MCP endpoint

Guardr answers the Model Context Protocol at https://api.guardr.io/mcp. An agent such as Claude Code or Cursor connects once with your API key, then calls Guardr as tools rather than as raw HTTP requests. Every tool runs as the holder of that key, so an agent reads exactly what the REST API returns for the same account.

1 - What the endpoint is

One address answers the protocol. It takes POST requests carrying the same X-API-Key header the REST API takes. Nothing else is needed: the endpoint mints no session identifier, keeps no state of its own and reads nothing the REST API does not already read.

• Address - https://api.guardr.io/mcp
• Transport - streamable HTTP. A GET or a DELETE answers 405.
• Key - the X-API-Key header, the same key the REST API takes
• Tools - check_site, list_sites and get_site

2 - Connect your agent

Claude Code

One command registers the endpoint. Run it in any project:

claude mcp add --transport http guardr https://api.guardr.io/mcp --header "X-API-Key: your-key-here"

Cursor

Cursor reads %USERPROFILE%/.cursor/mcp.json on Windows or ~/.cursor/mcp.json on macOS and Linux. Add the block below, then open the MCP settings panel and refresh the server list.

{"mcpServers":{"guardr":{"url":"https://api.guardr.io/mcp","headers":{"X-API-Key":"your-key-here"}}}}

Replace your-key-here with a key from Dashboard → API Access. Treat that key the way you treat a password: anything holding it can read your account.

3 - The three tools

Each tool returns the body an existing Guardr surface already returns, field for field. The endpoint adds no field of its own and takes none away.

Tool	What it returns	Matching route
check_site	A fresh check of one domain	POST /v1/scan
list_sites	The sites your account watches	GET /v1/sites
get_site	One watched site in detail	None. See below

check_site

Takes one domain and runs a fresh check of it. check_site returns the same fields as POST /v1/scan: the grade, the score, the five category scores, the findings with their severity and any API keys or tokens the check read out of JavaScript bundles. The values match that route field for field. The whitespace does not, because the REST API prints its JSON indented while a tool result is compact, so compare the parsed values rather than the bytes.

Any public domain may be checked, which is the rule POST /v1/scan already follows. The result for a domain another account watches is the result anybody checking that domain would get.

list_sites

Returns the sites your account watches, the same fields as GET /v1/sites, one row per site. The values match that route field for field. The whitespace does not, because the REST API prints its JSON indented while a tool result is compact, so compare the parsed values rather than the bytes. A key reads its own account only, so a row belonging to another account never appears. A key bound to a single site returns that one site.

get_site

Takes one domain your account watches. No REST route answers this one, so its body is assembled from three things Guardr already emits elsewhere: the list_sites row for that domain, the monitoring summary of its latest check and its uptime summary.

A domain your account does not watch answers exactly the way an unknown domain answers, so the tool cannot be used to learn which domains other accounts watch.

4 - Keys and limits

Every POST to the endpoint counts once against the same burst allowance a REST call counts against, whether it lists the tools or calls one. Every tool result carries the allowance it was served under in its _meta.rate_limit field: limit, remaining, reset and retry_after. Listing the tools is the exception: that call spends the allowance without reporting it, so its result carries no _meta.rate_limit. The REST API reports the allowance only on its scan responses, so GET /v1/sites tells you nothing about it either.

When that allowance is spent the endpoint answers 429 with a JSON-RPC error whose message is rate_limited, carrying those same four values. A missing key or an unknown key answers exactly as the REST API answers it.

The allowance itself, the key format and the error codes are documented once, on the API reference page. The endpoint reads them from the same place.

The story behind the endpoint, written for the developer rather than for the reference, is on the Guardr for agents page.