The Blockquote MCP server is a remote endpoint that lets any AI agent scan a URL for AI citability and read the full report.

How do you connect an AI agent to Blockquote?

Pick your client, paste one block, done. The server is remote — nothing to install, nothing to run locally — and follows the MCP specification's Streamable HTTP transport, so every current MCP client connects with a URL alone. The Authorization header is optional everywhere: leave it off for anonymous free scans, add it to act as your account.

# Claude Code — one command, no config file
claude mcp add --transport http blockquote https://mcp.blockquote.io/mcp

# with an API key (Pro/Agency):
claude mcp add --transport http blockquote https://mcp.blockquote.io/mcp \
  --header "Authorization: Bearer bq_YOUR_KEY"

In Claude Desktop and claude.ai, add the endpoint as a custom connector (Settings → Connectors → Add custom connector) with the URL https://mcp.blockquote.io/mcp — the MCP quickstart for users shows the flow. ChatGPT takes the same URL as a connector in developer mode. Cursor and VS Code read a JSON file:

// Cursor (~/.cursor/mcp.json) and VS Code (.vscode/mcp.json) — same shape:
{
  "mcpServers": {
    "blockquote": {
      "url": "https://mcp.blockquote.io/mcp",
      "headers": { "Authorization": "Bearer bq_YOUR_KEY" }
    }
  }
}

No MCP client at hand? The endpoint is plain JSON-RPC over HTTP, and the report has a first-class Markdown form over REST — both are one curl away:

# Any HTTP client — plain JSON-RPC against the endpoint:
curl -X POST https://mcp.blockquote.io/mcp \
  -H "content-type: application/json" \
  -H "accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"start_scan","arguments":{"url":"example.com"}}}'

# The whole report as one Markdown document, over plain REST:
curl -H "Accept: text/markdown" https://blockquote.io/api/v1/scan/SCAN_ID

After connecting, tell the agent what you want in plain language — "scan example.com and tell me the three highest-impact fixes" triggers start_scan, the poll, and the markdown read on its own. The server also ships the analyze_report prompt, which encodes exactly that instruction for clients with prompt support.

What tools does the MCP server expose?

Nine tools. start_scan dispatches a scan of a public HTTPS URL and returns a scan id immediately — a report cached within the last 24 hours returns as done at once. get_scan fetches status and report in three sizes: summary is the default and carries the score, per-category scores and the top five recommendations; markdown returns the entire report as one document; full returns the complete report JSON. list_checks and explain_check serve the catalog of all 34 checks with what each measures and its typical fix. get_account reports plan, limits and used scans for an API key. compare_scans diffs two finished scans of one URL — score and category deltas, every check whose verdict flipped, and recommendations split into resolved, new and still open — as JSON or as one Markdown section. list_monitors, add_monitor and remove_monitor maintain the account's weekly watchlist, within the monitor allowance of the account's plan — list_monitors returns that allowance as limit.

Beyond tools, the server ships two prompts — analyze_report walks an agent through evaluating every single result of a finished scan, fix_top_issues through applying the highest-priority fixes and re-scanning — and three resources: the check catalog, the live llms.txt, and a per-scan report template. A typical session is three calls: start_scan, a short poll on get_scan, then one markdown read.

Do you need an API key?

No for scanning, yes for everything account-shaped. Anonymous MCP calls run free scans under the same per-IP limits as the website — 1 scan per day and 3 per month — and see the anonymous report tier, which keeps the first recommendation in full and locks the rest by title. That is deliberately the lowest possible hurdle: an agent can connect and produce a scored report without any signup.

An API key — a bearer token starting with bq_, sent as Authorization: Bearer — authenticates the calls as your account. That switches metering to your plan's quotas, applies the full fix list in every view including markdown, enables refresh (skipping the 24-hour cache), and answers get_account. Keys are available on the Pro and Agency plans, created on the account page, shown exactly once, and revocable at any time; an account holds at most 5 keys you create yourself, and connected apps do not count against that. Each key is created with a scope: reports only, scans and reports (the default), or scans, reports and monitors. The scope is fixed for the life of the key. Key management stays session-only — no key reaches it, whatever its scope. Deleting stored scan history works the same way: no key reaches it either, including one created before scopes existed. Billing and webhook configuration refuse every key the account page issues today; a key created before scopes existed still reaches them until it is rotated.

How does an agent get the whole report at once?

Ask for Markdown. get_scan with view markdown returns the complete report as a single document: the score and verdict, the category table, every recommendation ordered by the score points its fix recovers, with its ready-to-paste fix payload, and all 34 checks with their evidence lines. One tool call, one read, no pagination — that is the format built for handing an entire audit to a model in one go.

The same document exists over plain HTTP: request GET /api/v1/scan/{id} with the header Accept: text/markdown and the API answers text/markdown instead of JSON. The JSON default is unchanged, so browsers and existing integrations notice nothing. The analyze_report prompt bundles this into a working instruction: fetch the markdown, group failures by category, explain each one's effect on citability, and end with the three changes with the biggest expected score impact.

How are anonymous requests limited?

Three layers, all counted against the calling agent's IP address, which the MCP server forwards to the scoring backend. The per-IP scan limits are 1 per day and 3 per month — identical to anonymous scans on the website. The MCP endpoint itself additionally caps total requests per IP per hour, so the cheap catalog tools cannot be hammered either. And an account-wide daily budget bounds total spend across all callers.

There is no CAPTCHA anywhere in this path. Human-verification widgets are unsolvable for headless agents by design, so the MCP relay authenticates itself to the backend instead and passes the real client IP through for metering. Hitting a limit returns a structured error with the retry delay, so a well-behaved agent backs off exactly as long as needed.

What is WebMCP, and when does the site register in-page tools?

WebMCP is a W3C proposal that lets a web page register callable tools directly in the browser via document.modelContext, so browser-based agents interact with the page through typed functions instead of screen-scraping. Blockquote ships this as progressive enhancement: on browsers that expose the API, the homepage registers a scan tool wired to the same form a human uses, and report pages register tools that read the score and the full Markdown report. Browsers without the API see no difference.

Cloudflare runs a related developer preview that can attach WebMCP tool packs to a site from the dashboard, including a pack that proxies a site's own remote MCP server into the browser. Both tracks are previews — Chrome-only as of 2026 — which is why the remote MCP server, reachable from every client today, is the foundation and WebMCP is the bonus layer on top.

What exists beyond MCP?

The plain REST API, described by an OpenAPI 3.1 document at /api/v1/openapi.json with a reference UI at /api/v1/docs. POST /api/v1/scan starts a scan, GET /api/v1/scan/{id} polls and returns the report as JSON or Markdown, GET /api/v1/scan/{id}/events streams live progress as server-sent events, and GET /api/v1/account/usage reports quota state. Everything the MCP tools do maps onto these routes — the MCP server is a protocol adapter, not a second product.

One difference matters for an agent: POST /api/v1/scan is the anonymous path for browsers, and it is gated by a Cloudflare Turnstile challenge that only a browser can answer. Send an API key, or use MCP, which needs neither. A REST scan without either answers 403 turnstile_failed, and that body carries the MCP endpoint, the start_scan tool and this page — so an agent that hits the wall can read its way out of it.

For recurring automation, the Agency plan adds signed webhooks: every weekly monitor result is POSTed to your endpoint, which can hand the report to an AI workflow that fixes your site — the continuous-optimization guide documents that loop end to end, including receiver code for common hosting providers.

What is on the roadmap for agent access?

OAuth is the next authentication layer: the MCP specification standardizes an OAuth 2.1 flow, and Cloudflare's provider library implements the server side on Workers, so a future version will let an agent request access interactively instead of pasting a key. API keys remain supported — they are the right shape for CI and headless automation.

Further out sits machine-payable scans via the x402 payment protocol. The concept document in the repository tracks these phases; none of them changes the tools shipped today, which are additive by design.

Where is the rest of the machine-readable surface?

Everything an agent needs links from here: the llms.txt summarizes the product and its access policy per the llms.txt convention; the OpenAPI reference describes every REST route; the webhook reference covers signed weekly deliveries; and the continuous-optimization guide turns all of it into a closed monitor → agent → pull-request loop. The MCP endpoint itself is built on Cloudflare's Agents SDK and the WebMCP proposal tracks the in-browser side. The scan itself, the scoring weights and the check thresholds are documented in the LLM-friendly content playbook.