MCP Server — Developer Setup

1. Claude API connector (recommended)

Pass the server in the Messages API's mcp_servers block — the key rides authorization_token:

{
  "mcp_servers": [
    {
      "type": "url",
      "url": "https://dutydrawback.ai/api/mcp",
      "name": "drawback",
      "authorization_token": "dk_live_YOUR_KEY"
    }
  ]
}

2. Claude Code

claude mcp add --transport http drawback https://dutydrawback.ai/api/mcp \
  --header "Authorization: Bearer dk_live_YOUR_KEY"

Then /mcp shows the connection and tools/list the 14 tools.

3. Any MCP client

Point a Streamable-HTTP client at https://dutydrawback.ai/api/mcp and send Authorization: Bearer dk_live_… on every request. Unauthenticated requests receive a spec-standard 401 challenge. Read-only keys can call every read tool; mutating tools (upload_file, validate_file, run_analysis, cancel_job, generate_report, generate_abi) need the write scope.

claude.ai custom connectors are a named future slot — they GA on OAuth; this server will add the RFC 9728 metadata when that lands.

Limits and scopes

• Rate limits. Mutating tools are limited to 100 calls per 60 seconds with a burst of 20, per client; read tools are exempt. A limited call answers 429 with a retry-after header, and the tool error text repeats the wait ("Rate limited. Retry after N seconds.") so an agent can back off.
• Scopes. Only the write scope is inspected; read access is implicit, so a key created without write can call every read tool and nothing else.
• Denylist. API keys are refused on /api/v1/auth/* (except /api/v1/auth/introspect, which whoami uses) and on /api/v1/api-keys — keys are created, rotated, and revoked in the portal, never by another key.
• Failure reasons. A job that fails reports status: failed through get_job; the reason itself currently reaches clients only through the backend's webhook payloads.

Tools

Typical flow: upload_file → run_analysis → wait_for_job → get_job_results → generate_report or generate_abi.