Jeevesus — DugganUSA threat-intel MCP

Looks up what an AI model or an agent session costs at list price. Prices are dated and copied from each provider's own pricing page. 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. Public read (no auth).

Checks whether a dependency (npm, PyPI, RubyGems or Packagist/Composer, or a GitHub Action used in a workflow) is on the DugganUSA malicious-package deny-list or has published advisories. Suited to a pre-install step in an agent or a CI pipeline, against slopsquatting and hijacked-package attacks. 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 (230k+ named-not-heuristic entries across npm + PyPI + RubyGems; RubyGems coverage is thin and Packagist has NO deny-list entries at all, so on those two the OSV lookup and reputation signals are the whole check). `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. One tool call, no auth. Examples: {"ecosystem":"npm","name":"cxp-jquery"} → malicious:true, verdict:block. {"ecosystem":"pypi","name":"requests"} → malicious:false, verdict:allow. {"ecosystem":"rubygems","name":"rest-client","version":"1.6.13"} → RubyGems check, version-scoped. {"ecosystem":"github-actions","name":"tj-actions/[email protected]"} → owner/repo@ref (or name owner/repo + version); the 2025 compromise advisory makes this verdict:review. Pin a full commit SHA for the strongest check.

Before you open or run a repository someone else sent you (a recruiter's coding test, a downloaded zip, a proof of concept), pass it the few files that matter and get a verdict. It looks for the places a lure hides that a dependency check never reads: npm install hooks that fetch or evaluate code, a VS Code task set to run when the folder opens, agent hooks and MCP servers in .claude, .cursor and .mcp.json, dev container lifecycle commands (initializeCommand runs on your own machine), yarnPath and foreign npm registries, git or URL dependencies, source that decodes and evaluates a payload, and setup.py that fetches or executes. Prompted by the 2026-10-29 Binance theft, where a compromised engineer's laptop is the first account and fake recruitment coding tests are the documented route of the group blamed. Static and local: nothing is fetched, run or stored. Pass { "files": { "<path>": "<file text>" } } with at most 40 files and 28000 characters in total (package.json, .vscode/tasks.json, .claude/settings.json, .mcp.json, .devcontainer/devcontainer.json, .yarnrc.yml, .npmrc, setup.py and any suspicious script). For a whole directory use the command line scanner or the DugganUSA Checks GitHub Action. Returns {verdict:"block"|"review"|"no-findings"|"unknown", findings:[{rule, severity, verdict, file, line, evidence, message, fix}], coverage, note}. "no-findings" means none of the listed patterns were seen in the files you sent; it does NOT mean the repository is safe. "unknown" means nothing was analyzed. Read the code on a machine that holds no credentials before you run it. One tool call, no auth.

Checks the text of one GitHub Actions workflow file for script injection: places where text an outside user controls (an issue or pull request title or body, a comment, a branch name, a commit message) is pasted into a shell script or a github-script body, a privileged trigger that checks out a pull request's code, event text re-evaluated through eval, an externally triggerable workflow with open token permissions, and an AI agent action on such a trigger. Built from Radware's 2026-10-29 report of 83 hidden-command attacks on 61 public repositories. Static and local: nothing is fetched, run or stored. Pass the workflow's YAML as text (max 28000 characters; use the DugganUSA Checks GitHub Action for whole repositories). Returns {verdict:"block"|"review"|"advisory"|"no-findings"|"unknown", findings:[{rule, severity, verdict, line, expression, message, fix}], coverage, note}. "no-findings" means none of the listed patterns were seen; it does NOT mean the workflow is safe. "unknown" means nothing was analyzed. One tool call, no auth.

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

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.

Measures whether a product's exploitation risk is chronic or a one-off, for patch prioritization. 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 result is computed live: it reports rho, the repeat-offender versus first-time split, the share concentrated in the 20 most-exploited products, and an `interpretation` sentence. This is product-level stickiness, a proxy for exploitation dynamics, not proof of exploit timing. Public read (no auth). Pass {"days": N} for the recent window (30-720, default 180).

Shows where confirmed exploitation concentrates for a vendor or product (Microsoft, Cisco, Fortinet, an appliance, an ERP), for questions like "what should I patch first". 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 known-exploited CVEs (e.g. ColdFusion), most recent first, up to 50, each with a ransomware-use flag (Known or Unknown); `kev_count` is the full total and `truncated` says whether the list was cut. Answers "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, synced daily. Example: {"vendor":"Citrix"} → NetScaler's known-exploited CVEs; {} → the full top-vendor risk ranking.

Searches threat-intelligence records about threat actors, malware, campaigns, CVEs, breaches, vendors and indicators. The default search covers security topics only; a few public-document archives can be searched by naming them (listed below). It holds no general programming or web content. Hybrid (keyword + semantic) search across the DugganUSA threat-intelligence corpus (live counts: /api/v1/search/stats). Read-only, prompt-injection sanitized. Returns up to 25 hits, each with index, id, title, snippet, source, timestamp and url (null where the record has none), plus `returned` (hits in this response) and `indexes_unanswered` (any index that timed out). No total match count is given. Searched by default: • iocs (indicators of compromise: IPs, domains, URLs, hashes, packages, with actor attribution) • adversaries (366 threat-actor profiles) • cisa_kev (CISA's Known Exploited Vulnerabilities catalog, synced daily) • pulses (OTX community pulses) • blog (1,800+ DugganUSA threat-intel research posts) Searched only when named in `indexes` (public research archives, not threat intel): • epstein_files (public Epstein court and DOJ documents) • the_finders and bishop_accountability (public abuse-accountability archives) • paranormal (fringe-research documents) Examples: query="ClearFake" → returns the Apothecary/ClearFake records and the related research post. query="ShinyHunters" indexes="iocs,adversaries,blog" → the UNC6040 actor across indicators, its adversary profile and research posts. query="CVE-2026-31431" → the Linux kernel KEV entry plus public proof-of-concept repositories we have collected.

Summarizes what is in the feed right now: useful for "what's active this week", feed freshness, or planning SIEM / blocklist ingestion. Shape report on the most recent 5,000 indicators in the DugganUSA STIX 2.1 feed, bounded to a 1-7 day window. Returns how many of those fall in the window (capped at 5,000), the top malware families or list labels (feeds such as Spamhaus DROP label by list, not family), top source feeds, a breakdown by indicator type, and top countries when the records carry one. Useful before pulling the full STIX bundle, to gauge feed depth and freshness, plan a SIEM ingestion budget, or check that a campaign is in the corpus. Does not return the full bundle (STIX 2.1 / TAXII 2.1), which is at bundle_url in the response and needs an API key. Public read (no auth), cached for 10 minutes. The full bundle needs a free API key. Example: `{"days": 7}` returns the last week's feed shape — useful for capacity planning and spot-checking recent ingest tags.