Rat Radar

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description does much of the behavioral work: it says robots.txt is fetched live, explains the longest-match rule, names default user agents, and describes the returned decision, deciding rule, and crawl delay. It does not cover failure behavior when robots.txt is missing or unreachable, so it is strong but not complete.

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 three tight sentences, front-loads the core question, then adds the matching rule and return details without filler. The parenthetical agent list is dense but useful.

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 two-parameter check with no output schema, the description explains the decision outcome, the deciding rule, and crawl delay, which is sufficient for an agent to understand what calling the tool yields. The courtesy-check caveat also sets appropriate expectations.

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 the baseline is 3. The description adds real meaning by specifying that user_agent defaults to '*' plus named AI crawler agents, which is not captured in 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 boolean question and mechanism: it checks whether robots.txt allows fetching the exact URL, fetches the live robots.txt, and applies longest-match rules. This clearly distinguishes it from site-level siblings such as check_site and list_sites without needing the schema.

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 phrase 'this exact URL' and the disclaimer 'courtesy check, not a legal opinion' give clear usage context. However, the description does not explicitly say when to use this instead of a sibling like check_site, so it stops short of full alternative routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description does real work: it discloses that unknown domains are probed live from a datacenter IP (so results may not match the caller's own network), that the dataset is refreshed weekly, the four verdict tiers, and the explicit 'signals, not legal advice' disclaimer. It omits latency/rate-limit expectations for live probes, which is the main remaining behavioral 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?

It front-loads the core question and answer shape before the long field enumeration. The return-value list is dense but justified because there is no output schema to lean on; only the EDPB-guideline clause is heavier than strictly necessary.

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 compensates well by enumerating every return field, naming the data sources and their freshness, and flagging the legal-advice limitation. It stops short of describing response structure (flat vs nested) or what happens on domains that cannot be probed.

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% and the single parameter is documented with an example (reddit.com). The description adds only marginal meaning, clarifying that arbitrary domains are accepted via the live-probe fallback. Baseline 3 is appropriate since the schema carries the parameter semantics.

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 opening question ('Can I scrape this site, and how?') plus the enumerated return payload (verdict, hostility score, recommended approach, bot protections, robots.txt/AI policy, machine-readable surfaces) makes the tool's function unmistakable. It never names the closest sibling (can_fetch) or explains how the two differ, so an agent still has to guess which to call.

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?

Usage context is implied by the data-source note: a pre-probed weekly dataset of several hundred sites, with live probing from a datacenter IP for anything else. That tells an agent roughly what to expect, but there is no explicit when-to-use, when-not-to-use, or routing to can_fetch/list_sites/search_sites for narrower needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden and does much of it: it discloses return payload contents (pipeline stages, fields, recipes per platform), the provenance signal 'found_on_this_site come from what the weekly probe saw on the site itself', and the additional payloads (other workflows, golden data, guardrails). It omits mutation/read nature explicitly and any rate-limit or failure behavior, keeping it short of 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 lead question plus 'Give a domain...' is well front-loaded, but the return-value sentence is a dense run-on enumerating eight pipeline elements and four platforms. It's informative yet verbose, and some enumeration ('a trigger, collect, shape, store, act pipeline') could be compressed.

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 does the necessary work by explaining what comes back, including the found_on_this_site provenance and the auxiliary payloads. What's missing is only the selection context against sibling tools, which is a modest gap for a read-only lookup 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 baseline is 3. The description adds modest meaning: goal examples that clarify what 'goal' accepts and 'or just one with platform' for the enum. But it mostly restates the schema's own description of the platform and domain parameters.

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?

It names a specific resource (a workflow/playbook for a given domain) and a specific output shape: 'Returns the best-matching workflow for that site: what it does, its cadence, a trigger, collect, shape, store, act pipeline...'. An agent can tell this apart from check_site, list_sites, and xray_page without opening any schema.

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 description does say 'Give a domain and, optionally, a goal in plain words' with concrete goal examples ('price alerts', 'sales leads', 'change log'), which implies the usage context. But it never says when to pick this over siblings like list_sites or check_site, and there are no exclusions or prerequisites (auth, cost, caching). Usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does not explicitly confirm read-only safety, describe pagination/limit behavior, or explain what the listing returns; 'List' implies a read operation but leaves key behavior to inference.

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 two sentences, front-loaded with the core action and followed by a concise usage cue. There is no wasted 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?

For a simple list tool, the description covers the main purpose and filters. But with no annotations and no output schema, it omits return contents, ordering, pagination semantics, and how it differs from search_sites.

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 moderate at 67%, and the description mentions the optional category and verdict filters. It does not mention the limit parameter or add meaning beyond the schema's existing enum and examples, so it is adequate but not compensatory.

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: list the sites in the dataset, with optional category or verdict filtering. It is clear enough to distinguish from mutation tools, though it does not explicitly differentiate itself from the sibling search_sites tool.

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 an intended use case: find easy targets or see what is covered. However, it provides no when-not guidance and does not mention alternatives such as search_sites or can_fetch.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 implies a read-only search and mentions discovery before check_site, but does not disclose result format, ordering, pagination behavior, or whether matching is case-insensitive. This is adequate but has clear gaps for a search 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?

Two tight sentences with the core purpose front-loaded and the usage note immediately after. Every phrase contributes useful selection or invocation context.

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 has no output schema and no annotations, so the description should do more to explain what callers get back and how results relate to check_site. It covers the search inputs and discovery use case, but leaves return shape and identifier handoff implicit.

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 50%; the query parameter is undocumented in the schema, but the description adds substantial meaning by listing searchable fields such as name, host, category, country, and verdict. The limit parameter is documented in the schema with default and max, so the combined coverage is good though not complete in the description itself.

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: "Find sites in the dataset" and clarifies the searchable dimensions: name, host, category, country, or verdict. It also distinguishes its discovery role from check_site, giving an agent a clear basis for selecting it.

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?

Explicitly says to use it "to discover what is covered before calling check_site," which gives a clear usage context. It does not explain when to prefer list_sites or when not to use search, so it falls short of full alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It lists the data returned but doesn't disclose whether this is a read-only operation, if it's expensive, requires authentication, or has rate limits. No behavioral traits beyond content are provided.

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 a single, front-loaded sentence that efficiently lists all key components without wasted words. It is appropriately sized for a summary tool.

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 complexity (no params, no output schema, no annotations), the description is adequate but has gaps. It specifies the contents but lacks details on return format (e.g., structure, pagination) and behavioral context such as read-only safety or potential limitations.

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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and none are present.

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 clearly states the tool provides headline numbers across the dataset, including verdict mix, blocking sites, vendors, and categories. It distinguishes itself from sibling tools like list_sites or check_site by being an aggregate summary, though it lacks a specific verb and doesn't explicitly name alternatives.

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?

Usage is implied: use this for aggregate statistics rather than individual site checks. However, there is no explicit guidance on when to use this tool versus alternatives like list_sites or search_sites, nor are any exclusions or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the return shape (download link + file_name), tells the agent to hand the link to the user, and warns that include_scene adds a few hundred KB. It omits operational traits like latency/cost of rendering and whether the page is fetched live, which keeps it short of 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?

Purpose is front-loaded in the first clause and the rest of the text is return-value detail, all of it relevant. The single long sentence with stacked parentheticals is dense but contains 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?

With no output schema, the description must explain returns and does: link, file_name, optional scene, plus where the file opens. Given only one required parameter and a simple schema, the remaining gaps (rendering cost, whether the page must be crawlable) are minor.

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 both parameters are already documented, and the description largely restates them. The only added value is the quantitative size hint ('a few hundred KB') for include_scene versus the schema's vague 'large', which is marginal.

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 concrete verb and resource ('Draw a page's anatomy as an Excalidraw diagram') and enumerates the diagram's contents (regions, ranked data-access routes, proof rows, best route). The output format implicitly separates it from xray_page, but no sibling is named, so differentiation relies on inference.

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?

Usage is only implied: an agent can infer this is the visual/diagram variant of page analysis. There is no explicit 'use this when you want a shareable visual rather than a text report' statement, no exclusion, and no mention of when xray_page would be the better choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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: it discloses the return structure (reliability, proof rows, pagination notes, blockers), the raw-HTML-only limitation, and the prerequisite ordering. These are exactly the behavioral traits an agent needs to avoid misinterpreting a blocked result as empty data.

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 core action after a short hook, and the enumeration of plan contents is efficient. Slightly dense in the middle list, but every sentence contributes a distinct fact.

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, yet the description fully describes the return payload (ranked sources with reliability, proof rows, pagination, blockers, optional script). An agent has everything needed to call it and interpret the result.

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 both parameters are already documented. The description's 'Set include_code for a starter Python script' largely restates the schema's own wording, adding only minor framing about what the script is for. Baseline 3 is appropriate.

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 ('Fetches one public page and returns a ranked extraction plan') and then enumerates exactly what the plan contains (JSON-LD, CSS selectors, tables, feeds, hidden APIs). This clearly separates it from siblings like xray_diagram or check_site.

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?

Explicitly routes the agent: 'Use check_site first to learn whether the site allows scraping at all.' It also states a when-not condition — JavaScript-built pages report a blocker instead of data, so the agent knows the tool's limits before calling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.