Profullstack

ThreatCrush: Look up file hashes (CrushAV)

threatcrush_av_hash_lookup

Read-onlyIdempotent

[ThreatCrush] CrushAV file reputation, no key needed: look up up to 100 SHA-256 file hashes. For each hash something is known about, returns knownMalicious (the source listing it as malware), malwareName, trust (0-100: how sure CIRCL hashlookup is that this is a published, known-good file from NSRL or a major OS/package repo) and a fileName it was seen as. Unknown hashes are omitted. Send hashes only, never file contents.

Served by ThreatCrush (https://threatcrush.com/docs).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "hashes": "<hashes>"
    },
    "name": "threatcrush_av_hash_lookup"
  }
}

Input Schema

Name	Required	Description	Default
`hashes`	Yes	Lower-case hex SHA-256 hashes (max 100)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: it explains that missing hashes are silently dropped, that `trust` is a 0-100 confidence that the file is a published known-good artifact from NSRL or a major OS/package repo, and that `knownMalicious` names the source listing it as malware. It also warns against submitting file contents, which is a real misuse risk.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the batch limit, followed by return-field semantics, then the input warning. Slightly redundant in repeating the max-100 limit that the schema already states, and the run-on list of return fields is dense, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by defining each field plus the omission rule for unknown hashes. Combined with the documented single input and the safety annotations, an agent has everything needed to call and interpret this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter already documents 'Lower-case hex SHA-256 hashes (max 100)'. The description restates the 100 cap and adds the 'no file contents' constraint, but contributes no new format or validation meaning beyond the schema. Baseline 3 for a fully documented single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('look up up to 100 SHA-256 file hashes') and states the data source (CIRCL hashlookup / CrushAV file reputation). An agent can immediately tell this is a batch hash-reputation tool and not a feed or IOC search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete operating guidance: no API key needed, send hashes only and never file contents, max 100, and unknown hashes are simply omitted (so an empty result is not an error). It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it is clear context rather than full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Profullstack tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?