Check a website in a real browser, or check if AI agents can use it: score, problems, report link.
Scored across 3 tools
check_agent_ready and check_site both run website checks and return scores/report URLs, so they could be momentarily confused, but the descriptions clearly separate AI-agent-readiness from real-browser site checking. get_report is clearly distinct as the retrieval tool for async results.
All tools use snake_case with verb-first naming (check_*, get_*), which is predictable and readable. check_agent_ready is slightly longer/compound compared with check_site, but the convention remains consistent overall.
Three tools is a small but sensible surface for a site-checking service: two check variants plus one report retrieval tool. It is slightly thin, but each tool has a clear role and nothing appears redundant.
The core lifecycle is covered: run an agent-readiness check, run a browser-based check, and retrieve async results by id. Minor gaps exist, such as listing past reports or canceling a running check, but agents can work around them.
Run a free Tuper Agent-Ready Check on a public website: can AI agents reach, read and use it? Checks robots.txt rules for 12 AI bots (answer bots scored, training bots info only), llms.txt (llmstxt.org format), bot walls and captchas on the sign-up/login/contact pages, text only after JavaScript, sitemap, JSON-LD and prices, MCP/A2A cards, OpenAPI. Returns a 0-100 score, a headline per group, every fail and warning with what to change, and the report URL. Takes 5-30 s. How 40 famous sites score: https://check.tuper.app/agent-ready/league/?src=mcp-league
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public site address, e.g. "example.com" | |
| wait_seconds | No | How long to wait for the result before returning the id (0 = do not wait) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations: it lists exactly what is inspected (robots.txt for 12 AI bots, llms.txt, bot walls/captchas, post-JavaScript text, sitemap, JSON-LD, prices, MCP/A2A cards, OpenAPI), what is returned (0-100 score, headlines, fails, warnings, report URL), and how long it takes. This is rich context for a read-only checker and does not contradict the annotations.
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 main action and scope, then lists the checks and return values efficiently. It is dense but mostly purposeful; the league URL is promotional but also provides a useful benchmark reference.
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?
Given the tool's complexity, the description is complete enough to call it correctly: it explains the target, the checks performed, the return shape, and expected runtime. With no output schema present, the description appropriately fills in the return-value details.
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 both parameters are already well documented in the schema. The description implies the 'url' target is a public website and mentions timing, but it does not add parameter-level meaning beyond the schema, such as how 'wait_seconds' affects polling or what happens when it returns an id.
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 uses a specific verb and resource: 'Run a free Tuper Agent-Ready Check on a public website' and explains that it assesses whether AI agents can reach, read, and use the site. It clearly states the many checks performed, but it does not explicitly differentiate this tool from the sibling 'check_site', leaving sibling selection partly inferential.
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: this is for a public website, it is free, and it takes 5-30 seconds. However, it does not state when to use this tool versus 'check_site' or 'get_report', and it provides no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a free Tuper Site Check on a public website (measured in a real browser): returns a 0-100 score, counts by severity, the top 5 problems (what, why it matters, where) and the full report URL. Takes 20-90 s. If still running after wait_seconds, returns status "running" and an id for get_report.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public site address, e.g. "example.com" or "https://example.com/pricing" | |
| wait_seconds | No | How long to wait for the result before returning the id (0 = do not wait) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only tell the agent this is a read-only, open-world, idempotent call; the description adds the real behavioral facts an agent needs — a 20-90 s runtime, the wait_seconds cutoff, and the partial-result contract (status 'running' plus an id). This is exactly the latency and long-running-call context annotations cannot express.
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?
Three tight sentences: what it does and returns, then timing, then the timeout branch. The most decision-relevant facts (free, real browser, return shape) are front-loaded with no filler.
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 fully covers the return shape including the alternate 'running' state, so an agent knows what to do in both the success and timeout cases. Nothing needed to invoke it correctly is missing.
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 already 100%, so baseline would be 3, but the description adds real meaning to wait_seconds by explaining its consequence (returning an id for get_report) rather than just its bound. The url parameter's public-site constraint is restated usefully but adds nothing 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?
States a specific verb and resource ('Run a ... Site Check on a public website'), names the measurement method (real browser), and enumerates the returned payload (0-100 score, severity counts, top 5 problems, report URL). It also distinguishes itself from the sibling get_report by describing exactly when that tool becomes relevant (timeout).
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?
Gives clear operating context: free, public sites only, 20-90 s duration, and an explicit fallback path to get_report when wait_seconds elapses. It never explains when to prefer check_agent_ready over this tool, so sibling selection against that alternative is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Site Check report by id (from check_site): status (queued, running, done, error), and when done the score, the top findings (up to 20 with all=true) and the report URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Report id from check_site | |
| all | No | true = up to 20 findings instead of 5 | |
| wait_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/open-world profile, so the description's job is to add payload detail, which it does: it lists the status states, what is returned when done, and the all=true findings expansion. The one behavioral gap is wait_seconds, whose blocking behavior (up to 110s) is disclosed nowhere.
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?
One sentence, front-loaded with verb and resource, and every clause (id source, status values, done payload, all flag) adds information. No filler or redundant restatement of the title.
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, the description correctly takes on the return-value burden by describing status, score, findings, and URL. However, for a tool whose central use case is waiting on an async report, the absence of any wait_seconds explanation leaves a meaningful hole in what an agent needs to invoke it 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 67%, and the description's parameter notes ('id (from check_site)', 'up to 20 with all=true') merely restate what the schema already says. The single undocumented parameter, wait_seconds, receives no explanation in either the schema or the description, so the definition does not compensate for the coverage gap.
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 uses a specific verb and resource ('Read a Site Check report by id') and anchors the id's origin to the sibling tool check_site. It also enumerates what the report contains (status, score, findings, URL), so an agent can distinguish it from check_site and check_agent_ready. It stops short of explicitly framing itself as the polling companion to check_site, but the purpose is unambiguous.
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 status enumeration (queued, running, done, error) implies a polling pattern, but the description never says to call this repeatedly until done, nor when to stop. Crucially, wait_seconds — the mechanism for waiting — is never mentioned, leaving the primary usage pattern only inferable rather than stated.
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_readycheck_siteget_reportScores any public website on how usable it is by AI agents, with per-check evidence.
Scan a public website for AI agent readiness: 60 checks, a score, and the evidence for each.
Website checker for AI coding agents. Measures your site in a real browser, with evidence.
Scan any website for AI-agent readiness: 0-100 score, grade, and agent-simulation audit.
Add one secure layer between your agents and this server.
