Skip to main content
Glama
Sign In

Jeevesus — DugganUSA threat-intel MCP

by io.github.pduggusa
OverviewDiscussionsAdmin

Enrich an indicator

enrich-ioc
Read-only

Looks up an IP address, domain, URL or file hash, such as one from a message, log line, SIEM alert or code under review.

Look up a single indicator of compromise (IP, domain, URL, or hash) in the DugganUSA corpus. Returns the threat type, malware family, confidence and references of the record with the strongest attribution (first-party, then curated, then third-party; not necessarily the highest confidence), the attributed actor if any record names one, and a sources list with each record's source, actor, confidence, first_seen (the source's own date when the record carries one, such as a vendor report date, otherwise when it entered our corpus) and ingested_at (always when it entered our corpus, which is not when it was first observed) and description (up to 10). attribution names the strongest record's class. Read-only. Country is filled in only when the source records one; many feeds publish none.

Useful after search finds something, for the full attribution and cross-feed correlation, or directly when triaging a single indicator.

Pass the IOC as either indicator or value (both work). Optional type hint: ip / domain / url / hash / auto.

Examples: indicator="185.93.3.195" → ShinyHunters/UNC6040 infrastructure. indicator="goldenleafway.lat" → fresh Apothecary/ClearFake .lat rotation domain. indicator="ee28b3137d65d74c0234eea35fa536af" → Volexity-attributed malware MD5 (BrazenBamboo/DEEPDATA campaign).

Returns found: false when the indicator isn't in the corpus. That means we hold no record, not that it is safe.

Input Schema

NameRequiredDescriptionDefault
typeNoOptional type hint. Default auto-detect.
valueNoAlias of `indicator`. Either field works.
indicatorNoThe indicator to enrich (IP, domain, URL, or hash).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "ip",
-  "domain",
-  "url",
-  "hash",
-  "auto"
-]New value: +[
+  "ip",
+  "domain",
+  "url",
+  "hash",
+  "email",
+  "auto"
+]
  2. Changed3 schema fields changed
    • addedInput schema / properties / indicator
      Added value: +{
+  "description": "The indicator to enrich (IP, domain, URL, or hash).",
+  "maxLength": 500,
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / properties / value / description
      Previous value: -"The indicator value."New value: +"Alias of `indicator`. Either field works."
    • removedInput schema / required
      Removed value: -[
-  "value"
-]
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover readOnly/openWorld; the description adds genuine behavioral depth beyond them: attribution precedence (first-party → curated → third-party, "not necessarily the highest confidence"), the `sources` list cap of 10, and the first_seen vs ingested_at distinction. It also flags real edge cases — `found: false` does not mean safe, and country is often absent.

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?

Purpose is front-loaded and the return-value block earns its space since there is no output schema. However, the first two sentences redundantly restate the same indicator-type list, and the long parenthetical about first_seen/ingested_at is dense to parse in one pass.

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 no output schema, the description carries the return-shape burden and does so thoroughly: attribution class, actor, per-source confidence, timestamps, and truncation limits. Missing-data and not-found behavior are both covered, leaving nothing an agent needs to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by showing concrete indicator formats via three worked examples. It does repeat the schema's alias note ("Pass the IOC as either `indicator` or `value`") and its type list omits the `email` value present in the schema enum, a minor gap.

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 a single indicator of compromise (IP, domain, URL, or hash) in the DugganUSA corpus") and explicitly locates itself relative to the `search` sibling. An agent can distinguish it from `search` and the check-* tools without opening any schema.

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

Usage Guidelines4/5

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

Gives clear usage context: "Useful after `search` finds something, for the full attribution and cross-feed correlation, or directly when triaging a single indicator." That names the alternative and the condition selecting it, but offers no when-not-to-use or boundary against the other siblings (check-package, check-repo, kev-*).

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

All Jeevesus — DugganUSA threat-intel MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources