The agentcheck prober

What it is

agentcheck is an uptime and contract monitor for MCP servers and HTTP APIs. Its prober makes the request a customer asked it to make, on the schedule that customer set, and reports whether the answer still matches the last one. It is an availability checker. It is not a crawler and not a training-data collector.

How to identify it

Every request carries that exact User-Agent. The prober is never run behind a browser user-agent string and the string is never rotated to evade filtering. It runs on shared serverless infrastructure, so there is no stable source-IP range to allowlist — match on the user-agent.

What it fetches

• Only URLs a customer enrolled as a monitoring target, one request per scheduled run.
• No link-following, no sitemap walking, no path discovery. The prober never requests a URL it was not given, other than the same-origin well-known paths an MCP or OAuth handshake requires.
• At most one run every 5 minutes per target, and hourly on the free plan.
• robots.txt is not consulted, deliberately. A customer pointing us at their own endpoint is instructing us to fetch it, the way any uptime checker is instructed. If you did not enrol the target, see “How to stop it”.

The monthly MCP census

Requests whose user-agent starts agentwares-mcp-liveness/ link here too. They come from MCP Liveness’s monthly census of the official MCP registry, not from a customer’s target. Once a month it sends one MCP handshake to the endpoint each remote listing names. It also sends five discovery GETs to each origin behind those listings, one each:

• /.well-known/agent-card.json, the A2A agent card;
• /.well-known/http-message-signatures-directory, the Web Bot Auth key directory (redirects are not followed);
• <endpoint>/server-card, the MCP server card (SEP-2127), for one endpoint per origin;
• /.well-known/mcp/server-card.json, the MCP server card at the location of the older SEP-1649 draft;
• /.well-known/ai-catalog.json, the AI Catalog, and then at most five MCP server cards it links on that same origin.

Each has a ten-second limit, no credential, no retry and no signature. An origin that does not answer the first is not sent the others. robots.txt is not consulted: these documents are published for automated clients to fetch. What the census finds is published as counts and per-origin verdicts at agentwares-mcp-liveness.vercel.app/agent-directories.

What it does with the response

• Records the status code, the timing and a hash of the response, so the next run can say whether anything changed.
• For MCP endpoints, records the tool manifest, because telling a customer which of their own tools changed shape is the product.
• No content is used to train a model, sold, syndicated, or republished.
• Nothing is shown to anyone except the customer who enrolled that target and, where they turned on a public status badge, the summary they chose to publish.

How to stop it

Block or challenge that user-agent at your edge. The prober will then report the target as unreachable to whoever enrolled it, which is the right outcome if that person does not own the endpoint. If you believe a target was enrolled by someone who does not control it, tell us at https://agentwares.vercel.app/contact (topic: abuse) with the URL and we will remove it.

Cryptographic identity

The prober signs every request with an Ed25519 key under RFC 9421 HTTP Message Signatures, following the Web Bot Auth profile. The public keys are published as a JWK Set at https://agentwares-agentcheck.vercel.app/.well-known/http-message-signatures-directory. Verifying that signature proves the request came from us; the user-agent alone does not.

Operator

agentwares, a product of TrainedBooks. Independent product; not affiliated with or endorsed by Anthropic, Cloudflare, or any vendor whose protocol it speaks.