feat(filesystem): add streaming get_file_hash tool for cryptographic digests (md5/sha1/sha256)
#2516
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduce a streaming file-hash tool using `crypto.createHash` and `fs.createReadStream`.
Validates input via Zod and respects allowed-roots path checks.
- Tool: `get_file_hash`
- Args: { path: string, algorithm: "md5"|"sha1"|"sha256", encoding?: "hex"|"base64" }
- Output: digest as hex (default) or base64
- Handler: added to CallToolRequest; included in ListTools
Notes:
- Rejects non-regular files (e.g., directories/devices)
- Fails fast if algorithm is unavailable in this Node/OpenSSL build
(e.g., FIPS) with a clear error message.
…ed testing Extract `getFileHash` from `index.ts` into a standalone module to avoid pulling server bootstrap and top-level await into unit tests. This decouples hashing logic from transport setup and other side effects, allowing tests to import the function directly. No behavior change: the server now imports `getFileHash` from `hash-file.ts`. This prepares the codebase for comprehensive unit tests covering success and error paths.
Add a policy gate to `getFileHash` that rejects any algorithm not in {md5, sha1, sha256}.
Motivation: these are the widely used hashes in digital forensics; keeping the list small helps
interoperability with DFIR tools and simplifies model/tool prompts. Also prepares unit tests
to assert failure on unsupported algorithms (e.g., sha512, crc32, etc.). Runtime availability is
still checked via crypto.getHashes to surface FIPS/build issues cleanly. Default remains sha256;
md5/sha1 are retained for legacy sets.
Add unit tests covering hashing of the text "ForensicShark" across md5/sha1/sha256 with expected digests. Validate rejection of non-regular paths (directory, symlink to directory, device like /dev/null when present). Verify hashing of a small binary snippet across all three algorithms. Assert that unsupported algorithms (e.g. sha512, crc32, whirlpool) throw per the policy gate. Exercise both encodings (hex and base64) for text and binary cases. Tests are platform-aware: skip the device case on Windows and create a junction for the directory symlink on Windows.
Refine the `get_file_hash` tool description to be concise and Qwen-friendly with properly escaped quotes. Document encoding as optional with default "hex"; require an absolute path and state the input must be a regular file under allowed directories (not directories/devices). Instruct models to return only the digest string. This improves tool-calling reliability and matches the Zod schema and server defaults.
olaservo
added
server-filesystem
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add a streaming file-hash tool to the filesystem server with Zod-validated
inputs, allowed-roots enforcement, and optional digest encoding.
Description
This PR adds a new tool,
get_file_hash, to the filesystem MCP server.crypto.createHash+ streamingfs.createReadStream(efficient on large files)md5,sha1,sha256(default:sha256)"hex"(default) or"base64"(optional)ListToolsregistrationServer Details
Motivation and Context
I’m a computer forensics expert; verifying file integrity is critical to chain of
custody. Standards (e.g., ISO/IEC 27037, SWGDE) emphasize hashing digital evidence.
NIST recommends collision-resistant hashes (SHA-2); SHA-1/MD5 remain for legacy
identification but not for collision-sensitive uses. This tool defaults to SHA-256
while retaining MD5/SHA-1 for interoperability. Keeping the algorithm set small
improves DFIR compatibility and simplifies model prompts.
Providing
get_file_hashinside the filesystem server lets LLM-driven workflowscompute/compare hashes under the same allowed-roots and realpath/symlink controls
as other file operations—no external copying, consistent and auditable results.
How Has This Been Tested?
MCP server; tool discovered via
ListTools)"abc","ForensicShark"), small binary snippet,encodings (hex/base64), non-regular paths rejected (dir/symlink/device), and
unsupported algorithms (e.g.,
sha512,crc32,whirlpool) rejected by policyclear error on unavailable algorithms (FIPS/build)
Breaking Changes
None. Additive only.
Types of changes
Checklist
Additional context
list_directory) when calling the tool from clients.only the digest string.
md5,sha1,sha256are supported by design; no extended algorithmsor env toggles in this PR.