Skip to main content
Glama
Sign In
maltiverse-mcp

maltiverse-mcp

by lumutech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Search Maltiverse indicators

maltiverse_search
Read-onlyIdempotent

Search the Maltiverse indicator dataset with Elasticsearch-style queries to hunt by threat name, tag, classification, ASN, country, or feed; paginate results with offset and limit.

Instructions

Search Maltiverse for indicators matching a query.

Use this to hunt across the whole dataset (by threat name, tag, classification, ASN, country, feed, etc.) rather than looking up one known indicator. Results are paginated: when has_more is true, call again with offset set to the returned next_offset. Keep limit small (default 20) to stay within output limits.

Example: query='classification:malicious AND type:ip AND country_code:RU'.

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": {
      "query": "<query>"
    },
    "name": "maltiverse_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax results per page (1-100).
queryYesElasticsearch query-string syntax over the IoC index. Examples: 'classification:malicious AND type:url', 'tag:emotet', 'as_name:"Google LLC"', 'blacklist.description:"Cobalt Strike"'.
offsetNoResult offset for pagination; pass the prior next_offset.

Output Schema

NameRequiredDescriptionDefault
queryYes
totalYesTotal matching indicators in Maltiverse.
resultsNo
has_moreYes
returnedYesNumber of hits in this page.
next_offsetNoPass as 'offset' to maltiverse_search to fetch the next page; null at end.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), but the description adds a genuine behavioral protocol: pagination via has_more/next_offset and the warning to keep limit small to stay within output limits. It stops short of noting rate limits or constraints on query complexity, so it is strong rather than exhaustive.

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?

Front-loads the one-line purpose, then qualifies it with a differentiating usage rule, then pagination mechanics, then an example. Every sentence carries actionable information and nothing is repeated from the schema verbatim.

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 annotations covering safety, an output schema covering return values, and full schema parameter descriptions, the description needs only to supply scope, the pagination loop, and query targeting — all present.

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%, so the baseline applies; the schema already documents query syntax, limit range, and 'pass the prior next_offset'. The description reinforces this with a worked query example and the limit-size rationale, but adds little the schema does not already state.

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 ('Search Maltiverse for indicators matching a query') and immediately distinguishes itself from the sibling check_* tools by contrasting 'hunt across the whole dataset' with 'looking up one known indicator'. An agent can route 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 explicit when-to-use criteria ('by threat name, tag, classification, ASN, country, feed, etc.') and an explicit when-not ('rather than looking up one known indicator'), implicitly naming the check_* siblings as the alternative.

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

Deploy Server

Other Tools