OpenAccountants

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds behavioral context such as jurisdiction auto-fill for signed-in users and the response marking jurisdiction_source, which provides useful transparency 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 is composed of three sentences with no extraneous information. The first sentence states the core purpose, the second provides usage cues, and the third explains conditional behavior. It is front-loaded and concise.

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 presence of annotations and an output schema, the description covers the essential aspects: what the tool returns (deadlines and rhythms), when to use it, and special behavior for configuration. 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?

The input schema covers both parameters (horizon_days and jurisdiction) with clear descriptions (defaults, max, examples). The description adds additional semantic meaning: jurisdiction is optional for signed-in users with a saved home jurisdiction, and the response indicates how jurisdiction was determined. This supplements the schema meaningfully.

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 that the tool retrieves upcoming filing/payment deadlines and recurring filing rhythms from the OpenAccountants tax calendar, specifying the scope as a country or US state. This defines a specific verb-resource combination that is distinct from sibling tools like get_rates or compare_jurisdictions.

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 advises when to use the tool: when a user asks 'when is X due', mentions a filing date, or needs a heads-up about an imminent deadline. It also notes that signed-in users with a saved home jurisdiction can omit the jurisdiction parameter. However, it does not explicitly state when not to use it or mention alternative tools for other types of queries.

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, openWorldHint, and destructiveHint false. The description adds behavioral context beyond annotations by specifying the exact fields returned (markdown, quality tier, verifier, footer). No contradictions.

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 sentence that communicates purpose and output effectively. It is front-loaded with the primary action. However, it could be slightly more structured (e.g., breaking out the list of included fields) to improve scanability.

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 has an output schema (not shown but present), the description does not need to detail return values. It covers the input (slug) and the output content. It could mention error conditions or required authentication, but annotations already indicate read-only access.

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 the schema already describes both parameters (slug and reason). The description mentions 'slug' in the first sentence but adds no semantic detail beyond the schema (e.g., example format). The 'reason' parameter is not elaborated in the description.

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 verb 'Fetch' and the resource 'published skill by slug', and lists the included fields (markdown, quality tier, named verifier, provenance footer). It distinguishes from siblings like search_skills which likely return lists, and get_skill_sections which may return different content.

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 implies use when you need a specific skill by slug, but does not explicitly state when to use this tool vs alternatives like search_skills or get_skill_sections. No 'when not to use' or comparison is provided.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, providing strong behavioral transparency. The description adds that output includes heading and markdown content, which is consistent but not a significant addition beyond 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?

Three sentences, front-loaded with purpose, followed by structure and usage. Every sentence is necessary and concise, with no wasted words.

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, usage, and the most important parameter. Minor omission: does not explicitly mention section_indices parameter, but schema handles it. Output schema exists, so return values are documented. Overall sufficient for correct tool selection.

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?

Input schema has 100% description coverage, so baseline is 3. Description adds useful context for section_index (linking to get_skill's section_index) but does not mention section_indices. Overall, it adds marginal 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 states it fetches parsed sections of a skill's current version, with each section containing heading and markdown content. It distinguishes from sibling tool get_skill by specifying it retrieves the actual content, not just indices.

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 guidance on when to use section_index (for a specific non-inlined section from get_skill's section_index) and when to omit it (to get all sections). Clearly differentiates use cases.

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?

Description adds valuable context about returned data fields and pre-computed nature, complementing annotations (readOnlyHint, idempotentHint, openWorldHint). Could mention if any latency or caching, but overall sufficient.

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 concise sentences plus a usage sentence. Front-loaded with key information, no redundant words.

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 parameters and an output schema, the description fully covers what the tool does, what it returns, and when to use it. Complete for its complexity.

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?

No parameters in schema, baseline 4. Description implicitly explains that no input is needed since it returns all jurisdictions. No further param detail required.

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?

Clear verb 'Returns' with specific resource 'jurisdictions' and detailed output fields (skill counts, verified counts, lead verifier). Explicitly distinguishes from sibling tool 'list_skills' by noting it avoids pagination.

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?

Provides explicit when-to-use examples ('which countries does OpenAccountants cover?', 'what's available for [country]?') and tells what to avoid ('Avoids paginating through list_skills').

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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds value by detailing what facets are returned (live jurisdictions, domains, etc.) and mentioning defaults, providing context beyond 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?

Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.

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 simplicity (no params, has output schema), description is complete. It explains what is returned and why to use it, and output schema covers return values.

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?

No parameters (0 params), so baseline is 4. Description does not need to add parameter info, and schema coverage is 100%.

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?

Description clearly states it returns metadata for filtering on search_rules, listing specific facets (jurisdictions, domains, roles, etc.). It distinguishes itself from sibling tools by explicitly tying to search_rules.

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 'Call this before search_rules to learn the valid filter values rather than guessing.' This provides clear when-to-use guidance, though no explicit when-not or alternatives are given, but the context is sufficient.

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 signal safety, and the description adds pagination details, total catalogue size, and filter suggestions, providing useful behavioral 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?

Two sentences, front-loaded with main purpose, no fluff. Every sentence adds essential information.

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, filters, pagination, and recommendations sufficiently for an agent to use the tool correctly. Output schema exists, so return value details are not needed.

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%, but description adds value by noting 'legacy' for category and emphasizing filter recommendations, aiding parameter understanding.

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 lists published skills with quality tier and verification status, and distinguishes by mentioning optional filters. It contrasts well with sibling tools like search_skills and get_skill.

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?

Provides guidance on pagination and strongly recommends jurisdiction/domain filters for efficient browsing. Does not explicitly compare to alternatives but gives context for when to use filters.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, read-only behavior. The description adds context by specifying that it returns 'named licensed accountants', but does not introduce any additional behavioral traits beyond what annotations cover.

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 concise, consisting of two sentences that front-load the purpose and provide clear usage guidelines. No superfluous information is present.

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 simplicity (one optional parameter, robust annotations, and an output schema), the description is complete. It covers the tool's purpose, usage context, and restrictions without needing additional elaboration.

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%, with the single parameter 'jurisdiction' already described in the schema as 'Optional ISO code filter — only return verifiers for this jurisdiction.' The tool description does not add extra meaning beyond the schema's description, so baseline score of 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?

The description clearly states the verb 'Returns', the resource 'named licensed accountants', and the context 'who have signed off on OpenAccountants jurisdictions'. It distinguishes itself from sibling tools by providing specific usage instructions, such as not using it to check jurisdiction coverage.

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 explicit when-to-use conditions ('when the user explicitly asks to see the verifier network or 'who verified this skill'') and when-not-to-use ('Do NOT use this to check whether a jurisdiction is covered before calling request_accountant_review'). It also gives an alternative action: 'just call request_accountant_review directly'.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds that the tool returns ALL matching rules by default, each tagged with verification status, and mentions the default limit. This enriches understanding without contradiction.

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 concise, well-structured, and front-loaded with the core purpose. Two paragraphs cover purpose, differentiation, examples, and usage guidance without extraneous information.

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 12 parameters, 0 required, high schema coverage, and an existing output schema, the description adequately explains the tool's behavior, filtering capabilities, and default outputs. It is complete for an agent to understand and invoke 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 100% and each parameter has a description. The description adds context on parameter interactions, such as the relationship between status and statuses, and references list_rule_facets for querying valid domains, providing 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 states that the tool queries tax rules/facts across jurisdictions and returns a bundled markdown set. It distinguishes from sibling get_skill by emphasizing cross-cutting assembly and provides specific examples like 'VAT rates in MT, IE and DE'.

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 contrasts with get_skill (one whole skill) and advises calling list_rule_facets first. Gives examples of appropriate use cases and explains status filtering options, guiding the agent on when and how to use the 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, openWorldHint, idempotentHint, and destructiveHint=false. Description adds value by explaining that search is across 'published' skills, that content_type='method' returns step-by-step procedures with review_status, and that jurisdiction filtering is optional.

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?

Single well-organized paragraph with front-loaded main action. Every sentence contributes value, though it is somewhat lengthy but appropriate given the guidance provided.

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?

Output schema exists, so return values need not be described. Description covers all relevant aspects: search scope, content type differentiation, jurisdiction limiting, and use cases. Sibling tools like get_skill and list_skills are implicitly distinguished via guidance. Complete given complexity.

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%. Description adds meaning beyond schema: provides example query values, explains the effect of content_type='method' vs 'fact', and mentions review_status for methods. This is above baseline 3.

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 it performs full-text search across published tax and accounting skills, and explicitly says 'Use this when you don't know the exact skill slug' to distinguish from get_skill. This is specific and differentiates from siblings.

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?

Provides explicit when-to-use guidance ('when you don't know the exact skill slug'), how to use content_type to find methods vs facts, and includes examples. It implicitly tells when not to use (if you know slug, use get_skill).

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 contradicts annotations: annotations say readOnlyHint: true, but the tool is clearly a write operation (saves to queue, sends data). The detailed disclosure of what it carries and returns is positive, but the contradiction is a critical failure.

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 overly long (multiple paragraphs, >300 words). It contains repetitive elements and could be streamlined. While information-rich, it lacks conciseness for quick agent parsing.

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 (9 parameters, conditional review logic), the description covers all necessary context: parameter purposes, conditional requirements, anonymity rules, and interaction scripts. No gaps.

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% (baseline 3). The description adds extensive value: explains the meaning of 'note' as a DIFF, conditions for 'skill_slug' vs 'submit_feedback', and detailed conditions for review parameters. It provides examples and clear usage rules.

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 this is 'THE one outbound channel' for feedback and review, and explicitly distinguishes from siblings: 'Do NOT use any other tool for feedback or review — everything goes through here.' The verb 'share' and resource 'OpenAccountants' establish a clear, unique purpose.

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?

Provides explicit when-to-use guidance: 'at your closing, make ONE warm offer' and includes a script. States that review is optional and only when user asks, and explicitly forbids using other tools for feedback or review.

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 (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) are all consistent with the description. Description adds behavioral details: returns clarification if jurisdiction missing, otherwise a plan with skills to load, and explains how taxpayer_type is handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three paragraphs are well-structured: first defines purpose and required fields, second details return behavior, third provides usage order. Every sentence adds value without redundancy.

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 5 parameters with 2 required and an output schema, the description fully explains tool behavior, parameter semantics, usage order, and alternative tool. It covers all necessary context for correct invocation.

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 covers all 5 parameters (100% coverage). Description adds crucial context: intent is REQUIRED, acting_as must be predefined, jurisdiction triggers clarification if missing, taxpayer_type has detailed enum meanings and guidance to not guess.

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 identifies the tool as the initial entry point for tax workflows once intent is known, distinguishes it from start_help (for unknown intents), and explains its return values (clarification or plan).

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 states when to use (after start_help if intent is known) and when not to (use start_help if intent unknown), provides prerequisites (acting_as must be established), and warns against guessing taxpayer_type.

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, openWorldHint, idempotentHint as true, and destructiveHint as false. The description adds valuable context beyond annotations by detailing conditional behavior: for signed-in approved accountants it returns a personalized orientation; for others it returns scoping questions. No contradictions.

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, with the key instruction front-loaded. It is efficient and every sentence adds value, though the first sentence is somewhat long. Could be slightly more terse, but overall well-structured.

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 has no parameters and an output schema exists, the description sufficiently covers what the tool returns for two user categories. It provides actionable next step. It lacks details on error handling or non-signed-in user behavior, but is complete enough for a simple scoping 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?

The tool has no parameters, and the description explicitly states 'No-argument front door'. Schema coverage is 100% (trivial). The description adds no further parameter info needed. Baseline 4 for zero 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 clearly states it is a no-argument front door for scoping guidance, with explicit verb ('get scoping guidance') and resource. It distinguishes from sibling tool list_jurisdictions by stating 'do NOT answer such questions by listing your tools or calling list_jurisdictions'.

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 explicit when-to-use instructions: 'call this FIRST whenever a user asks how can you help me?' It also tells when not to use alternatives and gives next action: 'Once you have an intent, call start(intent, jurisdiction).'

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?

Discloses live external dependency, unfakeability, and that it admits registry unavailability rather than inventing answers. Annotations already indicate read-only and idempotent, and description adds critical behavioral context beyond them.

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?

Description is relatively long but every sentence serves a purpose: purpose, use cases, limitations, behavior. Could be slightly tighter but well-structured and front-loaded with key info.

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—live external lookup, EU-only coverage, specific business use cases—the description fully addresses what agents need to know. Output schema handles return values, so description is complete.

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 baseline is 3. Description adds practical examples, explains optional country_code usage, and clarifies handling of prefixes, enhancing usability beyond 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 description clearly states the tool checks VAT numbers live against government registries and returns registered business name and address. It distinguishes from siblings by being the only tool for this specific authoritative verification.

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 tells when to use (before applying B2B reverse charge, zero rating, onboarding vendor) and when not to (non-EU numbers, tells user to inform rather than guess). Provides clear coverage scope.

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