Submit files and URLs to a malware sandbox, poll scans, fetch reports, hashes and IOCs.
Scored across 5 tools
Each tool has a clear role in the scan lifecycle, and the descriptions are detailed enough to prevent most misselection. The only potential ambiguity is between lookup_hash and search_indicator, since both can relate to searching by a hash; however, lookup_hash is specifically about finding analyses of a SHA-256 digest while search_indicator is broader indicator-observed search.
All tool names follow the same verb_noun snake_case pattern: get_report, lookup_hash, poll_scan, search_indicator, submit_scan. The verbs clearly describe the action and the objects describe the resource, making the pattern predictable and consistent.
Five tools is well-scoped for a malware analysis server: submit, poll, retrieve, and two discovery/search mechanisms. Every tool earns its place in the workflow without redundancy or unnecessary bloat.
The server covers the full scan lifecycle: submit_scan starts work, poll_scan checks status, and get_report retrieves the analysis. It also provides adequate discovery through lookup_hash and search_indicator, and the file-upload limitation is explicitly scoped out rather than left as an implicit gap.
The derived analysis report for one scan: verdict, capabilities, behaviour summary, observed operations and defanged indicators. Derived data only - it never contains the sample's bytes, its decompiled source, a download link or an artifact reference. Every list in the result reports what was returned, counted and truncated. Answers 'not found' for a scan that does not exist and for one this token may not read, identically.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | The scan's numeric id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds substantial behavioral context: the output never contains sample bytes, decompiled source, download links, or artifact references; lists report counts and truncation; and missing versus unauthorized scans return identical 'not found' responses. This is rich, useful behavioral disclosure.
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?
Every sentence earns its place: contents, exclusions, list semantics, and not-found behavior are each covered once with no redundancy. The most identifying information is front-loaded in the first sentence.
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?
With one documented parameter and no output schema, the description compensates well by specifying what the result contains, what it excludes, how lists behave, and how missing or unauthorized scans are handled. An agent has enough context to call the tool and interpret the result correctly.
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?
The schema already fully documents the only parameter, scan_id, as an integer 'numeric id,' so the description does not need to add parameter details. It lightly ties scan_id to 'one scan,' but the schema carries the explanatory weight here, which warrants the baseline 3.
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 clearly identifies the resource as 'the derived analysis report for one scan' and enumerates its contents, so an agent understands what the tool returns. It does not explicitly contrast with sibling tools, but the 'one scan' scope and derived-data emphasis make its purpose clear enough.
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?
The description implies when the tool is relevant: you have a scan and want its derived report, and it emphasizes that it exposes derived data only. However, it never explicitly says when to prefer get_report over poll_scan or lookup_hash, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find analyses of a known SHA-256 digest. Returns the caller's own scans of those bytes plus any publicly shared scan of them. Sends nothing anywhere: this searches scans that already exist on this platform. Answers with an empty list when the hash is unknown or not visible to this token, without distinguishing the two.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes | A 64 character hex SHA-256 digest. |
| Name | Required | Description |
|---|---|---|
| scans | Yes | A bounded list: items plus what was returned, counted and cut. |
| sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description reveals important behavior: it returns the caller's own plus public scans, sends no data externally, and deliberately returns an empty list for unknown or unauthorized hashes without distinguishing the two. This visibility protection is significant and well documented.
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?
Three concise sentences, each earning its place: the first states the core purpose, the second defines result scope, and the third explains edge-case behavior. All key information is front-loaded without redundancy.
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?
The description is complete for a single-parameter lookup tool: it covers the operation, result content, privacy behavior, and empty-result semantics. The output schema handles return structure, and no critical calling context is missing.
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 100% and the parameter description already clearly defines a 64-character hex SHA-256 digest. The tool description adds no new parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.
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 ('Find'), a specific resource (analyses of a SHA-256 digest), and clarifies scope: the caller's own scans plus public scans. This clearly separates it from siblings like submit_scan (which creates scans) and makes its lookup role unambiguous.
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?
The description makes the use case clear: use this when you already have a known SHA-256 digest and want to retrieve existing analyses. 'Sends nothing anywhere' and 'searches scans that already exist' imply a safe, read-only lookup, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The current status of one scan, for polling after submit_scan. Cheap enough to call in a loop. 'terminal' means the scan will not change again; 'report_available' means get_report will return a full report. Answers 'not found' for an unknown scan and an unreadable one identically.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | The scan's numeric id. |
| Name | Required | Description |
|---|---|---|
| mime | No | |
| size | No | |
| tags | No | |
| score | No | |
| module | No | |
| sha256 | No | |
| status | No | |
| scan_id | No | |
| verdict | No | |
| terminal | No | |
| finished_at | No | |
| submitted_at | No | |
| report_available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals meaningful behavior: it is safe for repeated calls, that 'terminal' is a final state, that 'report_available' gates get_report, and that unknown and unreadable scans are intentionally indistinguishable. This is substantial added context.
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?
Every sentence earns its place: the main purpose, the polling suitability, the key status meanings, and the privacy/error behavior. It is compact, front-loaded, and free of redundancy.
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 the output schema exists and the description already covers usage timing, status semantics, cost behavior, and edge-case handling, an agent has enough context to invoke and interpret this tool correctly.
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 100%, so the schema already documents scan_id as an integer numeric id. The description adds no extra parameter-level detail, but it does not need to; the baseline of 3 applies.
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 ('poll'), a specific resource ('one scan'), and the exact context ('after submit_scan'). It also distinguishes itself from get_report by defining when that sibling becomes relevant.
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?
It explicitly says to use this after submit_scan and notes it is cheap enough for a polling loop. It points to get_report when 'report_available' occurs, though it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find scans where an indicator was observed: an IP, a domain, a URL, a mutex, a registry key, a hash or a JA3/JA4 fingerprint. The indicator is matched exactly; defanged input such as 'evil[.]com' is refanged first. Only scans this token may read are searched.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional indicator type to narrow the search: ip, domain, url, md5, sha1, sha256, imphash, mutex, registry, filepath, email, ja3, ja4, user_agent. | |
| indicator | Yes | The exact indicator value. Defanged forms are accepted. |
| Name | Required | Description |
|---|---|---|
| matches | Yes | A bounded list: items plus what was returned, counted and cut. |
| indicator | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses meaningful behavior: indicators are matched exactly, defanged input is refanged first, and only scans the current token can read are searched. This gives an agent important operational expectations without contradicting the annotations.
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?
Three sentences deliver the core purpose, accepted input scope, matching behavior, and access boundary with no filler. The most important information is front-loaded, and every sentence contributes operational meaning.
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?
For a read-only list/search endpoint with only two simple parameters and a provided output schema, the description covers purpose, accepted indicator types, matching semantics, defang handling, and authorization scope. Nothing needed for correct invocation is missing.
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?
The schema already provides 100% coverage for both parameters, including the type enum and indicator meaning. The description adds value by clarifying exact-match semantics and defang/refang handling for the indicator parameter, which is not present in the schema.
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 uses a specific verb ('Find scans where an indicator was observed') and identifies the resource (scans) plus the full range of accepted indicator types (IP, domain, URL, mutex, registry key, hash, JA3/JA4). This clearly distinguishes the tool's core purpose from the sibling tools.
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?
The description conveys that this tool is for searching scans by an observed indicator and notes that only readable scans are searched. However, it does not explicitly say when to prefer this over lookup_hash or other siblings, nor does it state any exclusion conditions, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue a new analysis of a target that can be named as text: a SHA-256 to look up, a URL to visit, a command to run, or a package to install. Uploading a file or a document is not possible over MCP. This spends the account's own credits and is subject to its plan limits. Poll the returned scan_id with poll_scan, then read it with get_report.
| Name | Required | Description | Default |
|---|---|---|---|
| module | Yes | hash: look up a SHA-256. url: visit a URL in a browser VM. command: run a command line in a Windows VM. package: install a package in a Linux VM. url and package detonate with internet access and are refused on a plan that does not include it. | |
| target | Yes | The digest, URL, command line or package specifier, matching the chosen module. | |
| private | No | Keep the scan off the public corpus. Free plans cannot make a scan private and this is ignored for them. |
| Name | Required | Description |
|---|---|---|
| mime | No | |
| size | No | |
| tags | No | |
| score | No | |
| module | No | |
| sha256 | No | |
| status | No | |
| scan_id | No | |
| verdict | No | |
| terminal | No | |
| finished_at | No | |
| submitted_at | No | |
| report_available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that this is a queued/asynchronous operation, that it spends the account's own credits, and that it is subject to plan limits. These are material behavioral facts not captured by readOnlyHint, idempotentHint, or destructiveHint.
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 compact and front-loaded with the core action, then states key constraints and the workflow. Every sentence earns its place: purpose, limitation, cost, and next steps.
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?
For a tool with an output schema and fully described parameters, the description covers the important operational context: what can be submitted, what cannot, credit implications, and how to retrieve the result. An agent has enough to decide when and how to call it.
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 100%, so the schema already documents module, target, and private thoroughly. The description's enumeration of target types adds readability but does not add substantial semantic information beyond the schema.
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 clearly states the verb and resource: 'Queue a new analysis of a target' and enumerates the accepted target forms (SHA-256, URL, command, package). It also explicitly excludes file/document upload, which sharpens the boundary of what this tool does.
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?
The description gives clear context for when to use the tool: when the target can be named as text, and it warns that file uploads are not possible. It also explains the follow-up workflow with poll_scan and get_report. It does not explicitly contrast this with lookup_hash or other siblings, so a fully explicit when-not-to-use statement is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_reportlookup_hashpoll_scansearch_indicatorsubmit_scanThird-party sandbox verdict on any artifact in one call, no account. Also an agent marketplace.
VirusTotal reports, file and URL submissions, domain/IP reanalysis, and analysis recovery.
STIX IOCs, CVE lookups w/ EPSS/KEV, ATT&CK dossiers, OFAC wallet sanctions, domain age checks.
Breach intelligence API: email search, domain monitoring, passwords and stealer logs.
Add one secure layer between your agents and this server.
