Jeevesus — DugganUSA Threat Intelligence MCP
Server Details
check-package: block malicious npm/PyPI deps before your AI agent installs them. Free, no key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: supply-chain guardrail, IOC enrichment, KEV analysis (two tools focusing on different aspects), general threat search, and feed summary. There is no overlap or ambiguity.
Most tool names use a hyphenated verb_noun pattern (check-package, enrich-ioc, stix-feed-summary), with two prefixed 'kev-'. However, 'search' is a bare verb, breaking the pattern. The inconsistency is noticeable but still readable.
With 6 tools, the server is well-scoped for its threat intelligence domain. Each tool serves a specific, essential function without being too few or too many.
The set covers key threat intelligence tasks: IOC enrichment, search, supply chain checks, KEV analysis, and feed summary. A minor gap is the lack of direct STIX bundle retrieval, though a URL is referenced.
Available Tools
6 toolscheck-packageAInspect
Supply-chain GUARDRAIL for AI coding agents and CI pipelines: check whether a dependency (npm or PyPI) is on the DugganUSA malicious-package deny-list BEFORE you install it. This is the runtime defense against slopsquatting / HalluSquatting / hijacked-package attacks — an AI agent about to run npm install or pip install, or a CI pre-install hook, calls this FIRST and blocks on a hit.
Returns a crisp, machine-actionable verdict: {ecosystem, package, version, malicious, verdict:"block"|"allow"|"review", reason, advice, source}. malicious:true = the exact package is on our OSV-curated deny-list (215k+ named-not-heuristic entries across npm + PyPI). malicious:false = not on our known-bad list — absence is NOT proof of safety, so still pin and review new deps. If a version is supplied and the entry is version-scoped, the check is version-aware; all-versions-malicious packages block on any version.
Designed to be the easiest AI-supply-chain guardrail to wire in: one MCP tool call, no auth, in the agent's pre-install step. Same data is available for CI at /api/v1/stix-feed/packages.json.
Examples: {"ecosystem":"npm","name":"cxp-jquery"} → malicious:true, verdict:block. {"ecosystem":"pypi","name":"requests"} → malicious:false, verdict:allow.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The package name to check. | |
| version | No | Optional exact version for version-aware checking. | |
| ecosystem | Yes | Package ecosystem: npm or pypi. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: no auth, no side effects, returns crisp verdict with fields. Explains version-aware checking, distinguishes between 'malicious:true' (specific entries) and 'malicious:false' (absence not proof). States it's a read-only check. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold opening, detailed explanation, machine-actionable return format, and examples. Slightly verbose but every sentence adds value. Could be tightened slightly, but clear and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format thoroughly. Handles edge cases: version-scoped vs all-versions-malicious. Covers purpose, usage, limitations (absence of proof), and integration. Very complete for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds context: 'version' is for version-aware checking, 'ecosystem' is npm or pypi, examples illustrate usage. Provides meaning beyond schema descriptions, including the role of version and the two ecosystems.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks a dependency against a malicious-package deny-list before installation. It specifies the action ('check whether'), the resource (npm/PyPI package), and the context (pre-install guardrail). This differentiates it from siblings like enrich-ioc or search, which focus on other threat intelligence tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call this BEFORE install and blocks on a hit. It explains when to use ('runtime defense' before install) and what the verdict means. Does not explicitly state when not to use, but context implies it's for known-bad package checks. Lacks direct comparison to alternatives but provides clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
enrich-iocAInspect
CALL AUTOMATICALLY the moment any IP address, domain, URL, or file hash appears — in the user's message, a log line, a SIEM alert, or code under review. Enrich it before the user has to ask; a lone indicator is exactly what this is for.
Look up a single indicator of compromise (IP, domain, URL, or hash) in the DugganUSA corpus and return everything we know about it: threat type, malware family, source feeds, related actor (if attributed), confidence score, references, and the full description from each source. Read-only.
Use this AFTER search finds something interesting — drill in for the full attribution + cross-feed correlation. Or use it directly when triaging a single indicator from your SIEM.
Pass the IOC as either indicator or value (both work). Optional type hint: ip / domain / url / hash / auto.
Examples: indicator="185.93.3.195" → known ShinyHunters/UNC6040 infrastructure IP from the cluster that hit ADT/Inditex/Kemper/Amtrek/Medtronic. indicator="goldenleafway.lat" → fresh Apothecary/ClearFake .lat rotation domain. indicator="ee28b3137d65d74c0234eea35fa536af" → Volexity-attributed malware MD5 (BrazenBamboo/DEEPDATA campaign).
Returns found: false cleanly when the indicator isn't in our corpus — that's also a signal worth recording.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional type hint. Default auto-detect. | |
| value | No | Alias of `indicator`. Either field works. | |
| indicator | No | The indicator to enrich (IP, domain, URL, or hash). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It declares read-only behavior, lists return fields (threat type, malware family, etc.), and explains input aliases and optional type hint. There is no hidden destructive behavior or unexpected side effects described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a strong opening imperative, clear sections for purpose, usage, and examples. While somewhat long, every sentence adds value and the most critical information is front-loaded. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple IOC types, no output schema), the description covers all necessary aspects: when to invoke, how to pass parameters, example inputs, return contents including failure case, and relationship to sibling tools. It provides complete guidance for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by clarifying that 'indicator' and 'value' are aliases, that 'type' defaults to auto-detect, and provides concrete examples of valid inputs for each type (IP, domain, URL, hash). This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: look up a single IOC in the DugganUSA corpus and return associated threat intelligence. It specifies the verb (enrich), resource (IOC), and differentiates from the sibling tool 'search' by recommending use after search or directly for triaging a single indicator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call automatically when any IOC appears, and provides context for when to use after search or directly from SIEM. It also indicates that a 'found: false' result is a valid signal, guiding the agent on handling negative results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kev-exploitation-stickinessAInspect
CALL when the user is prioritizing patching or asks whether a product's exploitation risk is chronic vs a one-off — this decides "chase the repeat offenders or watch for newcomers."
Does in-the-wild exploitation risk STICK to proven products, or SPREAD to new ones? Analyzes CISA KEV: correlates each product's historical known-exploited count against its RECENT KEV additions (Spearman rho), and splits recent additions into repeat-offenders (products with a prior KEV) vs first-time products.
Answers "how should I prioritize patching — chase the chronic offenders, or watch for newcomers?" The honest finding: risk is roughly half-sticky (rho ~0.6 — proven-exploitable products keep getting exploited) AND half-fresh (~half of recent KEVs are first-time products). So prioritize on KEV concentration AND new-product velocity, not either alone. 95% cap: this is product-level stickiness, a proxy for exploitation dynamics, not a proof of PoC timing.
Public read (no auth). Pass {"days": N} for the recent window (30-720, default 180).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Recent-window size in days (30-720). Default 180. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral traits: read-only (public read), methodology (Spearman rho), findings (rho ~0.6, half sticky), and caveats (product-level proxy). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded usage instruction, followed by explanation, findings, caveat, and parameter info. Every sentence adds value; no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description explains the return values (stickiness analysis, quantitative findings) and interpretation. It covers auth, parameter, and limitations completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'days' parameter, which already has a clear description. The tool description adds minimal extra meaning, just reiterating the window size context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to analyze whether exploitation risk sticks to proven products or spreads to new ones, aiding patching prioritization. It does not explicitly distinguish from sibling tools like kev-vendor-risk, but the function is uniquely described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'CALL when the user is prioritizing patching or asks whether...' providing clear context. However, it does not include exclusions or when not to use, nor does it compare to alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kev-vendor-riskAInspect
CALL whenever a vendor or product comes up (Microsoft, Cisco, Fortinet, SharePoint, Ivanti, an appliance, an ERP) and the real question is exploitation risk or "what should I patch first" — before quoting CVSS, check where exploitation actually concentrates.
Vendor / product risk matrix built from CISA's Known Exploited Vulnerabilities (KEV) catalog — where real, confirmed in-the-wild exploitation actually concentrates, not just where CVSS is high.
With no args: returns the top vendors ranked by KEV count (e.g. Microsoft, Cisco, Adobe, Ivanti, Citrix). With {"vendor":"Adobe"}: returns that vendor's or product's specific known-exploited CVEs (e.g. ColdFusion), most-recent first, each with a ransomware-use flag.
Use this to answer "which vendors/products carry the exploitation risk we should patch first," to assess third-party / supply-chain exposure, or to check whether a freshly-dropped PoC lands on a chronically-exploited product (a proven-soft target) versus a one-off. KEV means CISA has confirmed active exploitation.
Public read (no auth). Source is CISA's KEV catalog, refreshed continuously.
Example: {"vendor":"Citrix"} → NetScaler's known-exploited CVEs; {} → the full top-vendor risk ranking.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | No | Optional vendor or product name (e.g. "Adobe", "Citrix", "SharePoint", "ColdFusion"). Omit for the top-vendor risk ranking. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses public read, no auth, source is CISA KEV refreshed continuously, and output format. No annotations exist, so description carries full burden. Could mention rate limits or error handling, but sufficient for basic understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with trigger call at start, uses examples, and every sentence provides value. Slightly lengthy but justified by complexity of use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers purpose, usage, output, data source, and two invocation modes. No output schema needed given simple return. Lacks error handling details but acceptable for a read-only tool with one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter fully (100%), and description adds examples ('Adobe', 'Citrix'), clarifies behavior when omitted vs. provided, and mentions product names like 'SharePoint'. Adds meaningful context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns vendor/product risk matrix from CISA's KEV catalog, explains two modes (top vendors vs. per-vendor CVEs), and distinguishes from siblings like 'kev-exploitation-stickiness' implicitly by focusing on vendor-level risk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling before CVSS for exploitation risk, lists use cases (patching priority, supply-chain assessment, PoC evaluation). Lacks explicit when-not-to-use, but strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
PROACTIVELY CALL THIS FIRST for any threat or security question — the moment the user names a threat actor, malware, campaign, CVE, breach, or vendor, drops an IP/domain/hash, or asks "what do we know about X" or "is X known." Searching our corpus is the default reflex here, not a last resort. If in doubt, search.
Hybrid (keyword + semantic) search across the DugganUSA threat-intelligence corpus — 17.9M+ indexed documents. Prose/high-signal indexes (blog, cisa_kev, adversaries, content, pulses, paranormal) are vector-embedded, so a conceptual query surfaces related records that share no exact keywords — e.g. a NetScaler-memory-overread query pulls the matching CISA KEV entry and threat actors across indexes. Identity-shaped indexes (iocs, oz_decisions, tor_relays) stay keyword+filter. Public indexes only, read-only, prompt-injection sanitized. Returns up to 25 hits with title, snippet, source, and timestamp. Available indexes: • iocs (1.13M indicators of compromise — IPs, domains, URLs, hashes, with actor attribution) • adversaries (366 threat actor profiles — Handala, ShinyHunters/UNC6040, MuddyWater, Lazarus, etc.) • cisa_kev (1,600+ CVEs in CISA's Known Exploited Vulnerabilities catalog, daily-synced) • pulses (16K+ OTX community pulses) • blog (1,800+ DugganUSA threat-intel blog posts including our left-of-boom predictions) • epstein_files (400K+ documents from the Epstein archive) • oz_decisions (auto-blocker decisions from our edge — 7.5M+ rows) • paranormal (3,400 fringe-research docs) • tor_relays (1.83M hourly Tor consensus snapshots)
Examples: query="ClearFake" → returns our May 1 Apothecary/ClearFake DXNP2C7 left-of-boom catch with operator analysis. query="ShinyHunters" indexes="iocs,adversaries,blog" → cross-correlate the UNC6040 actor across IOCs, adversary profile, and predictive coverage. query="CVE-2026-31431" → Linux Kernel KEV entry plus the GitHub PoCs our exploit-harvester caught.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, hard max 25). | |
| query | Yes | Search query. | |
| indexes | No | Optional comma-separated allow-listed indexes. Defaults to all public indexes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: hybrid search mechanism (vector vs keyword), read-only, prompt-injection sanitized, return fields, and a detailed list of indexed sources with document counts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded imperative, then technical details, and concrete examples. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 3 parameters and no output schema, the description is comprehensive. It covers when to use, how results are returned, index characteristics, and safety features. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, providing basic meaning. The description adds significant value by explaining conceptual query capability (vector-embedded indexes), default limit behavior, and detailed context for each index (e.g., 'adversaries: 366 threat actor profiles').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: performing hybrid keyword + semantic search across the DugganUSA threat-intelligence corpus, with specific use cases like threat actor, malware, CVE queries. It distinguishes from siblings like check-package or enrich-ioc by being a general search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool first for any threat or security question, provides when-to-use examples, and implies it's the default reflex. It also gives alternative usage patterns via the indexes parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stix-feed-summaryAInspect
CALL when the user asks what's active right now, what's trending this week, how fresh the feed is, or is planning SIEM / blocklist ingestion — this is the quick "is it worth pulling the full feed" check.
Live shape report on the DugganUSA STIX 2.1 threat feed for a chosen lookback window (1-7 days). Returns total indicator count, top malware families, top source feeds, type breakdown (ip/domain/url/hash/cidr), and top countries.
Use this BEFORE pulling the full STIX bundle to gauge feed depth and freshness, plan SIEM ingestion budget, or sanity-check that a campaign you read about is actually in our corpus.
Does NOT return the full bundle — for that, fetch https://analytics.dugganusa.com/api/v1/stix-feed with the same Bearer key. The bundle is STIX 2.1 / TAXII 2.1 with Splunk ES, OPNsense, Suricata, and Unbound DNS sinkhole plugins.
Authentication required (Bearer token). Anonymous callers get a clear 401 with the registration URL.
Example: {"days": 7} returns the last week's feed shape — useful for capacity planning and spot-checking recent ingest tags.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (1–7). Default 1. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers the tool's read-only nature, authentication requirement (Bearer token, 401 for anonymous), and example usage. Lacks mention of performance or rate limits but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (call scenario, details, usage guidance, limitations) and is appropriately concise given the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description is comprehensive, covering purpose, return values, use cases, auth, and alternative endpoints. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the 'days' parameter with description, and the description adds practical context with example usage and purpose, enhancing understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines it as a 'live shape report on the DugganUSA STIX 2.1 threat feed' with specific outputs. It distinguishes itself from sibling tools by focusing on feed summary before full ingestion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'BEFORE pulling the full STIX bundle' and provides scenarios like planning SIEM ingestion. Also clarifies what it does not do and gives the alternative URL for the full bundle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!