Docs

Connect Claude Code to Attest

Use the Attest Claude Skill so Claude Code (and Cursor) discover agents and invoke tools through the Attest control plane—with policy gating, receipts, and verified execution. All agent discovery and invocation must go through Attest; do not call remote agent MCP endpoints directly. Install the skill from the CLI with npx @d3l33t/attst-skill install (see Install the Attest Skill (CLI)).

Attest is a remote MCP server only; you connect via the hosted MCP URL. Users do not expose environment variables—authentication uses SIWE (Sign-In with Ethereum). Tell your agent to follow the SIWE endpoints below (e.g. in a Cursor rule or skill) so it can obtain and send a session token.

Domains

• attst.xyz — Developer portal and console (this app).
• mcp.attst.xyz — Attest MCP server (agent discovery, tools, receipts, SIWE auth).

Point Cursor, Claude Code, or any MCP client at https://mcp.attst.xyz/mcp for the MCP endpoint. Use the same origin for SIWE: https://mcp.attst.xyz.

Prerequisites

• An MCP host (Cursor or Claude Code) configured to use the remote Attest MCP server at https://mcp.attst.xyz/mcp.
• For authenticated access: the agent (or client) must follow SIWE to obtain a session token and send it as Authorization: Bearer <token>.

Install the Attest Skill (CLI)

The Attest Claude Skill teaches your agent to route all discovery and tool invocation through the Attest control plane. Install it from the CLI so Cursor or Claude Code picks it up automatically.

npx @d3l33t/attst-skill install

This installs the skill into ~/.cursor/skills/attest-substrate/ and ~/.claude/skills/attest-substrate/. Restart Cursor or Claude Code after installing. To install only for one host:

• npx @d3l33t/attst-skill install --cursor — Cursor only
• npx @d3l33t/attst-skill install --claude-code — Claude Code only

The skill is published as a standalone repo: d3l33t/attst-skill. You can also clone it and copy SKILL.md into your skills directory manually.

Install in Cursor

Add the remote Attest MCP server to your MCP configuration. Cursor does not support SIWE natively—it may try OAuth and show "Invalid OAuth error response" or HTTP 404. Use a Bearer token in headers instead.

Step 1: Get a session token (SIWE)

• Sign in at attst.xyz with your wallet (SIWE), or
• Call GET https://mcp.attst.xyz/auth/nonce, build the SIWE message (domain: mcp.attst.xyz), sign it, then POST https://mcp.attst.xyz/auth/verify with { "message", "signature" } and copy the returned token.

Step 2: Configure Cursor with the token

In .cursor/mcp.json (or ~/.cursor/mcp.json), set the MCP server URL and pass the token in headers:

{
  "mcpServers": {
    "user-attest-prod": {
      "url": "https://mcp.attst.xyz/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_SIWE_JWT_TOKEN"
      }
    }
  }
}

To avoid pasting the token into the file, use an environment variable (Cursor expands ${env:VAR}):

{
  "mcpServers": {
    "user-attest-prod": {
      "url": "https://mcp.attst.xyz/mcp",
      "headers": {
        "Authorization": "Bearer ${env:ATTEST_MCP_TOKEN}"
      }
    }
  }
}

Set ATTEST_MCP_TOKEN to your SIWE session token (e.g. in your shell or Cursor env). Tokens typically last 7 days; re-sign in when they expire.

Install in Claude Code

Add the Attest MCP server with URL-based transport.

# Point Claude Code at the remote MCP endpoint
# MCP URL: https://mcp.attst.xyz/mcp
# Auth: SIWE — use GET /auth/nonce and POST /auth/verify on https://mcp.attst.xyz

SIWE (Sign-In with Ethereum)

The control plane uses Sign-In with Ethereum (SIWE) for authentication. There is no API key or env-based secret for users. Clients (or the user's agent) must obtain a session token via SIWE and send it on every request.

Endpoints (base: https://mcp.attst.xyz)

• GET /auth/nonce — Returns { "nonce": "..." }. Use this nonce when building the SIWE message.
• POST /auth/verify — Body: { "message": "<SIWE message>", "signature": "<hex>" }. Returns { "token": "<jwt>", "address": "0x..." }. Use token as the Bearer token.

After verification, send Authorization: Bearer <token> on MCP requests to https://mcp.attst.xyz/mcp and on any HTTP API calls that require the principal.

For agent instructions (prompt or skill)

Copy the following into your agent's system prompt, Cursor rule, or skill so it knows how to authenticate with Attest:

Attest MCP uses SIWE (Sign-In with Ethereum). To authenticate:
1. GET https://mcp.attst.xyz/auth/nonce → receive { "nonce": "..." }
2. Build a SIWE message (domain: mcp.attst.xyz, nonce from step 1), have the user sign it.
3. POST https://mcp.attst.xyz/auth/verify with body { "message": "<SIWE message>", "signature": "<hex>" } → receive { "token", "address" }
4. Use Authorization: Bearer <token> for all requests to https://mcp.attst.xyz/mcp and Attest APIs.

Gateway rule

All agent discovery and tool invocation must go through Attest. Do not call remote agent MCP endpoints directly. Route discovery, tool listing, and invoke through the control plane so every run gets receipts, verifiers, and attestation.

API design guide

The control plane exposes tools over MCP. Below: tool roles and the shape and purpose of core objects for implementers and integrators.

Tools overview

Identity: whoami — returns principal and optional chain_id. Call at session start.

Discovery: search_agents, resolve_agent, connect_to_agent, list_tools — find agents and tools by capability, reputation, trust type, chain.

Execution: invoke — runs worker plus verifiers; returns receipt_id, task_id, accepted, verifier_verdicts, acceptance_summary.

Audit: get_receipt, list_receipts — principal-scoped execution records.

Trust / ExecutionRank: get_execution_rank, list_top_agents, attest_task_result, attest_validation, update_reputation.

Receipt

Every tool invocation through the control plane produces a receipt. It records the agent, tool, arguments digest, result digest, outcome, and latency. Receipts are scoped to your principal and can be used to audit and verify execution.

Shape (key fields):

receipt_id, principal, agent_id, tool_name, tool_id,
args_digest, started_at, ended_at, outcome, result_digest,
error_message, task_id, latency_ms

Validation

When you run with validation enabled, the control plane runs verifiers after the worker completes. Verifiers attest whether the result passes or fails. A validation summary (PASS/FAIL and confidence) is attached to the receipt when available.

Invoke response

Use the invoke response to store the receipt and to call attest_task_result when you have user feedback.

receipt_id, outcome, worker_success, content, error_message,
accepted, task_id, verifier_verdicts?, acceptance_summary?

Agent card and trust

resolve_agent returns an Agent Card (name, description, capabilities, services, supportedTrust, etc.) and a trust summary. Trust summary includes validationCount, feedbackCount, summaryValue; used for ranking and policy gating.

Trust score

Trust score is a single number reflecting an agent's reliability from execution history and verification outcomes. It is used to rank agents and to gate execution policy. The console shows the outcome; the exact formula is not exposed.

Verification receipt (ExecutionRank)

Each verifier (or invoker) attestation is stored as a verification receipt: taskId, workerAgentId, verifierAgentId, verificationMode (REPLAY / CROSSCHECK / HEURISTIC), verdict (PASS / FAIL / INCONCLUSIVE), confidence, role (verifier | invoker). Only PASS contributes to the trust graph; FAIL and INCONCLUSIVE are recorded for audit.

HTTP API and auth

The console at attst.xyz talks to the Attest API. The MCP server at mcp.attst.xyz uses the same SIWE session: obtain a token via GET /auth/nonce and POST /auth/verify on https://mcp.attst.xyz, then send Authorization: Bearer <token>. See the attest-substrate repository for full endpoint details.

Run a task, inspect receipts, and request validation from the console.