Skip to main content
Glama

Jeevesus — DugganUSA threat-intel MCP

Correlate an indicator: do we hold it, and what is next to it

correlate
Read-onlyIdempotent

Answers two different questions about an IP address or domain, and keeps them apart: do we HOLD it, and what sits NEXT to it.

held is an exact yes or no, with held_in naming the lane that answered (iocs, the published blocklist lane, or the graph). neighbors is group membership in our indicator graph: the same /24 for an IPv4 address, the same registrable domain for a domain, with a real count (or "200+" with truncated:true when the scan hit its bound). neighbor_summary says what those neighbors are: how many are attributed to which actor or malware family, from how many lanes. A range we carry that covers the address, with no exact record, is reported as block_coverage, never as a detection.

strength is a single word for a hurried reader: none, adjacent-only, single-lane, multi-lane or corroborated. Read caveats before trusting it: a shared hosting platform or cloud range makes neighbors co-tenants, not related infrastructure, and the response says so when it applies.

Use it after enrich-ioc, or first, when the question is "is this part of something": a scanner next to a known C2, a lookalike domain on a campaign's registrar, a clean address in a dirty /24. Keyed Pro and Enterprise callers also get the neighbor rows themselves (neighbors.sample) to pivot on with enrich-ioc; free and anonymous callers get the counts and the summary.

Not consulted: our own edge observations (blocks, honeypot hits). Read-only. Hashes and URLs are not graph nodes; use enrich-ioc for those.

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": "correlate"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax neighbor rows returned to Pro and Enterprise callers. Default 10. Counts and the summary do not depend on it.
indicatorYesAn IPv4 address or a domain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare it read-only/non-destructive; the description adds substantial behavior beyond that — the `held`/`held_in` lane semantics, the exact rule for what counts as a neighbor, truncation signaled by `truncated:true` with "200+", the distinction between `block_coverage` and a detection, and the `strength` vocabulary and caveats. It also discloses a tier-based access difference (Pro/Enterprise receive `neighbors.sample` rows; free/anonymous callers receive counts only) and that edge observations are explicitly not consulted.

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?

Front-loads the two-question framing, then defines each returned field in order, then usage, then exclusions — a logical, scannable structure. It is dense and somewhat long, and phrases like 'a single word for a hurried reader' are stylistic rather than informative, but nothing is redundant.

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?

No output schema exists, so the description carries the return-shape burden and does so thoroughly: field-by-field meaning for `held`, `held_in`, `neighbors`, `neighbor_summary`, `block_coverage`, `strength` and `caveats`. Combined with the complete schema, an agent has everything needed to call and interpret it.

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% and both parameters are fully documented in the schema, including `limit`'s tier restriction and its non-effect on counts and summary. The description adds no syntax or format detail for `indicator` or `limit` beyond the schema, so baseline 3 applies.

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 (correlate an IP or domain) and immediately splits the answer into two named questions, `held` and `neighbors`. It is distinguishable from `enrich-ioc`, which it explicitly positions as the sibling for hashes and URLs.

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 guidance ('after `enrich-ioc`, or first, when the question is "is this part of something"') with three concrete motivating examples (scanner next to C2, lookalike domain, clean address in a dirty /24). It also names when-not-to-use: hashes and URLs are not graph nodes, go to `enrich-ioc`.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources