hash MCP tool: SHA-256, MD5 and HMAC for AI agents

Language models can’t compute hashes. Asked for the SHA-256 of a string, a model produces 64 hexadecimal characters with the right length and the right look, and they’re almost never the right digest. There’s no shortcut: SHA-256 is 64 rounds of bit operations, and a model doesn’t execute code when it writes text. Ask for the hash of a file and it can’t even read the bytes.

The devtoolbox.cc MCP server has a hash tool so the assistant can get real digests instead of plausible ones. It uses the same code as the hash generator on this site and runs on your computer. Installation is described on the MCP page.

What the tool computes

• MD5, SHA-1, SHA-256, SHA-384 and SHA-512 digests, all five or any subset.
• HMACs with the same algorithms, for checking webhook signatures and signed requests.
• Input as text (encoded as UTF-8) or as a file read byte for byte.
• Output in hexadecimal (lower or upper case) or Base64.

MD5 and SHA-1 are marked “not for security use” in the output. They’re still fine for checksums against accidental corruption, but collisions can be produced on purpose, so they shouldn’t protect anything.

Arguments

Argument	Type	Meaning
text	string	Text to hash. Use this or path.
path	string	A local file to hash.
algorithms	list of "MD5", "SHA-1", "SHA-256", "SHA-384", "SHA-512"	Default: all five.
hmac_key	string	Compute HMACs with this key.
hmac_key_env	string	Name of an environment variable that holds the HMAC key.
format	"hex" or "base64"	Default "hex".
uppercase	boolean	Uppercase hex. Default false.

Examples

These examples were run against the real tool. The classic test vector from FIPS 180, the SHA-256 of abc:

{ "text": "abc", "algorithms": ["SHA-256", "MD5"] }

SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
MD5: 900150983cd24fb0d6963f7d28e17f72 (not for security use)

Files are hashed byte for byte. Here’s a small release note file:

v2.4.1: fixes the export timeout.

{ "path": "/home/dev/release/NOTES.txt", "algorithms": ["SHA-256", "SHA-512"] }

SHA-256: cb2ed66977c6cb4ee66296544484e70bc9322f2f7483b7601b27849b0d584059
SHA-512: 782ad712a184a264bfe2a73561cc1fd1fa295437a18870b56ee8046dda989500bb6d1bbc5777e0c9533497af245f53fb072063a36bb90dfc84a8d3427f870739

Subresource Integrity attributes and many package registries use Base64 instead of hex:

{ "path": "/home/dev/release/NOTES.txt", "algorithms": ["SHA-384"], "format": "base64" }

SHA-384: cWtQ58bZW+6fbPLXw5HaKmVoevSdnsLLGYoynuJpk6u5FTIncHopmsHuIaW/XeHh

That value goes after sha384- in an integrity attribute. It’s the same 48-byte digest as the hex form, written in 64 characters instead of 96. The Base64 encoder on this site shows how that encoding works.

Checking a webhook signature

Payment providers and source hosts sign webhooks with an HMAC of the request body and a shared secret. To debug a signature mismatch, an agent needs the expected HMAC, which means it needs the secret. Pasting a production secret into a chat is a bad idea. With hmac_key_env, the tool reads the key from an environment variable of the MCP server, and the secret never appears in the conversation.

In this example the server was started with WEBHOOK_SECRET=key in its environment. The message is the test string from the HMAC example in the Wikipedia article on HMAC:

{
  "text": "The quick brown fox jumps over the lazy dog",
  "algorithms": ["SHA-256"],
  "hmac_key_env": "WEBHOOK_SECRET"
}

HMAC-SHA-256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8

If the variable isn’t set, the call fails instead of quietly hashing with an empty key:

{ "text": "payload", "hmac_key_env": "STRIPE_SECRET" }

Environment variable STRIPE_SECRET is not set

Most MCP clients let you set environment variables per server in their configuration, under an env key next to command and args. Signature checks have one more trap: compare the computed HMAC with the received one in constant time in your own code. That part belongs in the service, not in the tool.

Which algorithm to ask for

The right algorithm depends on what the digest is for:

• Verifying a download or a release artifact: whatever the publisher lists, usually SHA-256.
• Subresource Integrity in HTML: SHA-384 or SHA-256, in Base64.
• Finding duplicate files or cache keys you control: SHA-256, or MD5 if a legacy system expects it.
• Webhook and API request signatures: an HMAC with the hash the provider documents, most often HMAC-SHA256.
• Storing passwords: none of these. Fast hashes make guessing cheap. Passwords need a slow, salted function such as Argon2id, scrypt or bcrypt, from your framework’s password library. This tool doesn’t compute those.

MD5 and SHA-1 stay useful for compatibility and for catching accidental corruption. They shouldn’t protect anything an attacker could tamper with, because collisions for both can be produced on purpose.

Comparing checksums

A checksum check is only as good as the comparison. Compare the full digest, not the first and last few characters. Hex digests are case-insensitive, so BA78… and ba78… are the same value, while Base64 digests are case-sensitive. Many projects publish a SHA256SUMS file with one digest filename line per download, which sha256sum -c SHA256SUMS checks in one go. The MCP page of this site publishes one for its own downloads. An agent can read such a file, hash the downloaded files with this tool and report any mismatch line by line.

Things to ask your assistant

• “What’s the SHA-256 of dist/app.zip? Compare it with the checksum in SHA256SUMS.”
• “Generate the integrity attribute for public/vendor.js with SHA-384.”
• “The webhook in request.log fails verification. Compute the HMAC-SHA256 of the body with the key in WEBHOOK_SECRET and compare it with the X-Signature header.”
• “Hash every file in fixtures/ with MD5 so I can spot duplicates.”

For a quick digest in the browser, the hash generator on this site computes all five algorithms at once, for text or a dropped file.

Why digests have to come from code

A digest is only useful if it’s exactly right. One wrong character makes a checksum comparison fail, or worse, makes a wrong file look verified when the agent “compares” two strings it generated itself. A tool turns a hash from a guess into a fact the agent can rely on, and it lets the agent work with files it couldn’t otherwise read.

The hash tool runs in the devtoolbox.cc MCP server, locally, with no network access. Files and keys stay on your computer. Setup for Claude Desktop, Claude Code, Cursor and VS Code is on the MCP install page.