Find out where your AI agent gets stuck: blocked fetches and missing data, in a private report.
Scored across 3 tools
report_failure and request_data share nearly identical triggers (HTTP 403/429, CAPTCHA, Cloudflare, login wall, no API), so an agent hitting a 403 must guess which one to call. report_failure is framed as 'report an incident' while request_data is framed as 'ask for data,' but the surface symptoms overlap heavily, and request_action further overlaps when the blocked thing is a form submission or portal.
All three names are snake_case verb_noun and readable at a glance, but the verb is inconsistent: two use 'request_' while one uses 'report_'. Minor deviation, still predictable enough.
Three tools is thin for a service that positions itself as an escalation desk across failure, action, and data escalation. Each tool maps to a plausible distinct intake category, but the count is borderline and arguably two of them could be merged.
The intake side (report/request plus log id) is covered, but the surface is a dead end: there is no tool to check the status of a submitted log id, retrieve a response later, or see whether a pooled request was fulfilled. That follow-up gap will strand agents after submission.
Call this right after a fetch, scrape or API call fails and stops your task: HTTP 403, HTTP 429, CAPTCHA, Cloudflare challenge, login wall, an empty page that needs JavaScript, PDF-only content, or a page that has gone. Returns an official API or open dataset for the same data where one is known, plus a log id. Does not bypass CAPTCHAs or bot protection. Free, takes seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | URL or domain that failed | |
| private | No | Set true to have your description, purpose and error text used for matching but not stored | |
| agent_name | No | ||
| description | Yes | What you were trying to get from it | |
| failure_type | Yes | e.g. 403, 429, captcha, cloudflare, login_wall, js_render, pdf, timeout | |
| error_message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well: it states the return value ('an official API or open dataset for the same data... plus a log id'), the explicit non-capability (no CAPTCHA or bot-protection bypass), and cost/latency ('Free, takes seconds'). It omits that a report is stored/logged by default unless the private flag is set, and says nothing about rate limits or auth, which is the remaining gap.
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 dense sentences with zero filler: trigger first, then what you get back, then the honest limitation and cost. Every clause carries information an agent needs before calling.
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?
For a 6-parameter tool with no output schema and no annotations, the description covers the two things an agent most needs — when to call it and what it returns. It does not explain that reports persist by default (only the schema's private flag hints at this) or note any auth/rate-limit constraints, leaving a modest 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 67%, and the description meaningfully compensates by translating real-world symptoms into values for failure_type ('empty page that needs JavaScript', 'PDF-only content', 'a page that has gone'), which goes well beyond the schema's terse 'e.g. 403, 429, captcha...' list. It also touches the private/matching semantics. It adds more than schema-only baseline but still leaves agent_name and error_message purely to 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 gives a concrete verb+resource ('report_failure', called right after a fetch/scrape/API call fails) and enumerates the exact failure conditions it covers (403, 429, CAPTCHA, Cloudflare, login wall, JS-only, PDF-only, dead page). This is clearly distinguishable from the sibling tools request_action and request_data, which are for making requests rather than reporting their failure.
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 trigger condition is stated precisely and front-loaded ('Call this right after a fetch, scrape or API call fails and stops your task'), with a detailed list of qualifying failure modes. It stops short of a true 5 because no alternative is named (e.g. when to use request_data again instead) and the when-not condition ('does not bypass CAPTCHAs') is a capability limit rather than routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when you tried to do something for your user and could not finish it: there is no API for the action, a CAPTCHA or bot check stopped you, it needs a login or account, it is phone-only or in person only, or a booking or government portal blocks automation. Examples: booking, submitting a form, contacting a business, filing with a portal, sending post. Returns any existing route that already handles it, plus a log id. Requests are pooled and the most requested actions get built. Free, no key.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Service, site or organisation involved | |
| private | No | Set true to have your description, purpose and error text used for matching but not stored | |
| purpose | No | What the user wanted to achieve | |
| agent_name | No | ||
| description | Yes | The action you were trying to take | |
| failure_type | No | Why it failed: no_api, captcha, login_required, bot_blocked, phone_only, human_verification, payment, other | |
| max_price_usd | No | Most you (or your operator) would pay per request in USD if this existed, e.g. 0.01 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful traits: the return value ('any existing route that already handles it, plus a log id'), the pooling/building behavior, and cost/auth ('Free, no key'). It omits retention or rate-limit behavior, though the private flag in the schema partially covers data storage.
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-loaded with the trigger condition, then examples, then return/behavior/cost in three tight sentences. The example list is dense but directly actionable and every sentence earns its place.
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?
For a 7-parameter, no-annotation, no-output-schema tool, the description covers the trigger, the return shape, and the cost/auth model, which is most of what an agent needs. It stops short of explaining how the individual parameters shape matching.
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 86%, so the schema already documents target, purpose, description, failure_type, private and max_price_usd. The description adds no syntax or format detail beyond a passing reference to 'your description, purpose and error text', 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?
The description states a specific verb+resource ('request an action you could not complete') and enumerates the exact failure conditions that qualify. It is clearly distinct in intent from request_data and report_failure, but it never names either sibling, so an agent must infer the boundary itself.
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?
Strong trigger guidance: 'Call this when you tried to do something for your user and could not finish it', followed by a concrete list of blocking scenarios (no API, CAPTCHA, login, phone-only, portal blocks automation). It gives no when-not-to-use cases and no explicit routing to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when you need specific data for a task and cannot get it: the site returned 403 or 429, showed a CAPTCHA or Cloudflare challenge, sits behind a login wall, has no API, renders only with JavaScript, publishes only as PDF, or the data is spread across many sites or not found at all. Returns pointers to existing sources (official APIs, open datasets, MCP servers) that may already serve the need, plus a log id. Requests are pooled across agents and the most wanted data gets sourced. Free, no key. Do not include personal data about private individuals.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Shape you wanted it in, e.g. JSON list, CSV, single value | |
| target | No | Site, organisation or source you tried, if any (domain or name) | |
| private | No | Set true to have your description, purpose and error text used for matching but not stored | |
| purpose | No | What task the data was for, in a few words | |
| freshness | No | How fresh it must be, e.g. real-time, daily, monthly | |
| agent_name | No | Name of your agent or product, optional | |
| description | Yes | What data you needed, as specifically as possible | |
| max_price_usd | No | Most you (or your operator) would pay per request in USD if this existed, e.g. 0.01 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that requests are pooled across agents, that the most-wanted data gets sourced, that the call is free with no key, that it returns pointers plus a log id, and it sets a privacy constraint on inputs. It omits latency, whether the call is synchronous, and any rate limits, keeping it from a 5.
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 trigger is front-loaded in the first clause and the return/behavioral facts follow, so an agent gets the routing signal immediately. The first sentence is a long run-on enumeration, but each item is a distinct condition that earns its place, so the verbosity is functional rather than 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?
There is no output schema, and the description compensates by explaining the return payload (pointers to sources plus a log id). For an 8-parameter submission tool it covers purpose, cost, privacy, and pooling behavior adequately; the main gap is that it never explains the interplay of private/max_price_usd/freshness, which the schema carries alone.
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 every one of the 8 parameters is already documented in the schema and the baseline is 3. The description adds no per-parameter semantics beyond the schema, aside from a general warning not to include personal data of private individuals.
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 trigger-and-action contract: call this when data is unobtainable (403/429, CAPTCHA, login wall, no API, JS-only, PDF-only, not found) and it returns pointers to existing sources plus a log id. It is clearly distinguishable from the siblings report_failure and request_action, which are about reporting and acting rather than sourcing data.
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 when-to-use condition is exhaustively enumerated with concrete failure modes, which is unusually good routing guidance. However, it never names the sibling alternatives (report_failure, request_action) or states when this tool is the wrong choice, so it stops short of full when/when-not/alternative coverage.
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.
report_failurerequest_actionrequest_dataLive web checks for AI agents: sitemaps, robots.txt, URL status, broken links, feeds, citations.
How websites treat AI agents: bot walls, JavaScript needs, robots rules and llms.txt. Look a site up before you fetch it, report what you saw after. Free lookups (100 a day per key), free signed reports, verified when 3 independent agents agree.
Find your AI agent's likely failure mode, get runtime settings, and clarify ambiguous prompts.
Scan any public website and see how ready it is for AI agents and AI search, explained plainly.
Add one secure layer between your agents and this server.
