search_by_fuzzy_hashSearch scans by fuzzy hash (paginated).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| hash_type | Yes | ||
| hash_value | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / hash_type / enumAdded value: +[
+ "tlsh",
+ "ssdeep",
+ "sdhash"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that results are paginated, which is mildly useful but does not explain matching behavior, accepted hash formats, empty-result behavior, or any limits beyond the paginated mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loaded: it states the action, resource, and a key behavior in six words. No filler exists. However, the brevity leaves important usage guidance and parameter semantics unaddressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a fuzzy-hash search with four parameters and many closely related sibling tools, the description is too thin. It does not distinguish scan-level search from JS-fingerprint search, nor does it clarify the role of hash_type versus hash_value. The output schema and annotations help, but the description itself leaves an agent without enough context to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters, but it only says "fuzzy hash." It does not clarify that hash_type selects among tlsh/ssdeep/sdhash, what hash_value should contain, or how page and limit behave. The schema's enum and defaults do the real work here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair: "Search scans by fuzzy hash." This clearly sets the resource (scans) apart from the many JS-fingerprint sibling tools such as search_js_fingerprint_by_fuzzy_hash and search_jsfingerprints_by_fuzzy_hash. The word "paginated" adds a useful scoping detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. With dozens of sibling search tools, including two other fuzzy-hash searches, the description does not explain why an agent should pick this one or what distinguishes scan-level fuzzy-hash search from JS-fingerprint fuzzy-hash search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.