ComplianceCN — toys, batteries, cosmetics, food contact: CE, GPSR, UN 38.3, CPC/GCC and more

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false. The description adds context beyond annotations: it says the tool answers immediately 'from the published ruleset: no case, no account, no follow-up call', and clarifies that a second human-reviewed pack for the same confirmed seller email is arranged with ComplianceCN. It also sets expectations about free/unlimited access for a different product. Minor gap: it doesn't mention what the output object looks like, but there is an output schema, so that's covered.

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 manageable size for a complex tool, is front-loaded with the main use case and examples, and then provides access/pricing context. It does contain a somewhat tangential note about market_access_check being free/unlimited which is useful for sibling differentiation. Slightly longer than necessary but each sentence adds 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?

Given the complexity of the tool (36 params, huge enum sets), the description provides a solid overview of inputs, outputs, access rules, and relationship to siblings. It describes what the tool returns: evidence typically requested, what seller holds, what is outstanding. It also addresses the immediate vs human-reviewed distinction, which is a key behavioral context. The presence of an output schema means return values don't need to be explained in the prose. Minor gaps: it doesn't explain the questions_required clarification loop fully or the continuation via clarification_answer, but those are covered by parameter descriptions in the schema.

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 only 47%, and the description adds meaningful guidance for the most important input (product_description: 'describe the product, destination market, sales channel and any known supplier documents in plain language'). It also explains key parameters like evidence_held, evidence_text, evidence_notes, clarification_answer, case_id, etc. However, many parameters (e.g., evidence_observations, marks, market-specific booleans) are left to the schema's own descriptions, which are already fairly detailed, so the description doesn't need to repeat them. The baseline 3 is fair because it compensates partially for low schema coverage but not fully for all 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?

The description names a specific verb ('check') plus resource ('Amazon or another marketplace compliance request') and clearly states what the tool returns: the evidence usually requested, what the seller already holds, and what remains outstanding. It gives three natural-language triggers and differentiates from siblings such as market_access_check by stating this is the compliance-files answering 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?

The description explicitly states when to use the tool ('Use when Amazon or another marketplace has asked a seller for compliance files or documents') and even gives example phrasings for the user input. It also provides an exclusion/alternative by noting that product assessment through market_access_check is free/unlimited, implying the user should use that for preliminary requirements, leaving this tool for marketplace compliance requests.

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=true, idempotent=true, destructive=false. The description adds that it 'answers immediately from the published ruleset,' implying deterministic read-only behavior, and includes an access notice about free/unlimited usage vs. human review. This goes beyond annotation baseline without contradicting it.

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 'Use when' and examples, then states outputs. The access notice adds extra sentences but provides relevant workflow context. Overall concise for the complexity, though slightly wordy.

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 description covers purpose, output, and a workflow distinction (free vs. human review), but it doesn't explain the dependency on a prior market_access_check call to obtain case_id, which is critical given the parameter schema. It is adequate but not fully complete for an agent to use correctly without additional inferences.

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 only 47%, and the description does not explain any of the 36 parameters. It does imply the need for product/case context (e.g., 'this cell and pack') but doesn't specify how inputs map to parameters. The low coverage requires more compensation than provided.

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 a specific use case ('freight forwarder has refused or queried a battery product') and what it returns (UN 38.3 applicability, shipping marks, transport documents). It distinguishes itself from siblings by targeting battery transport specifically.

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?

Explicit 'Use when' scenarios with concrete examples. It also contrasts the free preliminary path via market_access_check from the human-reviewed second pack, clarifying when this tool fits. No explicit mention of non-use conditions or alternative sibling names, but the trigger conditions are strong.

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 readOnlyHint, idempotentHint, and destructiveHint already present, the description adds meaningful context: 'Answers immediately from the published ruleset' (latency), 'does not issue or sign one' (authority boundary), and the access notice detailing free/unlimited calls and the second human-reviewed pack. No contradiction with 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 use case and output, and the five sentences each carry useful information. The access notice is slightly verbose and somewhat tangential, but not bloated. It earns a 4 rather than 5 due to the extra billing/access detail that could be trimmed without losing core purpose.

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 complex 36-parameter tool with a rich output schema and ten siblings, the description covers purpose, usage triggers, exclusions, latency, cost model, and human-review follow-up. Since an output schema exists, return values need not be spelled out. No major gaps are apparent.

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 47% (below 50%), so the description must compensate for under-documented parameters. It does not: it never mentions case_id, product_description, markets, or any specific field, carrying only generic 'this product' language. The schema itself has good per-parameter descriptions, but the tool description adds no parameter-level guidance.

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+resource: it 'Returns the legislation and standards a Declaration of Conformity would cite for this product' and clearly differentiates from related tools by stating it 'does not issue or sign one.' It also gives concrete trigger phrases ('customs is asking for the DoC'), making the tool's scope unmistakable.

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 explicitly starts with 'Use when a buyer, customs authority or distributor wants the EU Declaration of Conformity' and provides example intents. It states what it does not do (does not issue or sign), but does not name specific sibling tools as alternatives (e.g., check_us_import_certification for US), so it is not a full 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description only needs to add nuance. It adds 'Answers immediately from the published ruleset' (indicating latency and static input) and the access notice clarifies cost/effort boundaries, such as free unlimited assessment via market_access_check and separate human-review arrangement. It doesn't mention error conditions like questions_required, but the annotations cover the safety profile, making this addition valuable.

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 purpose and return value, and the example questions are effective. However, the access notice about market_access_check and ComplianceCN is tangential and could be moved to a separate note, adding extra length. Still, it's only three sentences and avoids unnecessary detail.

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 36 parameters, an output schema, and a multi-stage workflow (case_id from market_access_check, clarification answers, human review). The description doesn't mention that a case_id from a prior workflow call is needed, nor does it explain the overall flow between market_access_check and this tool. The access notice hints at the relationship but doesn't make it explicit, so an agent could be confused about prerequisites.

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 only 47% (low), and the description provides no parameter-level guidance. It never mentions key parameters like case_id, product_description, or evidence_held, which are central to using the tool. With 36 parameters, the description should compensate for the incomplete schema, but it does not.

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 explicitly states the tool's function with a specific verb and resource: 'Use when a seller is unsure their label, artwork or packaging is correct' and 'Returns the marks, symbols, warning language and responsible-entity details'. It clearly distinguishes from siblings such as check_battery_transport_documents and market_access_check by focusing solely on label/packaging review. Example questions further clarify the exact scope.

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 provides a clear when-to-use condition ('Use when a seller is unsure their label, artwork or packaging is correct') with concrete example queries. It mentions market_access_check as a separate complimentary service and notes that a human-reviewed pack requires a separate arrangement with ComplianceCN, which helps an agent understand the workflow. However, it does not explicitly state when not to use this tool or name sibling alternatives beyond market_access_check.

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 indicate read-only, idempotent, non-destructive behavior. The description adds that answers come immediately from the published ruleset and explains the access model: first call returns preliminary requirements, different products start new cases, and a second human-reviewed pack is only arranged under specific conditions. This adds context beyond 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 front-loads the use case and return value, but the 'Access notice' section is verbose and contains business details (free/unlimited, human-reviewed pack) that could be condensed. It is not a tautology, but it is longer than necessary for a tool purpose.

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 (36 parameters, no required parameters), the description omits important input guidance such as the need to provide product_description when category/markets are absent, and how to use case_id across calls. The output schema partially compensates for return-value expectations, and the access model is explained, but overall the description is incomplete for a tool this complex.

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 only 47%, so the description carries a heavy burden, but it provides no parameter-specific guidance. It doesn't mention product_description, case_id, or how to structure inputs; the only hint is that a 'first call' returns preliminary requirements, which is about workflow rather than 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 description clearly states the tool's purpose: used when a US importer, customs broker or buyer needs certification or entry-filing data, with concrete examples (CPC, GCC, CBP entry, FCC SDoC). It specifies the resource (US import certification/entry filing) and distinguishes itself from market_access_check by noting that product assessment through that tool is separate.

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 provides an explicit trigger condition ('Use when...') and gives example queries that an agent might receive. It also references market_access_check as an alternative for product assessment, but does not explicitly list exclusions (e.g., when not to use for EU/UK), so it stops short of full when-not 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?

Annotations already indicate read-only, idempotent, non-destructive behavior; the description adds non-obvious context: answers come immediately from a published ruleset, optional_refinement_questions are non-blocking and should not be auto-asked or re-run, plus access/billing terms for the related market_access_check. No contradiction with 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 appropriately sized and front-loaded: core purpose first, then behavioral traits, then alternative tool, then access notice. Every sentence adds value 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?

With an output schema present, the description covers tool selection, required inputs, tolerances (partial facts), behavioral constraints (non-blocking questions, no re-run), and access/billing context. It gives enough information for an agent to select and invoke the tool 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 low (28%), so the description must compensate. It identifies the required inputs (category, markets), tolerates partial product facts, and explains the non-blocking nature of optional refinement questions. However, it does not add semantics for the many optional product-fact parameters (e.g., battery_type, age_group), leaving them to schema names/enums.

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 ('Compare') and resource ('what the same product needs across 2-4 of the EU, UK, US and Australia'), and distinguishes itself from the sibling market_access_check by noting this is a comparison tool rather than a full readiness assessment.

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 explicitly states when to use the tool (comparing requirements across markets, with partial product facts fine) and gives a clear alternative ('For a full readiness assessment of one product, use market_access_check'). It also clarifies no case, no account, and no follow-up needed.

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, so the description doesn't need to restate safety. It adds behavioral context by specifying what the tool returns (versions, category/market coverage, per-record verification, source policy, operational check links) and by providing workflow guidance about not repeating it before every seller request.

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 with clear front-loading: 'Use when...' immediately states context. The second sentence adds return details and a sibling pointer, 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?

For a simple one-parameter read-only tool, the description covers usage, exclusions, return content, and even directs to a sibling tool for the proper workflow. The presence of an output schema and complete annotations means nothing critical 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?

The schema already provides full coverage for the single `language` parameter, including enum and default. The description adds no parameter-specific details, so the baseline of 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 clearly states the tool's purpose: to inspect scope, source trust, or live-service details, and lists specific return types (versions, coverage, verification, source policy, links). It distinguishes itself from the sibling market_access_check by instructing to use that tool for Stage 1 product requests.

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 'Use when the user or agent needs to inspect scope, source trust or live-service details' and warns 'do not repeat it before every seller request.' It also directs to start ordinary product requests at Stage 1 with market_access_check, thereby clarifying when not to use this tool.

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 and idempotentHint=true, and the description adds useful behavioral context: the claim_id must be stable and from an earlier result, and the return includes claim, evidence, verification date, and evidence gaps. The access notice about market_access_check is tangential but not contradictory.

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 first sentence is strong and front-loaded, but the access notice about market_access_check is off-topic and adds unnecessary length. While still compact, the extra information could be moved to the sibling tool or omitted.

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 a rich output schema and clear annotations, the description covers the essential aspects: what the tool does, constraints on input, and expected return content. It is sufficiently complete for an agent to select and invoke the tool correctly, though the access notice slightly dilutes focus.

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 descriptions cover case_id and language well (67% coverage). The description adds meaning to claim_id by specifying it must be a stable claim_id from an earlier result, but does not elaborate on case_id or language. This provides some additional value 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 clearly specifies the tool's function: explaining a stable claim_id from an earlier ComplianceCN result. It explicitly differentiates from broad natural-language questions and provides a distinct resource and verb, making it easy to distinguish from sibling tools.

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 gives explicit when-to-use and when-not-to-use guidance: 'Explain only a stable claim_id returned by an earlier ComplianceCN result' and 'Do not use this for broad natural-language questions or invent an ID.' It also points to market_access_check as the alternative for product assessments, providing clear context for tool selection.

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?

The description goes far beyond the sparse annotations by exposing the multi-stage workflow, the presence of next_action in every response, the requirement for a confirmed seller email and reviewer sign-off, and the language handling behavior. This gives the agent a concrete mental model of stateful, staged execution without contradicting the idempotency hint.

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?

Four sentences cover the purpose, workflow, constraints, and language support without redundancy. The most actionable instruction ('Send a plain-language product description') appears early, and every sentence contributes meaningful detail.

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 existing output schema and comprehensive parameter descriptions, the tool description fills in the remaining context: how the workflow advances, what requires human review, and how to handle returned questions. An agent has enough information to invoke the tool correctly across all stages.

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 schema already provides 100% parameter description coverage, including detailed guidance for action and case_id, so the baseline is high. The description adds valuable context about the overall interaction flow and language options, lifting it slightly above baseline.

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 opens with a specific verb ('Check') and resource ('what a product needs to be sold into the EU, UK, US or Australia'), making the primary function unmistakable. It also differentiates from sibling tools like compare_market_requirements by focusing on a single product's access needs rather than cross-market comparison.

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 clearly explains how to use the tool: send a plain-language description, follow the returned next_action, answer questions by key, and complete the email/sign-off for human review. It does not explicitly contrast with alternatives or state when not to use it, which prevents a perfect score.

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 read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: it is a single-call operation with no follow-up needed and returns a specific set of outputs. It does not contradict annotations. While it doesn't mention potential clarification flows, the added input-state and return composition justify a score above baseline.

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: the first front-loads purpose and return content, the second gives a clear alternative. No redundant words, easy to parse, and appropriately sized for the tool's complexity.

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 36 parameters and the presence of output schema and annotations, the description covers the essential decision criteria (when to use this tool vs market_access_check) and the expected response shape. It omits some edge cases like clarification continuation, but those are in the schema. It is complete enough for an agent to select and invoke correctly in the primary scenario.

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?

With 47% schema description coverage, the burden falls partly on the description. It names the core parameter groups (category, markets, evidence held), giving a useful conceptual frame, but it does not compensate for the many undocumented parameters (e.g., age_group, battery_type, food_contact_material). The schema handles individual parameter descriptions, so the description's high-level grouping is helpful but not sufficient to push the score higher.

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 ('readiness check') with a clear resource ('structured product facts') and scope (category, markets, evidence held), and it differentiates from the sibling market_access_check by positioning this tool for structured input. It also specifies the return content (requirements, evidence checklist, gaps), making the purpose unmistakable.

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 explicitly says 'when you already have structured product facts' and 'For a plain-language description instead, use market_access_check', providing both a when-to-use condition and a concrete alternative. This directly guides tool selection without ambiguity.

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 annotations (readOnlyHint=false, etc.), the description adds crucial behavioral context: 'Requires a real top-level email and consent_to_alerts=true; there is no payment and no checkout step', 'Alerts start immediately', and 'It does not guarantee detection of every regulatory change.' These disclose side effects, prerequisites, and limitations, matching the openWorldHint and non-idempotent nature.

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 dense paragraph but front-loads the core purpose and includes useful example phrases. Every sentence contributes: purpose, when to use, prerequisites, coverage scope, and caveats. It is slightly long but not wasteful; bullet points could improve scanability but are not 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?

Given the complex nested product_profile schema and the presence of an output schema, the description covers all necessary context: what triggers this tool, what it does, its limitations, and the required preconditions. It does not need to explain return values (output schema exists) or repeat schema field details. The description is complete for an agent to select and invoke the tool 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?

The schema already provides 100% description coverage for parameters, so baseline is 3. The description adds value by explaining the required profile state ('already checked here', 'saved product, market, requirement or rule profile') and reinforcing the consent/email preconditions. This connects the parameters to the workflow better than the schema alone.

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 first sentence clearly states the tool's purpose: 'Start free email alerts for regulatory changes affecting a product already checked here.' The verb 'start' plus the resource 'email alerts' is specific, and the qualification 'product already checked here' differentiates it from sibling check tools.

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 explicitly says 'Use when a seller says they want to be told if the rules change' and provides concrete quote examples. It also states a precondition: 'Call only after a product check has produced a usable product/market profile and the seller has explicitly asked to be notified.' This gives clear when-to-use guidance and excludes premature calls.

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