Feedback wanted: lookup.disclose.io — new MCP server + API, and where it still gets attribution wrong

Ideas
1

Vulnerability coordination is in the process of changing shape. People still find the bugs and decide what’s worth reporting — but the plumbing that carries a finding to the right inbox is getting more programmatic, through APIs, integrations, and MCP. The first question of every report hasn’t moved, though: whose asset is this, and who do I even tell? Get that wrong by hand and you usually catch it; bake the wrong answer into a tool or a pipeline and it stays wrong, quietly, for everyone who relies on it.

lookup.disclose.io is the contact layer for that problem: give it almost any asset — a domain, IP, ASN, package, repo, container, app, a piece of hardware down to an FCC ID, or just a company name — and it returns the right security channel (security.txt, bug bounty, VDP, PSIRT, or a national CERT). It never invents a contact.

What’s new since launch:

  • A hosted MCP server, now in the official registry as io.github.disclose/lookup-disclose-io. One line in Claude Code: claude mcp add --transport http lookup https://lookup.disclose.io/mcp
  • A JSON API — POST /api/lookup, OpenAPI 3.1, plus an llms.txt so a coding agent wires in from one file. Free and anonymous; email hello@disclose.io for a key if you need volume.
  • A hard push on attribution accuracy — killing the cases where naive attribution lands confidently wrong (an npm package routed to the wrong company via a maintainer’s email domain; a PyPI package attributed to GitHub the host instead of its real maintainer; a hardware ID resolved to a fabricated contact that never existed). Each is now a regression test. The full write-up has the details.

This is the ask. lookup is useful today and wrong sometimes, and we’d rather hear about the wrong from you. Three questions in particular:

  1. Are we getting you to the right places? When you looked something up, was the contact it returned correct — and when it wasn’t, what was the right answer? Wrong and missing answers help most.
  2. What input types are we missing? Sixteen covers a lot, not everything. What did you want to paste in and couldn’t?
  3. Where would you wire it in? Caido, Burp, a ProjectDiscovery/Nuclei pipeline, a SOAR playbook, your own assistant — tell us, or just build it.

Want to build it into Caido, Burp, a ProjectDiscovery/Nuclei pipeline, or your own agent? The API, the MCP server, and the dio-lookup CLI (plus caido-lookup and burp-lookup) are all there to build on.

Full post: Feedback Requested: Coordination is going API-first. Contact Discovery and Attribution still aren't solved.

Reply below with the asset that stumped you — that’s the most useful thing in this thread. Know someone who spends their afternoons hunting for the right inbox? Send them the link.

Lookup.disclose.io — MCP server, API, and new tool integrations
2

I was thinking that the lookup API would include likely CNAs that cover a given area, including providing hierarchical CNA information (e.g., who the root CNA is for a given CNA). Often folks who are looking to disclose are trying to get a CVE allocated, and knowing who has the operational scope to do so would be useful information. Explicitly collecting and presenting the written operational rules for a given CNA may also be useful. E.g., some CNAs decline to allocate CVEs for end-of-life products, or for low severity impact issues.

3

@msw this is a great steer — thank you. And it’s a genuinely different question from the one lookup answers today, which is exactly why it’s worth getting right.

Right now our backstop is geographic: when there’s no vendor channel, we fall through to the national CERT / CERT-CC. What you’re describing is a scope-based backstop — who holds the operational authority to allocate a CVE — and that’s a separate axis. A vendor that’s its own CNA is usually already reachable via their security.txt / PSIRT; the value you’re pointing at is (1) CVE-allocation routing when the discloser specifically wants an ID, and (2) a coordinator of last resort when the vendor is unreachable, walking the hierarchy up to the Root and ultimately the CNA-LR.

The encouraging part: MITRE publishes this as a machine-readable list (CNAsList.json) with exactly the fields that make your ask tractable — each entry carries its scope text, its disclosurePolicy link (where the EOL / low-severity decline rules you mentioned actually live), and its place in the tree (isRoot / root / TLR). So “surface the covering CNA, its written rules, and the escalation path” is buildable without inventing anything — same primary-source-or-nothing bar as the rest of lookup.

How we’re thinking about the shape: a resolution step hung off the org we already resolve (so it reaches every input type through the existing chains), emitting a distinct CNA channel in the coordinator tier — ranked above the generic national-CERT floor because it’s scope-specific and CVE-actionable, but never above the vendor’s own published channel, and not double-counted when the vendor is the CNA. The breadcrumb we’d show a discloser: CNA (scope) → Root → TLR, or → CNA-LR when nothing else has scope.

Two things would genuinely help us prioritize:

  1. Which is the higher-value piece for you — the specific-CNA match (this product → this CNA + its written rules), or the CNA-LR fallback (nobody else has scope → here’s who allocates by default)?
  2. Where would you want it surfaced first — as structured cnaRouting in the API / MCP response, in the web result, or both? You flagged pipelines earlier, so I’d guess structured-first.

Really appreciate you pushing on this — misrouting a CVE request is a subtle, high-cost way to be wrong, so the shape matters more than the speed here.