Jeevesus — DugganUSA Threat Intelligence MCP

Server Details

check-package: block malicious npm/PyPI deps before your AI agent installs them. Free, no key.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.6% over 57 days
Last Tested: 2026-10-13 17:17
Transport: Streamable HTTP · MCP 2024-11-05
URL

TDQS

A4.3/5.0

Scored 2026-10-05 20:50 across 7 tools

Disambiguation4/5

KEV-focused tools (kev-exploitation-stickiness and kev-vendor-risk) overlap in prioritization use cases, and search vs enrich-ioc could be confused for IOC lookup. However, descriptions clearly delineate each tool's role, with enrich-ioc for single indicators and search for corpus-wide discovery.

Naming Consistency3/5

All names use kebab-case, but the grammatical pattern is mixed: check-package and enrich-ioc are verb-first, search is a lone verb, and the rest are noun phrases. This inconsistency in action-vs-resource naming reduces predictability, though names remain readable.

Tool Count5/5

7 tools is well within the ideal range for a focused threat-intel service, and each tool addresses a distinct query or analysis need. The count is appropriate without being bloated or thin.

Completeness4/5

The set covers search, IOC enrichment, KEV risk analysis, feed summarization, and package checking, but lacks a tool to retrieve the full STIX feed — the summary tool explicitly defers to an external URL for bulk data. ai-model-price also sits outside the threat-intel domain, suggesting minor scope drift rather than a functional gap.

Available Tools

7 tools

ai-model-priceAInspect

CALL before quoting what an AI model or an agent session costs, or when a usage report needs dollars — prices are dated and copied from each provider's own pricing page, never from memory.

Returns the per-1M-token USD rates for a model (input, output, and for Anthropic models the 5-minute and 1-hour cache write, cache read and fast-mode rates), the date the provider page was checked, and the page it came from. Pass token counts to get an exact list-price cost for a call or a whole session.

With no args: lists every priced model and each provider's checked date. With {"model":"claude-opus-5-5","input_tokens":2,"cache_read_tokens":300000,"output_tokens":800}: returns the rates and the cost breakdown. A model not in the table returns UNPRICED — never $0.

Why it matters: in agent sessions most spend is context re-read from cache, not output (DugganUSA's own month: 93% carrying context). Meter your own Claude Code sessions in your browser, nothing uploaded: https://finops.dugganusa.com

Public read (no auth).

ParametersJSON Schema

Name	Required	Description
`fast`	No	Anthropic fast mode (premium rates).
`model`	No	Model id, e.g. "claude-opus-5-5", "gpt-4o-mini", "gemini-2.5-flash". Omit to list all priced models.
`input_tokens`	No
`output_tokens`	No
`cache_read_tokens`	No
`cache_write_1h_tokens`	No
`cache_write_5m_tokens`	No

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it declares public read with no auth, specifies the return payload (rates, provider-checked date, source page, cost breakdown), and documents failure semantics — an unknown model returns UNPRICED, never $0. That is exactly the kind of non-obvious behavior an agent needs before trusting a dollar figure.

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?

The imperative CALL directive is front-loaded and the core mechanics follow in tight sentences. The 'Why it matters' paragraph plus the self-promotional URL are extra weight that does not help an agent invoke the tool, though the cache-heavy-spend point does justify the cache_read_tokens parameter.

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?

For a seven-parameter tool with no annotations and no output schema, the description covers invocation modes, return contents and the unpriced edge case adequately. The remaining gap is the exact semantics of each cache-write/token parameter, which is only partially inferable from the description.

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 description coverage is only 29%, with five token parameters undocumented in the schema, but the description compensates by naming the rate categories (input, output, 5-minute and 1-hour cache write, cache read, fast-mode) and giving a worked example that shows input_tokens, cache_read_tokens and output_tokens in use. It does not spell out which parameters map to which rate line, so it stops short of fully closing the coverage 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: it returns per-1M-token USD rates for a named model and computes list-price cost from supplied token counts. The scope is unambiguous and no sibling tool (check-package, enrich-ioc, search, etc.) overlaps with it, so an agent can identify it immediately.

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?

Explicit trigger: "CALL before quoting what an AI model or an agent session costs, or when a usage report needs dollars," plus the rule that prices come from provider pages rather than memory. It also documents the no-args listing behavior. It does not name a when-not case or an alternative tool, which is the only thing keeping it from a 5.

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

check-packageInspect

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. With a version, it also checks OSV for published vulnerabilities in that exact version (known_vulnerabilities): a reputable package with known CVEs returns verdict:"review", never block.

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.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The package name to check.
`version`	No	Optional exact version for version-aware checking.
`ecosystem`	Yes	Package ecosystem: npm or pypi.

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.

ParametersJSON Schema

Name	Required	Description
`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).

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it declares read-only, enumerates the returned fields (threat type, malware family, source feeds, actor, confidence, references, descriptions), and notes the not-found behavior. It omits auth/permission requirements and rate limits, which keeps it short of a 5.

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?

The imperative auto-call instruction is correctly front-loaded and the examples earn their space by illustrating each input type. A couple of promotional clauses ('a lone indicator is exactly what this is for') are slight padding against an otherwise dense structure.

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?

There is no output schema, so the description must explain returns — and it does, listing every field plus the found:false path. Combined with the auto-detect type hint and alias note, an agent has everything needed to call this 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 schema already documents the params and baseline is 3. The description adds value by confirming the `indicator`/`value` alias both work and by giving concrete example values that show what each accepted input type looks like in practice.

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 states a specific verb and resource ('Look up a single indicator of compromise ... in the DugganUSA corpus') and enumerates exactly what it accepts (IP, domain, URL, hash). It also distinguishes itself from the 'search' sibling by positioning itself as the drill-in tool, so an agent can route between them 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?

It gives explicit triggering conditions ('CALL AUTOMATICALLY the moment any IP address, domain, URL, or file hash appears'), a sequencing rule ('Use this AFTER search finds something interesting'), and a standalone case ('when triaging a single indicator from your SIEM'). Alternatives and when-not are covered by the sibling reference.

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).

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Recent-window size in days (30-720). Default 180.

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it excels: it discloses 'Public read (no auth),' explains the analytical method (Spearman rho, repeat-offender split), and includes a clear limitation ('95% cap: this is product-level stickiness...'). This goes well beyond minimal requirements and is genuinely transparent.

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?

The description is longer than a simple two-sentence blurb, but every sentence delivers value: trigger, question, methodology, finding, caveat, and usage. It is front-loaded with the most important usage cue. Slight redundancy exists between the rhetorical question and the 'Answers...' sentence, but overall it is well-structured and not bloated.

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?

Despite having no output schema and no annotations, the description tells the user enough to invoke and interpret the tool: what it analyzes, how it works, what the key finding is, what the limitations are, and how to pass parameters. It also covers auth requirements. For a read-only analytical tool, this is complete.

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?

The schema already documents the single 'days' parameter completely (type, range, default, and description). The description repeats this information ('Pass {"days": N} for the recent window (30-720, default 180)') but does not add new semantic meaning beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: analyzing CISA KEV to determine whether exploitation risk sticks to proven products or spreads to new ones. It uses specific verbs like 'Analyzes' and 'Answers' and specifies the resource and methodology. However, it does not explicitly distinguish itself from sibling tools such as kev-vendor-risk, so it stops short of a full 5.

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?

The first line gives an explicit trigger: 'CALL when the user is prioritizing patching or asks whether a product's exploitation risk is chronic vs a one-off.' This provides clear context for when to use the tool. It does not mention when not to use it or name alternative tools, but the guidance is strong enough for a 4.

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.

ParametersJSON Schema

Name	Required	Description	Default
`vendor`	No	Optional vendor or product name (e.g. "Adobe", "Citrix", "SharePoint", "ColdFusion"). Omit for the top-vendor risk ranking.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses public read/no auth, the source (CISA KEV), continuous refresh, and output details (ordering, ransomware flag). This is strong, but lacks error handling, rate limits, or edge-case behavior, so a 4 is appropriate.

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 description is a single, well-structured paragraph with a clear sequence: usage trigger, context, behavior, examples. Every sentence earns its place, and the examples are compact and illustrative without being verbose.

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?

Despite the absence of an output schema, the description clearly communicates what the tool returns in both invocation modes, including ordering and the ransomware-use flag. It also covers data source and refresh, making it sufficiently complete for an agent to select and invoke the tool 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%, but the description adds significant meaning: it explains the effect of omitting vs. providing the 'vendor' parameter, gives concrete examples, and describes output ordering and flags. This goes beyond the schema's simple field description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: a vendor/product risk matrix built from CISA's KEV catalog, with specific behaviors (top vendors by KEV count, or per-vendor CVEs). It uses specific verbs like 'returns' and provides a resource, but does not explicitly distinguish from sibling tools such as kev-exploitation-stickiness, so it misses the top score.

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?

The opening explicitly says 'CALL whenever a vendor or product comes up... and the real question is exploitation risk or what should I patch first', which provides a clear when-to-use directive. It also lists use cases (e.g., supply-chain exposure, PoC check) but does not name alternative tools or specify when not to use this tool, 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.

searchInspect

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. Security topics ONLY — do not use this for general programming, documentation or web questions (e.g. "react hooks", "connection pooling"); it returns threat-intel records, not answers, and wastes your tokens.

Hybrid (keyword + semantic) search across the DugganUSA threat-intelligence corpus — ~29M documents (live: /api/v1/search/stats). 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.

ParametersJSON Schema

Name	Required	Description
`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.

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.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Lookback window in days (1–7). Default 1.

TDQS

A4.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses exactly what is returned (counts, top malware families, type breakdown, countries) and what is not (the full bundle), plus authentication requirements and the 401 behavior for anonymous callers. This is thorough and transparent.

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 description is front-loaded with the usage trigger and every sentence adds value: purpose, exclusions, auth, and example. It is organized into clear sections and remains succinct despite covering multiple aspects.

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 compensates by enumerating the expected return fields and explicitly stating the full bundle is not returned. It includes auth details, the alternative fetch URL, and an example, making it self-sufficient for an agent to use 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?

The schema fully describes the 'days' parameter with min, max, and default. The description adds a concrete example (`{"days": 7}`) and ties it to capacity planning, providing extra context beyond the schema. This justifies a small boost above the baseline.

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 clearly states it returns a 'Live shape report' on the DugganUSA STIX 2.1 threat feed with specific metrics (indicator count, malware families, source feeds, type breakdown, countries). It distinguishes itself from sibling tools by explicitly noting it does NOT return the full bundle and directs users to the full feed URL.

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?

The description opens with explicit 'CALL when' triggers (trending, freshness, SIEM planning) and instructs to use it BEFORE pulling the full bundle. It also names the alternative (fetch the bundle URL) and clearly states what the tool does not do.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 5, 2026
- Addedai-model-price

1 tool updateOct 1, 2026

Changedenrich-ioc1 field changed

changedInput schema / properties / type / enum

Previous value: -[
-  "ip",
-  "domain",
-  "url",
-  "hash",
-  "auto"
-]New value: +[
+  "ip",
+  "domain",
+  "url",
+  "hash",
+  "email",
+  "auto"
+]

1 tool updateJul 11, 2026
- Addedcheck-package
1 tool updateJul 2, 2026
- Addedkev-exploitation-stickiness
1 tool updateJul 2, 2026
- Addedkev-vendor-risk

1 tool updateMay 3, 2026

Changedenrich-ioc3 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 tool updatesMay 3, 2026
- First observedenrich-ioc
- First observedsearch
- First observedstix-feed-summary

Related MCP Connectors

Presend dependency checks A
io.github.presendapp
Check an npm/PyPI package before an AI agent installs it: 5 focused supply-chain tools.
Security Developer Tools
51
vdb A
kr.ai.vdb
Check packages for CVEs, slopsquatting, and CISA KEV before your AI agent installs them.
Security Developer Tools Testing & QA Tools
71
Package Intel MCP A
io.github.selflabbs
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Developer Tools Code Analysis
2
Package Intel MCP A
com.datakoot
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Developer Tools Code Analysis
61

Related MCP Servers

DepHealth MCP
Security Code Analysis
hasarahman
A
license
A
quality
F
maintenance
Dependency security & health auditing for AI agents with no account or API key required.
Updated 3 months ago (2026-07-04 22:58 UTC)
2
2
MIT
pkgtruth
Security CI/CD & DevOps Developer Tools
hxckya
A
license
A
quality
A
maintenance
Enables AI coding agents and CI to vet npm dependencies before they reach the lockfile, flagging hallucinated, slopsquatted, or otherwise risky packages with evidence-backed verdicts.
Updated 2 days ago (2026-10-12 10:37 UTC)
3
61 npm
4
MIT
depscope-mcp
Developer Tools Security
cuttalo
A
license
Not graded
quality
C
maintenance
Validates and checks packages across 19 ecosystems to prevent AI agents from installing hallucinated, deprecated, or malicious packages.
Updated 5 months ago (2026-05-05 02:00 UTC)
40 npm
AGPL 3.0
pkgguard
Security CI/CD & DevOps Developer Tools
rxslice
A
license
B
quality
A
maintenance
Pre-install gate for AI coding agents. Checks npm, PyPI and crates.io package names before an install runs and blocks names that do not exist, were registered after models invented them, or sit one keystroke from a popular package. CLI, GitHub Action and MCP server. Apache 2.0.
Updated 11 days ago (2026-10-03 00:32 UTC)
1
1
Apache 2.0

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

Need Help?