Skip to main content
Glama
maltiverse-mcp

maltiverse-mcp

by lumutech

Check IP reputation (Maltiverse)

maltiverse_check_ip
Read-onlyIdempotent

Look up an IP address's threat-intel reputation to get its classification, associated threats and feeds, ASN, and behavior flags such as C2, scanner, TOR, VPN, or proxy.

Instructions

Look up the threat-intel reputation of an IP address in Maltiverse.

Use this when you have an IP and need its classification (malicious / suspicious / neutral / whitelist), associated threats and feeds, ASN, and behaviour flags (C2, scanner, TOR, VPN, proxy, etc.). For domains use maltiverse_check_hostname; if you don't know the indicator type, use maltiverse_check_indicator.

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": {
      "ip": "<ip>"
    },
    "name": "maltiverse_check_ip"
  }
}

Input Schema

NameRequiredDescriptionDefault
ipYesIPv4 or IPv6 address, e.g. '8.8.8.8' or '2001:4860:4860::8888'.
response_formatNoconcise

Output Schema

NameRequiredDescriptionDefault
tagsNo
typeYes
valueYesThe indicator that was looked up.
as_nameNo
sourcesNoDistinct feeds that reported this indicator.
summaryYesOne-line human-readable summary of the verdict.
av_ratioNo
filetypeNo
hostnameNo
blacklistNoFull per-feed attributions (detailed mode only).
last_seenNo
first_seenNo
active_flagsNoBehaviour flags that are true, e.g. 'is_cnc', 'is_tor_node'.
country_codeNo
is_maliciousYesTrue when classification is 'malicious'.
threat_namesNoDistinct threat/campaign names across all feeds.
classificationYesMaltiverse verdict: malicious, suspicious, neutral, whitelist, or unknown.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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, and non-destructive behavior, so the description does not need to restate safety. It adds useful behavioral context by naming the returned classifications (malicious/suspicious/neutral/whitelist), associated threats and feeds, ASN, and behavior flags (C2, scanner, TOR, VPN, proxy). It does not mention authentication requirements or rate limits for the external lookup.

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

Conciseness5/5

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

The text is front-loaded with purpose, then immediately gives usage guidance and sibling alternatives. Every sentence adds selection or scoping value, and there is no redundant or filler wording.

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?

With a rich output schema and detailed annotations, the description supplies the core selection context and return-data categories. The main omission is any explanation of the response_format option, which would help an agent choose between concise and detailed results.

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

Parameters2/5

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

The description does not mention either parameter. Schema coverage is 50%: 'ip' is documented in the schema with examples, but 'response_format' (concise/detailed enum) has no description in the schema and none in the tool description, leaving the meaning and tradeoff of that option unclear.

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 opens with a specific verb and resource: 'Look up the threat-intel reputation of an IP address in Maltiverse.' It explicitly distinguishes the tool from maltiverse_check_hostname and maltiverse_check_indicator, so an agent can select it among siblings without opening their schemas.

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?

It states when to use this tool ('when you have an IP') and names alternatives for domains (maltiverse_check_hostname) and unknown indicator types (maltiverse_check_indicator). This is explicit routing guidance with no ambiguity.

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