ConformRadar

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real value beyond them: a hard 3 MB HTML size limit, that JSON-LD product data is parsed, that url is used to recognise the shop's own domain, and the exact check set per page type.

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 purpose in one sentence, then a scannable per-page_type check list and a short Args block. The page_type list is somewhat long but each line carries semantic content (which checks run) that the bare enum values do not provide.

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 should hint at what comes back; it references 'the evidence' but never states the result format (findings, pass/fail, severity). Everything an agent needs to select and invoke the tool is present, but the response shape remains 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 coverage is 0%, so the description carries the burden, and it does so well: html (full page, size cap, JSON-LD read), page_type (drives which checks run, with the enum values mapping to documented check groups), url (future address, used in evidence and domain recognition), and lang (fr/en). Only the return shape of the checks stays undescribed.

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 (run checks) on a specific resource (the HTML of ONE page) and enumerates exactly which checks fire per page_type. It clearly distinguishes itself from scan_website (full scan) and check_text (text-based) by scoping to one page's HTML before go-live.

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 context: use it on a page you are building or editing (template, rendered page, local preview) and to verify a fix without waiting for a new scan, which implicitly contrasts with a full site scan. It does not explicitly name check_text or scan_website as the alternatives, so usage routing is implied rather than spelled out.

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?

Annotations cover read-only/idempotent/open-world status, but the description adds substantial context the annotations don't: read-only nature aside, it discloses a 200,000-character limit, that product_description triggers GPSR/textile checks, and that product_name is used to classify textiles/food/services. That is meaningful behavioral detail beyond the structured fields.

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 statement of intent, then compact per-type breakdown and arg definitions. Dense but almost every clause carries unique signal. Slight redundancy in listing text types twice (parenthetical and per-type block) keeps it from a 5.

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 does not describe return values or findings format, which is the main remaining gap. Everything an agent needs to invoke it correctly (params, language support, text-type-specific behavior) is present, so it is nearly complete for a 4-param 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 coverage is 0%, so the description must compensate, and it does: it defines text (up to 200k chars), text_type categories, lang supported values, and crucially that product_name disambiguates textiles/food/services – none of which the schema conveys. This fully covers what an agent needs.

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 (check) and resource (plain text) and enumerates the concrete text categories it covers (product description, ad/newsletter copy, terms of sale, legal notice). It also names specific checks per text_type, which no sibling does.

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 'before publishing' framing and the per-text_type enumeration implicitly tell the agent when to use it, and the language note ('French fully supported; English only for environmental claims') is an explicit constraint. However, it never names or routes to alternatives, which is the tool's main gap given siblings like check_html.

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?

Beyond the readOnly/idempotent annotations, it discloses things annotations cannot: the registry size (~160), the robot_coverage field semantics ('auto'/'partial'/'self' and what 'self' means operationally), and that rule texts are French. It does not describe result shape or pagination behavior.

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 and the Args block is dense with no filler; every parameter gloss carries information. Slightly long, but the length is justified by 0% schema coverage.

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 at least explains the robot_coverage field the agent will encounter, which is the most important interpretation aid. It omits what else comes back per rule (title, id, legal references) and how to page beyond limit, leaving a small 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 0%, so the description carries the full burden and does: it glosses each sector value, enumerates the valid theme values (which the schema does not constrain at all), explains query matching against title/obligation/legal references with examples, and giving the limit bound of 1-200 that the schema lacks.

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: searches a register of ~160 French rules applying to websites, with the scope size quantified. It also implicitly separates itself from get_rule by framing itself as the search step and naming get_rule as the detail step.

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 get_rule when the full obligation, texts, penalties and authority are needed, implying find_rules is for discovery. No explicit when-not-to-use or prerequisite guidance, but the sibling hand-off is clear.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the concrete output forms (HTML with French labels plus plain text, paste-ready) and the conditional requirement rule for EU-responsible data, though it says nothing about error behavior or missing optional fields.

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 purpose is front-loaded in the first sentence, followed by a well-structured Args block with one line per parameter. It is somewhat verbose, but nearly every line earns its place given that the schema provides no parameter documentation.

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 compensates by describing the two return formats and their intended use. Combined with full parameter coverage and the conditional EU-responsible rule, an agent has what it needs to call the tool correctly; only edge-case behavior (invalid input, omitted optional fields) is unaddressed.

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 0%, so the description must carry the burden, and it does: it explains all eight parameters, clarifies that the three eu_responsible_* fields are required only when the manufacturer is outside the EU (a rule absent from the schema), and specifies that safety_warnings must be in French for the French market.

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 (build/generate) and a precisely scoped resource: the GPSR 'manufacturer and product safety' block required by Regulation (EU) 2023/988 art. 19 for non-food products in the EU. It also names the output artifacts (HTML with French labels and plain text), so an agent can distinguish it from siblings like generate_legal_guarantee_box at a glance.

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 the regulatory condition that triggers the need ('every online offer of a non-food product must show in the EU'), which implies when to use it, and it states when EU-responsible fields are required (manufacturer outside the EU). However, it never explicitly names alternatives or states when NOT to use this tool versus generate_legal_guarantee_box, leaving routing to inference.

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?

Annotations already declare readOnlyHint, idempotentHint=true and destructiveHint=false, so the safety/idempotency profile is provided structurally. The description adds output-format transparency (HTML and plain text) and the goods-only constraint, but says nothing about how the seller details are embedded or failure modes when out of scope.

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 purpose sentence followed by the validity caveat, then a clean parameter list. Slightly verbose due to long legal reference, but every element 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?

Covers purpose, scope limits, and all four parameters for a generation tool with no output schema. Sufficient for correct invocation; only minor gaps (exact output structure, out-of-scope behavior) remain.

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 0%, so the description must carry the burden. It documents all four required parameters with clear intent (e.g., 'e-mail address or another digital contact'), compensating well for the empty schema. It could add format expectations (e.g., phone format) but is otherwise solid.

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 (Build) and a specific artifact (the mandatory legal guarantees box for French consumer terms of sale), and names the exact legal basis (annex to art. D. 211-2, model A). No sibling tool produces this artifact, so it is clearly distinguished.

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 scopes applicability: 'Valid for the sale of goods only (pets and digital content or services have other templates).' This tells the agent when NOT to use it, though it doesn't name the specific alternative tool/template to route to.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description still adds useful behavior beyond that: the payload is in French and it enumerates the fields returned (legal texts with links, penalties, enforcement authority, date in force, upcoming changes), which matters because there is no output schema.

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 and scope are front-loaded in a single sentence, with the argument detail relegated to a compact Args block. The field enumeration is long but each item is a distinct, non-redundant output field 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?

With no output schema, the description compensates by listing the returned content, and it flags the French-language constraint that an agent otherwise would not know. Missing error/not-found behavior for an invalid rule_id, but the essential information for correct invocation is present.

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 0%, so the description must carry the parameter. It does: it explains provenance ('identifier returned by find_rules or scan_website') and provides a concrete example ('information-precontractuelle-vente-distance'). It omits format constraints such as case sensitivity or handling of an unknown 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?

Names a specific verb and resource ('Full detail of one rule of the register') and enumerates the exact content returned, so an agent can distinguish it from find_rules (search) or check_html (evaluation). The French-content note further disambiguates its output.

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?

By specifying the rule_id is 'returned by find_rules or scan_website', it establishes the prerequisite workflow that selects this tool over its siblings. It stops short of saying when not to use it or what happens for an unresolvable id, so it is not a 5.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely new behavioral context: it blocks up to 60 seconds if the scan is still running, and results expire after 30 days. It does not describe the returned payload, which is a 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?

Purpose and key behaviors are front-loaded in the first sentence, followed by a compact Args block. The sector/lang enumerations partially repeat the schema, but overall there is little waste.

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 result-retrieval tool with no output schema, the description never characterizes what the returned scan result actually contains, leaving the agent to guess the payload shape. Retention and blocking behavior are covered, but the output gap keeps this at minimum-viable.

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 0%, so the description carries the burden and mostly delivers: it identifies the origin of scan_id, enumerates sector values and notes it is guessed when omitted, and lists lang values. The 'guessed when omitted' behavior for sector is meaning not present 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?

States a specific verb+resource ('Get the result of a scan') and ties it explicitly to its producer sibling, 'scan_website', so an agent can distinguish it from the other check_* and find_* tools without opening a 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?

Clearly establishes the prerequisite (the scan_id returned by scan_website) and the blocking behavior, which tells the agent when this tool is the right one. It stops short of naming any alternative or a when-not-to-use condition.

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds genuinely useful behavior (results sorted by date, default 90-day lookback, no upper bound), but says nothing about result volume, pagination, or how far ahead 'upcoming' extends.

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 front-loaded sentence states what the tool returns and how it is ordered, followed by a tight per-argument block. No filler, no restatement of the tool name, and the most decision-relevant information comes first.

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 three-parameter, read-only list tool with no output schema, the description covers purpose, filtering, sort order, and defaults adequately. The main gap is that it does not hint at the returned shape (e.g. whether rule identifiers are included for follow-up get_rule calls), which matters given there is no output schema to fall back on.

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 0%, so the description carries the burden and largely discharges it: it documents all three parameters, gives the sector enum values, the YYYY-MM-DD format, and the defaults for since and until. Only minor ambiguity remains (whether since/until are inclusive, and what happens if until precedes since).

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-and-resource ('Dated changes in the register: rules that recently came into force and upcoming changes, sorted by date'), so an agent knows this lists time-bound regulatory changes rather than searching rule text. It does not explicitly distinguish itself from the sibling find_rules/get_rule, which is the only thing keeping it from a 5.

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 you call this to see recent and upcoming regulatory dates, and the defaults (90 days back, no upper limit) tell it the default window. There is no statement of when to prefer this over find_rules or get_rule, and no prerequisites or exclusions.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds that the source is a public register, but it omits what happens when nothing matches, whether a name query can return multiple hits, and any rate/availability constraints on the external register.

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 purpose and format before the auxiliary context, and no sentence is wasted. The 'Args:' docstring artifact is slightly rough but functional and arguably helps an agent map the field.

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 does convey the return shape via the FR123456_01ABCD format example, which is the key thing an agent needs. It stops short of describing no-match or multiple-match behavior, the one gap that matters for a single-param 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 0%, so the description carries the full burden and does so well: it enumerates the accepted input forms — SIREN (9 digits), SIRET (14 digits), an identifier of the FR…_… form, or a company name of at least 3 characters — including the length constraint. This is meaningfully more than the bare 'query' string 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?

States a specific verb (Find) and resource (French EPR unique identifiers / identifiant unique REP) with the authoritative source (public ADEME register, SYDEREP) and a concrete format example. The domain is clearly distinct from every sibling tool (HTML/text checkers, rule lookups, GPSR generators), so an agent can route without ambiguity.

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 second sentence gives business context ('a producer covered by an EPR scheme must show them in its terms of sale'), which implies when this is relevant, but there is no explicit instruction on when to call it versus doing nothing, nor any exclusion or precondition. Usage is 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.

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

Goes well beyond the annotations: up to 20 public pages read, robots.txt respected, no firewall bypass, no JavaScript execution, 20-90 second runtime, 100-second timeout yielding a scan_id, and a 30-day report_url. This is exactly the operational context an agent needs and is not derivable from the readOnly/openWorld hints.

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 purpose, then runtime/async behavior, then a clearly delimited Args block. Every sentence carries distinct information 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?

Covers the async handoff (scan_id -> get_scan_result), report availability, and all inputs. With no output schema, the description still tells the agent what comes back (findings with excerpts and legal references), so nothing material 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 description coverage is 0%, yet the prose documents all four parameters with meaning beyond the schema: url accepts domain or full URL including a product page, sector enumerates three values and is guessed when omitted, lang selects finding language, and fresh overrides the 30-minute cache.

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 ('Scan a live website'), names the legal domain (French consumer and e-commerce law) and scope (16 checks). It is clearly distinguished from siblings like check_html/check_text, which operate on snippets rather than a live crawl.

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?

Explains when a scan is reused (same site within 30 minutes) and when to set fresh=true after a fix, and routes the agent to get_scan_result if the run exceeds 100 seconds. It does not explicitly compare against sibling tools such as check_html/check_text, so the alternative selection is left partly to inference.

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