Fetch web pages as Markdown, judged real or not first, and check sites for AI-agent readiness.
Scored across 3 tools
The three tools have clearly distinct purposes: auditing a site for agent-readiness, retrieving a page as Markdown, and obtaining an API key. Although check_agent_readiness and fetch_page both touch web content, their intended outcomes are different enough that an agent should not confuse them.
All three names use the same clear verb_noun snake_case pattern: check_agent_readiness, fetch_page, request_key. The convention is predictable and consistent throughout the set.
Three tools is at the lower end but still appropriate for this focused surface. Each tool is substantive and appears to earn its place rather than being a thin wrapper.
The set covers the core workflows: auditing a site, fetching page content, and obtaining an API key. A minor gap is key lifecycle management, since there is no tool to check, revoke, or rotate an existing key, but agents can work around this for the apparent scope.
Check a website the way an AI agent meets it: robots.txt and content signals, sitemap, Markdown on request, llms.txt, the API catalog, OAuth discovery, an MCP server card, agent skills, an A2A card, and whether the home page lets an agent in. Each file is checked by its body against an address that cannot exist, so a site that answers every path with its home page is reported as a false pass instead of a pass.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The site to check, e.g. example.com | |
| api_key | No | Your key (sik_…), only if your MCP client cannot send it as the Authorization header, for example a key you just got from request_key. The header wins when both are sent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full disclosure burden, and it does deliver a genuinely non-obvious behavioral trait: each file is validated by its body against an impossible address so soft-404 sites are reported as a false pass rather than a pass. That is exactly the kind of anti-footgun detail an agent could not get from the schema. It still omits what the response actually looks like and whether requests are rate-limited or authenticated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the action is front-loaded before the enumerated checklist. The second sentence, while dense, earns its length by explaining the soft-404 false-pass guard, which is the single most important thing to understand about the tool's results.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a multi-check diagnostic with no annotations and no output schema, so the description must convey both behavior and result shape. It handles behavior well but never says whether the result is a per-check pass/fail list, a score, or free text, leaving the agent unable to anticipate what it will receive. For a two-parameter read tool that is a moderate but real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the url and api_key parameters are already fully documented inside the schema, including the header-wins precedence rule. The description adds nothing about parameter format or behavior beyond that. Baseline 3 is appropriate when the schema does all the semantic work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ("Check a website the way an AI agent meets it") and then enumerates exactly what is inspected: robots.txt, sitemap, llms.txt, API catalog, OAuth discovery, MCP server card, A2A card, and home page access. That is far beyond a restatement of the name. It stops short of a 5 because it never contrasts itself with the sibling fetch_page, so an agent must infer on its own that this is the multi-artifact audit rather than a single-page retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use statement, no mention of cost, rate limits, or whether this should be run once per site versus per page. The purpose implies the usage context well enough that an agent can pick the tool for an agent-readiness audit, but nothing tells it when to prefer fetch_page or when to fetch a key via request_key first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a web page and get its main text as Markdown, with the title, word count, outgoing links, the final URL after redirects, and a SHA-256 of the Markdown. Before returning it, the page is judged: an app shell that needs JavaScript, a bot challenge, a cookie wall, a sign-in redirect or an error page comes back as verdict not_content with the reason, and does not count against your calls. Plain HTTP only: it does not run JavaScript.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to fetch, e.g. https://developers.cloudflare.com/workers/ | |
| api_key | No | Your key (sik_…), only if your MCP client cannot send it as the Authorization header, for example a key you just got from request_key. The header wins when both are sent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the returned fields, redirect resolution, a SHA-256 digest, the verdict mechanism with named failure reasons (JS shell, bot challenge, cookie wall, sign-in redirect, error page), and the fact that not_content responses are free. That is unusually rich behavioral context for a fetch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action and the returned value, then the limitation, then the verdict behavior — no filler and nothing repeated from the title. The sentence structure is dense but each clause carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by enumerating the response fields and the not_content verdict shape. Combined with the no-JS limitation, an agent has everything needed to call it and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the url example and the api_key fallback/header-precedence rule are already fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch a web page') and immediately names the payload ('main text as Markdown') plus the extra fields returned. It is unmistakably distinct from the siblings check_agent_readiness and request_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Plain HTTP only: it does not run JavaScript' line and the enumerated not_content cases tell the agent when this tool will fail and therefore when not to reach for it. It stops short of explicitly routing to check_agent_readiness as the alternative for verifying a site is fetchable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a working API key now, without a sign-up form. Give the email of the person you work for: the key works at once for a few calls a day, they get one email, and when they confirm it the same key moves to the free plan of 100 calls a day. Then send it as Authorization: Bearer on this server.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | A short name for your agent, shown to that person | |
| Yes | Email of the person the agent works for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses immediate limited quota, the confirmation email, the upgrade to 100 calls/day, and the Authorization: Bearer usage, though it omits key expiry, revocation, and error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the outcome and constraints, and every sentence adds useful information. There is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description implies that a key is returned and explains how to use it. It could specify the response shape or failure modes, but it is adequate for a simple two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces that the email belongs to the person the agent works for, but it does not mention the optional agent parameter or add syntax beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: get a working API key for this server, without a sign-up form. It is clearly distinct from the unrelated sibling tools check_agent_readiness and fetch_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: get a key now without sign-up, use it immediately for a few calls, and confirm the email to move to the free plan. It does not explicitly state when not to use it or name alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_agent_readinessfetch_pagerequest_keyFetch pages as markdown, search web and news, extract structured data. For AI agents.
Read any web page as clean Markdown for AI agents: fetch, search, metadata, links. SSRF-safe.
Fetch any URL and get clean Markdown. Web scraping for AI agents.
Vet a domain (WHOIS age, DNS, SPF/DMARC, TLS) or read a web page as Markdown. Run by an AI agent.
Add one secure layer between your agents and this server.