maltiverse-mcp

Overview Schema Source Related Servers Discussions Admin

Check any indicator (auto-detect type, Maltiverse)

maltiverse_check_indicator

Read-onlyIdempotent

Look up an IP, domain, URL, or file hash without knowing its type; auto-detect the indicator type and query Maltiverse threat intelligence for a verdict.

Instructions

Look up any indicator when you don't know its type up front.

This is the convenient default: pass an IP, domain, URL, or hash and the server routes to the correct Maltiverse endpoint. Prefer the specific tools (maltiverse_check_ip/_hostname/_url/_sample) when you already know the type and want to avoid ambiguity.

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": {
      "indicator": "<indicator>"
    },
    "name": "maltiverse_check_indicator"
  }
}

Input Schema

Name	Required	Description	Default
`indicator`	Yes	Any IoC: an IP, domain/hostname, full URL, or file hash. The type is auto-detected (IP by parse, URL by scheme, hash by hex length, else host).
`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

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only, open-world, idempotent, non-destructive behavior, so the description only needs to add routing context — which it does, explaining that the server dispatches to the correct Maltiverse endpoint and that the generic path carries ambiguity risk. It stops short of noting that the response shape varies by detected type or that resolution could be slower/less precise than the specific tools, which would be the remaining useful behavioral detail.

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?

Short and front-loaded: the unknown-type condition comes first, then the routing behavior, then the alternative. Slightly redundant in restating 'convenient default' and the type list, but nothing structurally wasteful.

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?

An output schema exists and annotations cover the safety profile, so the description needn't explain return values. For a two-parameter routing tool this is close to complete; the only gap is what the concise vs. detailed response_format actually changes.

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%, and the description mostly repeats the schema's own list of accepted types (IP, domain, URL, hash) without adding detection detail — the actual auto-detect rules (parse, scheme, hex length, fallback to host) live in the schema, not here. The response_format parameter's effect on output is never mentioned, leaving half the parameter set explained only by the schema.

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?

States a specific verb and resource ('look up any indicator') plus the defining scope: when the type is unknown up front. It explicitly contrasts itself with the named type-specific siblings, so an agent can distinguish it without opening either schema.

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

Usage Guidelines5/5

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

Gives both sides of the decision: use this as the default when the type is unknown, and prefer maltiverse_check_ip/_hostname/_url/_sample when the type is known and ambiguity should be avoided. The alternative is named with the condition that selects it.

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

Deploy Server