MCP server

Endpoint

https://rtblint.org/mcp

Listed on Smithery as aleksander/rtblint. Machine-readable card: /.well-known/mcp/server-card.json.

The server speaks JSON-RPC 2.0 over HTTP: POST a request and the response comes back in the body. Bare GET with a JSON Accept returns a short descriptor so crawlers and Smithery do not hang. SSE opens only when Accept includes text/event-stream. It is stateless (no session ids, no Durable Objects), CORS-open, and runs on the same Cloudflare Worker that serves this site. Validation happens in a WebAssembly build of rtblint-core at the edge; the default version is the latest tracked 2.6 snapshot.

Tools

The version argument accepts any tracked OpenRTB version id (call list_openrtb_versions for the set). Findings mirror the tester exactly: a stable rule id, a severity, a message, and the JSON path that tripped it.

AdCP discovery

RTBlint answers AdCP capability discovery at release 3.1. An agent that finds the endpoint can ask what it is before calling it, rather than having the integration hardcoded by whoever wired it up:

{
  "status": "completed",
  "adcp_version": "3.1",
  "adcp": {
    "major_versions": [3],
    "supported_versions": ["3.1"],
    "idempotency": { "supported": false }
  },
  "operator": { "name": "rtblint", "domain": "rtblint.org" },
  "supported_protocols": ["measurement"],
  "experimental_features": ["measurement.core"],
  "measurement": {
    "metrics": [
      { "metric_id": "openrtb_error_count", "unit": "count", ... },
      { "metric_id": "openrtb_warning_count", "unit": "count", ... },
      { "metric_id": "openrtb_conformance_rate", "unit": "percent", ... }
    ]
  }
}

The declaration is deliberately narrow. RTBlint does not plan, negotiate or deliver, so it claims none of the transactional protocols: declaring one commits an agent to that protocol's compliance storyboard, and claiming media_buy to look better populated would be a claim it cannot pass. What it does do is compute quantitative properties of a bid-stream payload, which is what the experimental measurement protocol describes. The three metric ids are the numbers validate_bid_request and validate_bid_response already return.

Version pinning is enforced rather than ignored. A caller that pins a release this agent does not serve gets a typed VERSION_UNSUPPORTED carrying the releases that would work, so it can re-pin without a second round trip. That handshake is the thing the bid stream itself still lacks, which we wrote about in the version negotiation post. Field-level mapping between an AdCP media buy and the request it becomes is in AdCP to OpenRTB.

Connect from Claude Code

claude mcp add --transport http rtblint https://rtblint.org/mcp

Then ask it to validate a bid request and it will call the tool directly.

Connect from Claude Desktop, Cursor, and others

Clients with native remote MCP support:

{
  "mcpServers": {
    "rtblint": { "url": "https://rtblint.org/mcp" }
  }
}

Older clients can reach the same endpoint through the mcp-remote bridge:

{
  "mcpServers": {
    "rtblint": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://rtblint.org/mcp"]
    }
  }
}

Call it directly

The endpoint is plain JSON-RPC, so you can exercise it with curl:

curl -s https://rtblint.org/mcp \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "validate_bid_request",
      "arguments": { "payload": "{\"id\":\"1\",\"imp\":[]}" }
    }
  }'

Run it locally over stdio

For a local, offline setup, the same tools ship as the rtblint-mcp crate, a stdio MCP server that needs no network:

cargo install rtblint-mcp

# then point an MCP client at the "rtblint-mcp" command over stdio

Prefer the browser or a pipeline instead? See the tester and the CLI and library.