integrations / mcp

MCP server

The official Model Context Protocol server for Attestd. Once connected, Claude Code and Cursor gain native access to CVE risk and supply-chain integrity checks for every dependency decision. No plugin, no wrapper code, no custom tool definition.

Two transports, same two tools. Hosted HTTP at mcp.attestd.io is the recommended path. No Node.js required. Works in Claude Code, Cursor, or any HTTP-based MCP client. The stdio npm package @attestd/mcp is available for local use and runs as a child process.

Hosted MCP is listed on Smithery for agent marketplace discovery and one-click connect flows.

hosted mcp

Connect to mcp.attestd.io

Point your MCP client at https://mcp.attestd.io/mcp with your API key in the Authorization header. No local install required. Works in Claude Code, Cursor, and any other HTTP-based MCP client.

Get an API key from the portal.
Add the block below to ~/.claude/mcp.json or project .mcp.json.
Restart your MCP client. Both Attestd tools appear automatically.

~/.claude/mcp.json

{
  "mcpServers": {
    "attestd": {
      "url": "https://mcp.attestd.io/mcp",
      "headers": {
        "Authorization": "Bearer your-api-key-here"
      }
    }
  }
}

All requests to /mcp require an Authorization: Bearer atst_... header. The /health endpoint is unauthenticated.

stdio (local)

Local stdio via npx

Spawns @attestd/mcp as a local child process. Requires Node.js 18+. npx downloads the package on first run; subsequent starts use the npx cache.

~/.claude/mcp.json

{
  "mcpServers": {
    "attestd": {
      "command": "npx",
      "args": ["-y", "@attestd/mcp"],
      "env": {
        "ATTESTD_API_KEY": "your-api-key-here"
      }
    }
  }
}

tools

Available tools

`check_package_vulnerability`

Calls /v1/check and returns structured CVE and supply-chain data. Requires an API key (hosted: Authorization header; stdio: ATTESTD_API_KEY env).

Argument	Description
`product`	Infrastructure slug or monitored package name. Use `list_covered_products` if unsure. Examples: `nginx`, `postgresql`, `litellm`, `log4j`.
`version`	Exact version string: `1.20.0`, `2.14.1`, `1.82.7`.

`list_covered_products`

Returns all 350 covered infrastructure products (slug + display name). Static list bundled with the server. No API call made. Use this when the product slug is uncertain before calling check_package_vulnerability. PyPI/npm packages monitored for supply-chain are not listed here. Call check_package_vulnerability directly and handle outsideCoverage: true as unknown risk.

response examples

What Claude sees

Each tool call returns a single JSON text item. Claude branches on these fields to make deployment decisions.

Critical CVE with active exploitation (log4j 2.14.1)

json

// Claude calls: check_package_vulnerability({ product: "log4j", version: "2.14.1" })
{
  "outsideCoverage": false,
  "riskState": "critical",
  "activelyExploited": true,
  "patchAvailable": true,
  "fixedVersion": "2.16.0",
  "supplyChainCompromised": false,
  "supplyChainDescription": null
}

Supply chain compromise (litellm 1.82.7)

json

// Claude calls: check_package_vulnerability({ product: "litellm", version: "1.82.7" })
{
  "outsideCoverage": false,
  "riskState": "none",
  "activelyExploited": false,
  "patchAvailable": false,
  "fixedVersion": null,
  "supplyChainCompromised": true,
  "supplyChainDescription": "Malicious publish detected on PyPI: version 1.82.7 contains..."
}

Product outside coverage

This is not a safety signal. Attestd has no data for this product. Treat the risk as unknown.

json

// Claude calls: check_package_vulnerability({ product: "wordpress", version: "6.4.2" })
{
  "outsideCoverage": true,
  "riskState": null,
  "message": "No Attestd coverage for 'wordpress'. Treat as unknown risk, not safe."
}

list_covered_products

json

// Claude calls: list_covered_products()
{
  "count": 350,
  "products": [
    { "slug": "nginx",      "display": "NGINX" },
    { "slug": "postgresql", "display": "PostgreSQL" },
    { "slug": "redis",      "display": "Redis" },
    // ... 350 total
  ]
}

return fields

Field reference

Field	Semantics
`outsideCoverage`	true when Attestd has no CVE data for this product. Unknown risk. Do not treat as safe.
`riskState`	"critical" \| "high" \| "elevated" \| "low" \| "none" \| null when outside coverage. Block on critical or high.
`activelyExploited`	true if the version is in the CISA KEV catalog. Hard block regardless of riskState.
`patchAvailable`	true if a clean version is known. Pair with fixedVersion to tell Claude what to recommend.
`fixedVersion`	Earliest version with no known critical/high CVEs. null when no patch exists yet.
`supplyChainCompromised`	true if a malicious publish or integrity event was detected on PyPI or npm. Hard block.
`supplyChainDescription`	Human-readable description of the supply-chain event when present.
`error`	Present when the tool returns isError: true, for example a bad key, rate limit, or missing arguments.

system prompt

Recommended system prompt

Include this in the Claude Code project or global system prompt to make the deployment-gate policy explicit. Without it, Claude may treat outsideCoverage: true as if there were no known vulnerabilities, which is incorrect.

text

You are a security-aware deployment assistant with access to the Attestd MCP server.

Before approving any software dependency, infrastructure component, or package version:
1. Call check_package_vulnerability with the product slug and exact version.
2. Block deployment if riskState is "critical" or "high".
3. Block immediately if activelyExploited is true, regardless of riskState.
4. Block immediately if supplyChainCompromised is true.
5. If outsideCoverage is true, state explicitly that the risk is UNKNOWN. Do not treat it as safe.
6. If patchAvailable is true, include fixedVersion in your recommendation.

Use list_covered_products if you are unsure whether a product slug is supported.

workflow

Example: dependency review

A developer asks Claude to review a requirements.txt or Dockerfile before deploying. Claude reads the file, calls check_package_vulnerability for each dependency, and synthesises a go/no-go decision.

bash

# Example: Claude Code reviewing a Dockerfile or requirements.txt

User: "Review my dependencies before I deploy"

# Claude will:
# 1. Parse the dependency list from the file
# 2. Call check_package_vulnerability for each item
# 3. Synthesize a security report

# For a requirements.txt containing:
#   litellm==1.82.7
#   nginx==1.20.0

# Claude calls:
check_package_vulnerability(product="litellm", version="1.82.7")
# → supplyChainCompromised: true  ← BLOCKED

check_package_vulnerability(product="nginx", version="1.20.0")
# → riskState: "high"             ← FLAGGED

# Claude output:
# "I cannot approve this deployment. litellm 1.82.7 has a confirmed supply-chain
#  compromise. nginx 1.20.0 has a high risk state. Upgrade to 1.27.4 (riskState: none).
#  Remove litellm 1.82.7 entirely; no safe version is available at this time."

The same pattern applies to CI pipelines, pull request reviews, and infrastructure audits. Claude will call the tool proactively whenever a dependency or version appears in context.

verify

Verify the server works

Hosted MCP health check:

bash

# Health check (no auth required)
curl https://mcp.attestd.io/health
# → {"status":"ok"}

# Quick tool list (replace with your key)
curl -X POST https://mcp.attestd.io/mcp \
  -H "Authorization: Bearer atst_..." \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

For local stdio, send a raw JSON-RPC tools/list request over stdin:

bash

# Build and verify locally (requires Node 18+)
npm install -g @attestd/mcp   # optional: pin a version globally
# or just use npx (no install needed):
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' \
  | ATTESTD_API_KEY=your-key npx -y @attestd/mcp

Both tools, check_package_vulnerability and list_covered_products, should appear in the response.