maltiverse-mcp

Overview Schema Source Related Servers Discussions Admin

Check file-hash reputation (Maltiverse)

maltiverse_check_sample

Read-onlyIdempotent

Look up a malware sample by MD5, SHA-1, SHA-256, or SHA-512 hash to retrieve classification, AV detection ratio, file type, and threat attributions.

Instructions

Look up a malware sample by file hash in Maltiverse.

Returns classification, AV detection ratio, file type, and threat attributions. Accepts MD5/SHA-1/SHA-256/SHA-512; the right endpoint is chosen from the hash length.

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": {
      "file_hash": "<file_hash>"
    },
    "name": "maltiverse_check_sample"
  }
}

Input Schema

Name	Required	Description	Default
`file_hash`	Yes	A malware sample hash: MD5 (32 hex), SHA-1 (40), SHA-256 (64), or SHA-512 (128). The algorithm is detected from the length.
`response_format`	No		concise

Output Schema

Name	Required	Description
`tags`	No
`type`	Yes
`value`	Yes	The indicator that was looked up.
`as_name`	No
`sources`	No	Distinct feeds that reported this indicator.
`summary`	Yes	One-line human-readable summary of the verdict.
`av_ratio`	No
`filetype`	No
`hostname`	No
`blacklist`	No	Full per-feed attributions (detailed mode only).
`last_seen`	No
`first_seen`	No
`active_flags`	No	Behaviour flags that are true, e.g. 'is_cnc', 'is_tor_node'.
`country_code`	No
`is_malicious`	Yes	True when classification is 'malicious'.
`threat_names`	No	Distinct threat/campaign names across all feeds.
`classification`	Yes	Maltiverse verdict: malicious, suspicious, neutral, whitelist, or unknown.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A3.9/5.0

Behavior4/5

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

The annotations already declare read-only, idempotent, open-world, and non-destructive behavior, so the description does not need to repeat that. It adds useful context beyond the annotations by confirming that MD5, SHA-1, SHA-256, and SHA-512 are accepted, that the endpoint is selected automatically from hash length, and that the result includes classification, AV detection ratio, file type, and threat attributions.

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?

The description is three short sentences, front-loaded with the purpose, then return categories, then accepted input behavior. No wording is wasted, though describing return values is slightly redundant given the presence of an output schema.

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

Completeness4/5

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

For a simple lookup tool with rich annotations and an output schema, the description covers purpose, accepted input formats, endpoint selection, and return categories. The main omission is any mention of the response_format parameter, but the schema's enum and default make that detail discoverable.

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 50%: file_hash is thoroughly documented in the schema, and the description largely echoes that documentation rather than adding new meaning. The response_format parameter is not mentioned in the description, though its concise/detailed enum and default make it reasonably self-explanatory. A baseline 3 is appropriate because the description neither compensates for nor worsens the partial schema coverage.

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 states a specific verb ('Look up') and resource ('malware sample by file hash'), and the listed hash algorithms make the scope unambiguous against siblings such as maltiverse_check_hostname and maltiverse_check_url. An agent can identify this as the file-hash reputation tool without opening the schema.

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

Usage Guidelines3/5

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

The description implies the use case by saying 'by file hash' and listing accepted hash types, so an agent knows this tool applies when a file hash is available. However, it does not explicitly state when to choose it over siblings like maltiverse_check_indicator or maltiverse_search, nor does it provide exclusions.

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

Deploy Server