{
  "markdown": "# fips-mcp\n\nAn MCP server over the NIST CMVP data behind [808bits.com/fips](https://808bits.com/fips/):\nevery FIPS 140 cryptographic module validation, plus the queue of submissions\nstill awaiting one.\n\nRead-only, no authentication.\n\n```\nhttps://fips.808bits.com/mcp\n```\n\n```sh\nclaude mcp add --transport http fips https://fips.808bits.com/mcp\n```\n\nThe endpoint speaks POST, as the transport requires. Opening either the\nhostname or the endpoint in a browser redirects to the tracker. A client's\n`GET /mcp` still gets 405, which is what a stateless server owes a request to\nopen an SSE stream, and `GET /` and `GET /health` return a JSON descriptor with\nthe data generation dates for anything checking liveness.\n\n## Tools\n\n| Tool | Answers |\n|---|---|\n| `fips_cert` | Status, level, sunset date and validation history for one certificate number. |\n| `fips_search` | Does this vendor or product hold a current validation, and at what level. |\n| `fips_vendor` | Everything one company holds, across the spelling variants NIST filed it under. |\n| `fips_cve` | Which validated modules are associated with a CVE, and which CVEs touch a vendor's. |\n| `fips_in_process` | Has the vendor's replacement actually been submitted, and what phase is it in. |\n| `fips_sunset` | What expires before a given date, and which vendors are about to have nothing valid. |\n\n`fips_in_process` is the one with no equivalent elsewhere. NIST publishes the\nModules in Process list as a web page, not as an API, and \"it is on MIP\" is the\nmilestone people reach for when a validation has lapsed and the replacement has\nnot landed.\n\n## Reading the data without getting it wrong\n\n**A submission in the queue is a milestone, not a date.** 181 modules are in\nprocess and the phase dates run back more than a year, so plenty have sat in\none phase for longer than that. \"It is on MIP\" says review started.\n\n**An absence from the queue can mean the successor already landed.** Ribbon's\nSBC 5400 sunsets on 2026-09-06 and has held a 140-3 certificate since 2025.\nCheck `fips_search` for the module name before reporting a gap.\n\n**Vendor names are free text at NIST.** Cisco holds certificates under three\nspellings, Thales under two. `vendor_key` groups the variants of one\nregistration and `vendor_display` is the spelling NIST used most often. Neither\nmerges corporate families: the nShield line ran nCipher Corporation to Thales\nto Entrust, so folding those together would credit certificates to a company\nthat sold the product years ago.\n\n**112 certificates have no module name or vendor,** because NIST published\nnone. Those come back as `null` with a note rather than as empty strings.\n\n**CVE associations are name-based, not boundary-based.** They come from\nmatching the vendor and product CPE, so a listed CVE may sit in code the\ncertificate never covered, and a real flaw inside the boundary may not appear\nat all. 183 associations across 16 certificates.\n\n**An empty CVE result is not a clean bill of health,** and this is the more\nmisleading direction. Only 16 of 5,504 certificates carry any association, the\nmatch does not follow dependencies, and it needs a stable CPE string, so\nhardware modules come back empty largely regardless of their advisory history.\n`fips_cve` for CVE-2014-0160 returns nothing. Every empty result says so, and\nreports how many certificates carry any association at all, so the number is\nin front of the caller rather than in this file.\n\n**Sunset dates are not uniform.** Most active 140-2 certificates move to the\nhistorical list on 2026-09-21, but six carry earlier dates of their own.\n\n## Where the data comes from\n\nEverything is derived from NIST's published CMVP lists: the validated modules,\nthe historical and revoked lists, and the Modules in Process queue. The server\ndoes not scrape NIST on demand. A separate pipeline snapshots the lists, diffs\nthem against the previous snapshot and loads the result, so answers reflect the\nlast refresh rather than this minute. Every response carries the generation\ndate, and `GET /` reports it too.\n\nThis repository holds the server. The dataset it serves is built elsewhere and\nis not checked in, so a clone will typecheck and deploy but will not have rows\nto answer with.\n\n## Licence\n\n[MIT](LICENSE). The certificate data itself is published by NIST and is not\ncovered by it.\n",
  "bytes": 4328,
  "sha": "f2985fb588ea1429267ed198748fe6f9e3e55d6d8b559375543ecaac59e82cd9",
  "repo_slug": "808bits/fips-mcp",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_com_808bits_fips_cmvp_5b5250c8/readme"
}