integrations / claude-code

Claude Code

Attestd works with Claude Code via the Model Context Protocol. Once configured, Claude Code checks any npm, PyPI, or infrastructure dependency for CVE risk and supply chain compromise as part of its normal tool-use flow. The hosted server at mcp.attestd.io requires no local install.

setup

Connect Attestd to Claude Code

Claude Code reads global MCP config from ~/.claude/mcp.json. The hosted server is the recommended option.

Get an API key from the portal.
Add the block below to ~/.claude/mcp.json. Create the file if it does not exist.
Restart Claude Code. All three Attestd tools appear automatically.

~/.claude/mcp.json

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

cli alternative

CLI alternative

You can also add the server using the Claude Code CLI. Verify the exact command syntax against Claude Code documentation before publishing to your team.

bash

# Verify syntax against Claude Code documentation before publishing
claude mcp add attestd \
  --transport http \
  --url https://mcp.attestd.io/mcp \
  --header "Authorization: Bearer your-api-key-here"

stdio (local)

Local stdio via npx

For local execution, use the stdio npm package. Requires Node.js 18+.

~/.claude/mcp.json

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

system prompt

System prompt

Add this to your Claude Code project settings (for example, in CLAUDE.md) or your global system prompt. Without it, Claude Code may have the tool available but not call it unprompted when a dependency comes up in conversation.

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. When reviewing multiple packages at once, use check_batch_vulnerabilities (up to 100 per call) instead of looping check_package_vulnerability.
2. For a single package, call check_package_vulnerability with the product slug and exact version.
3. Block deployment if riskState is "critical" or "high".
4. Block immediately if activelyExploited is true, regardless of riskState.
5. Block immediately if supplyChainCompromised is true.
6. Block or warn immediately if typosquat.detected is true. Treat kind "hallucination" as an AI-invented or conflated package name; prefer the resembles / likely_intended names instead of installing the requested name.
7. If outsideCoverage is true and typosquat is null, state explicitly that the risk is UNKNOWN. Do not treat it as safe.
8. If patchAvailable is true, include fixedVersion in your recommendation.

Use list_covered_products if you are unsure whether an infrastructure slug is supported (live catalog when the MCP server has an API key).
Use get_cve_details when you need CVSS, EPSS, or KEV context for a specific CVE after a check flags it.

what happens

What Claude Code does with Attestd

When you mention a dependency, “should I install this,” “is this version current,” “review my requirements.txt before I commit,” Claude Code calls check_package_vulnerability. The response fields (riskState, activelyExploited, supplyChainCompromised) are categorical. Claude Code reads them and states the answer directly rather than reasoning about a CVSS score.

verify

Verify the connection

Ask Claude Code to call list_covered_products. With an API key configured, it returns live catalog data from GET /v1/products. Without a key, it returns the static bundled infrastructure count. For a direct server health check:

bash

curl https://mcp.attestd.io/health
# → {"status":"ok","attestd":{...}} when upstream API is reachable