openregistry

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

The description adds valuable behavioral context beyond annotations: it specifies the default response size (<1KB), mentions 'pricing' and 'rate limits' as included information, and explains the relationship between 'jurisdiction' section and parameter. While annotations cover safety (readOnlyHint, destructiveHint), the description provides operational details about response format and parameter interactions.

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 efficiently structured: first sentence establishes the core purpose and default behavior, second explains parameter usage with clear examples, third provides an alternative recommendation. Every sentence adds value with zero redundancy, and key information is front-loaded.

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 informational nature, rich annotations (readOnlyHint, openWorldHint, idempotentHint), and complete schema coverage, the description provides excellent contextual completeness. It covers purpose, usage patterns, parameter interactions, output characteristics (size constraint), and even directs to alternatives when deeper jurisdiction data is 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?

With 100% schema description coverage, the baseline is 3, but the description adds meaningful context: it explains that omitting parameters yields the 'compact default envelope,' clarifies that 'jurisdiction' parameter is 'required only when section='jurisdiction',' and provides the practical purpose of expanding 'specific slices' of information. This goes beyond the schema's technical specifications.

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 provides a 'compact self-description' of the server with specific content (server name, version, jurisdiction codes, tool names, pricing, rate limits). It clearly distinguishes this from sibling tools by being the only meta-information tool, while all others perform data operations like fetching company records or searching.

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 guidance: 'Omit for the compact default envelope' for basic info, and specifies when to use the optional parameters - 'Pass `section` to expand a specific slice' with enumerated options. It also gives a clear alternative: 'For the full per-jurisdiction schema... prefer list_jurisdictions,' directly naming a sibling 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?

The description adds valuable behavioral context beyond annotations: it explains the return structure ('Returns { query, available, warning, similar_names[] }'), defines availability logic ('available is true only when upstream does not emit the 'Name entered already exists' warning AND the similar-names table is empty'), and notes jurisdiction limitations ('Other jurisdictions return 501'). Annotations cover read-only, open-world, idempotent, and non-destructive traits, but the description enriches this with specific endpoint behavior and constraints.

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 core purpose, followed by return details, availability logic, and operational notes. Each sentence adds value: endpoint specification, return structure, availability criteria, pricing/login info, and jurisdiction limits. 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?

Given the tool's moderate complexity, rich annotations (read-only, open-world, idempotent, non-destructive), and 100% schema coverage, the description is complete. It explains the endpoint, return format, availability logic, jurisdiction scope, and cost/access details. No output schema exists, but the description adequately 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?

Schema description coverage is 100%, so parameters are well-documented in the schema. The description does not add significant parameter semantics beyond what the schema provides, though it implies the tool's focus on 'company_name' and 'jurisdiction' as core inputs. Baseline 3 is appropriate given high schema coverage.

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 purpose: 'Probe the Isle of Man Companies Registry 'Check Name Availability' endpoint' to check 'whether a proposed company name is available'. It specifies the jurisdiction ('IM only') and distinguishes it from siblings by focusing on name availability rather than searching, counting, or fetching company data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage guidelines: it specifies when to use ('Check whether a proposed company name is available'), when not to use ('Other jurisdictions return 501'), and alternatives implicitly (e.g., use search_companies for broader queries). It also notes prerequisites: 'no login required' and 'Pricing: free'.

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 adds significant behavioral context beyond what annotations provide. While annotations indicate read-only, open-world, idempotent, and non-destructive operations, the description adds: performance characteristics (~2s average, similar to full search), pricing (free), jurisdiction-specific behavior (IE only, others return 501), endpoint mapping (/companycount), and return format (plain integer). This provides practical implementation details not captured in 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 efficiently structured with clear sections: purpose statement, performance warning with specific guidance, jurisdiction details, and parameter mapping. Every sentence adds value—no redundant information. The use of emojis and formatting (⚠️, ──) enhances readability without adding fluff.

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 (7 parameters, jurisdiction-specific behavior, performance considerations) and lack of output schema, the description provides comprehensive context. It covers purpose, usage scenarios, performance trade-offs, jurisdiction limitations, endpoint mapping, pricing, return type, and parameter relationships. This makes the tool's behavior and constraints fully understandable to an agent.

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 only 29% schema description coverage, the description compensates well by explaining parameter context. It notes that parameters 'support the same filters as search_companies' and lists them (query, match_type, bus_ind, include_business_names, address, alpha), providing semantic meaning beyond the bare schema. However, it doesn't explain individual parameter purposes or constraints in detail, keeping it at a 4 rather than 5.

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: 'Return the total number of companies that would match a search, without fetching the candidates themselves.' It specifies the verb ('return'), resource ('companies'), and scope ('matching a name/filter'), and distinguishes it from sibling tools like search_companies by emphasizing it only provides a count, not the actual results.

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 guidance on when to use this tool versus alternatives. It states it's 'useful before paginating very large result sets' and gives a specific example ('how many Coffee business names exist in Ireland?'). It also explicitly advises against using it for performance reasons in some cases, recommending 'search_companies with limit=1' instead for checking query narrowness, and notes jurisdiction limitations (IE only, others return 501).

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 adds substantial behavioral context beyond annotations: it explains the two response shapes (embedded vs resource_link), details workflow steps for oversized documents, provides critical rules about citation practices and error handling, describes caching behavior and auto-resolution mechanisms, and explains jurisdiction-specific considerations. While annotations cover basic safety (readOnlyHint, idempotentHint), the description adds rich operational context.

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 well-structured with clear sections (Response Shapes, Workflow, Critical Rules) and uses bullet points effectively. While comprehensive, it maintains focus on essential information - every sentence serves a clear purpose in guiding tool usage. The front-loaded statement about being the 'Primary tool for reading a filing's content' immediately establishes 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 (9 parameters, no output schema), the description provides exceptional completeness: it covers response formats, error handling, workflow integration with sibling tools, jurisdiction considerations, caching behavior, and practical usage constraints. The description fully compensates for the lack of output schema by detailing what the tool returns and how to interpret different response types.

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 89% schema description coverage, the baseline would be 3, but the description adds meaningful context about parameter usage: it explains the primary use of document_id (from list_filings/get_financials), clarifies that override parameters are for 'rare use' cases, provides practical guidance on format selection ('recommended — XHTML > XML > JSON > PDF'), and explains the practical implications of max_bytes settings. This adds significant value beyond the schema descriptions.

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 this is the 'Primary tool for reading a filing's content' and distinguishes it from sibling tools by explaining that filing metadata alone is insufficient - the actual content requires this tool. It clearly identifies the verb (reading/fetching) and resource (filing documents).

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 comprehensive usage guidance: it specifies when to use this tool ('MANDATORY for any substantive answer'), explains the workflow for different response types, distinguishes when to use sibling tools like 'fetch_document_pages' and 'get_document_navigation', and explicitly states when NOT to use certain approaches ('Don't reflexively retry with a larger max_bytes').

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 adds valuable behavioral context beyond annotations: the 100-page hard cap, the need to cache documents first, format-specific behaviors (e.g., 'pdf' preserves text layers, 'text' may have OCR errors, 'png' may return 'not implemented'), and performance considerations. Annotations cover safety (readOnlyHint=true, destructiveHint=false), but the description enriches this with practical constraints.

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 well-structured with bullet points for format options and clear, front-loaded sentences. Every sentence adds value: it explains formats, usage scenarios, limitations, and prerequisites without redundancy. The information density is high and efficiently organized.

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 (7 parameters, no output schema), the description is highly complete. It covers purpose, usage guidelines, behavioral traits, parameter semantics, and limitations. The lack of output schema is compensated by detailed format explanations. It provides all necessary context for an agent to use the tool effectively.

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 86% schema description coverage, the baseline is 3, but the description adds meaningful context: it explains the semantic differences between format options in detail (e.g., 'pdf' for citation-grade content, 'text' for machine-readable but not authoritative), which complements the schema's enum descriptions. It also clarifies the pages parameter's 100-page limit and splitting advice.

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 with specific verbs ('return specific pages') and resources ('PDF'), distinguishing it from sibling tools like fetch_document (which fetches full documents) and get_document_metadata (which provides metadata). It explicitly mentions the three output formats and their characteristics.

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 guidance on when to use each format ('pdf' for authoritative content, 'text' for summarization, 'png' for scanned documents), when not to use them (e.g., 'text' is not authoritative for numbers), and prerequisites ('call fetch_document on the full document first if this is a new filing'). It also mentions the 100-page limit and suggests splitting larger ranges.

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, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies that empty results return an empty list (not an error), describes jurisdiction-specific limitations, and mentions error codes (501) for unsupported cases. No contradiction with annotations exists.

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 well-structured and front-loaded with core functionality, followed by important caveats and alternatives. Every sentence adds value: the first defines purpose, the second details return fields, the third covers edge cases, and the fourth explains jurisdiction limitations and workarounds. 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?

Given the tool's complexity (jurisdiction-dependent, multiple return fields) and lack of output schema, the description is highly complete. It details return fields (charge_id, status, etc.), edge cases (empty list for no charges), error handling (501 for unsupported jurisdictions), and links to other tools for further context. Annotations cover safety, so the description focuses on operational nuances.

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 schema description coverage at only 33% (1 of 3 parameters described), the description compensates by clarifying parameter semantics. It explains that 'jurisdiction' scope affects results and links to `list_jurisdictions` for details, and implies 'company_id' identifies the target company. However, it doesn't detail the 'fresh' parameter's effect.

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: 'Return charges (mortgages, fixed and floating charges, pledges, security interests) registered against a company.' It uses specific verbs ('return', 'registered against') and resources ('charges', 'company'), and distinguishes itself from siblings by specifying it's for 'security-interest and lender analysis' rather than general company data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use alternatives: 'Unsupported jurisdictions return 501; some return 501 and suggest `list_filings(category='charges')` as an alternative.' It also advises calling `list_jurisdictions` for per-country scope details, giving 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it specifies the return format ('flat object: { code: description, … }'), mentions pricing ('free'), and documents jurisdiction limitations ('Other jurisdictions return 501'). However, it doesn't mention caching behavior despite the 'fresh' parameter existing.

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 perfectly structured with clear jurisdiction sections, bullet-like formatting for code examples, and no wasted words. Every sentence adds value: purpose statement, jurisdiction-specific details, return format, pricing, and error conditions. The information is front-loaded with the core purpose 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 read-only lookup tool with comprehensive annotations and 100% schema coverage, this description provides excellent contextual completeness. It covers jurisdiction variations, code examples, language support, return format, pricing, and error cases. The lack of output schema is compensated by explicitly describing the return format. No significant gaps remain for this type of 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?

With 100% schema description coverage, the baseline is 3. The description adds meaningful context beyond the schema: it organizes parameters by jurisdiction (FI/CZ/CH sections), provides concrete code examples for each jurisdiction, clarifies language applicability ('FI only — CZ ignores'), and explains the purpose of the 'fresh' parameter ('Bypass the cache'). This significantly enhances understanding beyond the schema's technical definitions.

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 'resolve' and resource 'registry code-list', specifying it converts codes to human-readable descriptions. It explicitly distinguishes this from sibling tools by mentioning its specific use for 'decoding values seen in jurisdiction_data fields', which none of the sibling tools appear to do.

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 guidance ('useful for decoding values seen in jurisdiction_data fields'), jurisdiction-specific code lists, language support details, and clear exclusions ('Other jurisdictions return 501'). It also distinguishes when language matters (FI only) versus when it's ignored (CZ).

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 adds valuable behavioral context beyond the annotations. While annotations declare read-only, non-destructive, and idempotent operations, the description details the return structure (unified fields plus jurisdiction_data), explains status field semantics, describes caching behavior ('fresh: true bypasses the cache'), and mentions performance implications of optional flags ('slower', 'doubles upstream calls'). No contradictions with annotations are present.

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 well-structured and efficiently packed with information. It front-loads the core purpose, then details return values, exclusions, input guidance, optional flags, and per-country caveats. While comprehensive, some sentences are lengthy, and the density of information might slightly reduce immediate clarity, though every sentence adds value.

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 (6 parameters, no output schema, rich annotations), the description is largely complete. It covers purpose, usage, return structure, exclusions, input guidance, and jurisdictional nuances. However, without an output schema, it could more explicitly detail the full return format or error conditions, though the annotations provide safety context.

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 100% schema description coverage, the baseline is 3. The description adds meaningful context beyond the schema: it explains the variability of company_id formats, provides guidance on obtaining company_id from 'search_companies', clarifies that optional flags are jurisdiction-specific and ignored elsewhere, and explains the purpose of the fresh parameter. However, it doesn't fully detail all parameter interactions or edge cases.

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: 'Fetch the full profile of a company by its registry-specific ID.' It specifies the verb ('fetch'), resource ('company profile'), and key identifier ('registry-specific ID'), and distinguishes it from siblings by explicitly listing what it does NOT include (filings, officers, etc.) and naming alternative tools for those purposes.

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 guidance on when to use this tool versus alternatives. It states what the tool does NOT include and names specific sibling tools for those purposes (e.g., 'list_filings', 'get_officers'). It also advises pulling company_id from 'search_companies' rather than guessing, and directs users to 'list_jurisdictions' for per-country details.

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, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it explains error conditions (404/502 for synthesized IDs, 501 for paywalled/unsupported jurisdictions), availability caveats (available_formats may be empty), and the purpose of checking metadata before downloading large documents. 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 efficiently structured with clear paragraphs: first states purpose and returns, second provides usage guidance, third gives critical warnings, and fourth covers edge cases. Every sentence adds value without redundancy, and key points are front-loaded (e.g., the warning about not constructing IDs is emphasized).

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 (metadata retrieval with jurisdiction-specific behaviors), the description is highly complete. It covers purpose, usage, prerequisites, error cases, and relationships to other tools. While there's no output schema, the description details return values (formats, sizes, page count, etc.). The annotations provide safety context, and the description fills in behavioral nuances adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67% (2 of 3 parameters have descriptions). The description adds meaningful context for document_id beyond the schema's 'Document ID from a previous list_filings call' by warning against constructing IDs and explaining composite ID formats. It also clarifies jurisdiction usage by referencing list_jurisdictions for details. However, it doesn't explicitly address the 'fresh' parameter's 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 specific action ('retrieve metadata') and resource ('filing document'), distinguishing it from sibling tools like fetch_document (which downloads content) and list_filings (which lists documents). It explicitly mentions what metadata is returned (content formats, byte sizes, page count, source URL, creation date, jurisdiction_data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('call this before fetch_document when the document might be large or you don't yet know the format') and when not to use it ('do NOT construct or guess document_id values'). It names specific alternatives (list_filings for obtaining IDs, fetch_document for downloading, list_jurisdictions for jurisdiction details).

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, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context: navigation aids may be truncated, contain OCR errors, or have false positives, and it explains the caching requirement and the 'fresh' parameter's effect. 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 well-structured with clear sections: purpose, returns, critical warnings, and prerequisites. It's front-loaded with key information, though it could be slightly more concise by integrating some details (e.g., jurisdiction support) more tightly. Every sentence adds value, but minor redundancy exists.

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 (navigation for large documents) and lack of output schema, the description is mostly complete: it explains purpose, usage, behavioral caveats, and prerequisites. However, it doesn't detail the exact structure of returned navigation data (e.g., format of outlines or landmarks), which could aid agent interpretation. Annotations cover safety aspects well.

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 80%, so the schema documents most parameters well. The description adds context for 'jurisdiction' by mentioning it's for official government sources and referencing 'list_jurisdictions' for details, but doesn't explain other parameters like 'document_id' or 'fresh' beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.

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: 'Open the navigation index for a cached document' and specifies it returns 'outline (PDF bookmarks), per-page text previews, keyword-matched landmarks, text_layer classification, and source URLs.' It distinguishes from siblings like 'fetch_document_pages' by emphasizing this is for navigation aids only, not authoritative 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 provides explicit usage guidelines: call this FIRST for large PDFs or when locating sections, NEVER cite navigation aids as source material, and always follow up with 'fetch_document_pages' for authoritative content. It also specifies prerequisites: requires cached document bytes and to call 'fetch_document' first for new documents, clearly differentiating from alternatives.

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 adds significant behavioral context beyond annotations. Annotations indicate read-only, open-world, idempotent, and non-destructive, but the description elaborates on implementation details: it normalizes fiscal-period shape, pre-computes download URLs, returns newest-first, walks the entire accounts history due to late-filed amendments, and mentions error conditions (501 if adapter lacks support). It also describes the return structure (items with fields like `period_end`, `document_id`, etc.) and per-country caveats, providing rich behavioral transparency that annotations alone don't 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 appropriately sized and front-loaded, starting with the core purpose and key enhancements. It efficiently covers usage, behavior, parameters, and caveats in a structured manner without unnecessary repetition. However, it could be slightly more concise by integrating some details (e.g., the per-country caveats paragraph is lengthy but necessary), so it's not perfectly minimal but still highly effective.

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 (6 parameters, no output schema), the description is complete enough. It covers the purpose, usage guidelines, behavioral traits, parameter semantics, error conditions, and per-country considerations. While there's no output schema, the description details the return structure (items with specific fields), and annotations provide safety context. This addresses all necessary aspects for an agent to use 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?

With schema description coverage at 83%, the baseline is 3, but the description adds meaningful context beyond the schema. It explains filter precedence (`period_end` takes precedence over `year`), clarifies that `limit` caps post-filter results and can be omitted to return all matches, and notes that the whole accounts history is walked per query. However, it doesn't detail all parameters (e.g., `fresh` is not mentioned), so it doesn't fully compensate for the 17% gap, warranting a 4 rather than a 5.

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 'returns annual-accounts filings (financial statements) for a company' and distinguishes it from sibling tools by explaining it's a 'convenience wrapper over `list_filings(category='accounts')`' with specific enhancements like normalization and pre-computed URLs. This provides a specific verb+resource+scope and differentiates from alternatives like `list_filings` or `fetch_document`.

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 this tool vs alternatives: it's a convenience wrapper over `list_filings(category='accounts')` that adds normalization and pre-computed URLs to avoid a second round-trip. It also mentions when not to use it (if the adapter doesn't implement `list_filings`, it returns 501) and provides guidance on per-country caveats by referring to `list_jurisdictions`. This covers explicit when/when-not/alternatives.

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=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it discloses pagination ('Results are paginated'), which is crucial for usage, and implies data freshness considerations through the 'fresh' parameter in the schema. No contradiction with annotations exists.

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 efficiently structured in three sentences: first states the core functionality, second provides usage context and differentiation, third discloses pagination. Every sentence adds value without redundancy, and it's front-loaded with the main 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 moderate complexity (5 parameters, paginated results) and rich annotations covering safety, the description is largely complete: it explains purpose, usage, and key behavior (pagination). However, with no output schema, it doesn't describe return values or error handling, which could be helpful for an agent. The parameter guidance is adequate but not exhaustive.

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 40%, with officer_id and jurisdiction having descriptions but fresh, limit, and cursor lacking them. The description compensates by explaining the officer_id parameter's source ('from get_officers or search_officers') and the tool's overall purpose, which helps infer parameter roles. However, it doesn't detail all parameters like cursor or fresh, keeping it from a perfect score.

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 specific action ('return every company'), resource ('in the registry'), and scope ('where that person has held an appointment') with distinguishing details like 'cross-company tracing tool' and 'follow a person's full corporate footprint' that differentiate it from sibling tools like get_officers or search_officers. It explicitly mentions the returned fields (role, appointed_on, resigned_on dates).

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 guidance on when to use this tool ('Given an officer_id from get_officers or search_officers') and its purpose ('cross-company tracing tool — use it to follow a person's full corporate footprint across the registry'), clearly distinguishing it from sibling tools that focus on single-company data or different search methods. It effectively tells the agent when this specific tool is appropriate.

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 adds significant behavioral context beyond annotations: it explains GDPR masking, jurisdiction-specific limitations (e.g., birth-date precision, 501 gating), cache bypass with 'fresh: true', and how flags are ignored on unsupported registries. While annotations cover read-only, open-world, and idempotent hints, the description enriches this with practical constraints and data source details without contradicting 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 well-structured and front-loaded with core functionality, followed by details on data shape, flags, and caveats. While comprehensive, it remains focused with minimal redundancy, though some sentences could be slightly tightened (e.g., the per-country caveats paragraph is dense but informative).

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 (5 parameters, no output schema, rich annotations), the description is highly complete: it covers purpose, usage, data format, parameter semantics, jurisdiction-specific behaviors, and links to other tools for further details. It addresses gaps from missing output schema by describing the unified shape of returned officers and potential errors like 501.

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 schema description coverage at 60%, the description compensates by explaining parameter implications in detail: it clarifies the default and effect of 'include_resigned', specifies that 'group_by_person' is for CZ only, and notes that 'fresh' bypasses cache. It also adds context for 'jurisdiction' and 'company_id' by linking to other tools for support details, enhancing understanding 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 the tool's purpose: 'Return the officers of a company' with specific details about what constitutes an officer (directors, secretaries, members, etc.) and distinguishes it from sibling tools like 'get_officer_appointments' by explaining the relationship between them. It goes beyond a simple list to explain the unified shape of returned data and cross-company tracing capabilities.

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 guidance on when to use this tool versus alternatives: it mentions using 'get_officer_appointments' for cross-company tracing with officer_id, and directs users to 'list_jurisdictions' for per-country caveats and support details. It also explains when certain flags are applicable (e.g., 'group_by_person' for CZ only) and when jurisdictions return 501 errors.

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, open-world, idempotent, and non-destructive hints, but the description adds significant behavioral context beyond this. It explains that returns may be an empty list for companies with no filing, unsupported jurisdictions return 501 with alternative tool suggestions, and details on per-country availability, historical-entry behavior, and paid-tier gates. This enriches the agent's understanding of edge cases and limitations.

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 well-structured and front-loaded with the core purpose, followed by usage guidelines, output details, and behavioral notes. Each sentence adds value without redundancy, such as clarifying sibling tool differences and jurisdiction-specific behaviors, making it efficient and easy to parse.

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 (involving jurisdiction-specific rules, sibling tool distinctions, and no output schema), the description is highly complete. It covers purpose, usage, output fields, edge cases (empty lists, error codes), and directs to other tools for further context, ensuring the agent has sufficient information to use the tool effectively despite the lack of structured output details.

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 50%, with only the 'jurisdiction' and 'include_ceased' parameters described in the schema. The description compensates by explaining the output structure (e.g., fields like 'name', 'kind', 'nature_of_control') and contextualizing parameters indirectly through examples of jurisdiction codes and usage notes. However, it doesn't explicitly detail all input parameters beyond what the schema provides, keeping it from a perfect score.

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 returns persons with significant control (PSCs/beneficial owners) of a company, specifying these are individuals on a statutory-threshold register typically with >25% ownership or voting rights. It clearly distinguishes this from the sibling tool `get_shareholders` by explaining the different registers and thresholds, making the purpose specific and differentiated.

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 guidance on when to call this tool (e.g., for 'beneficial owners', 'UBO', 'PSC', 'who controls', or >25% threshold queries) and when not to (e.g., for plain 'shareholders' questions, directing to `get_shareholders` instead). It also mentions alternative tools like `list_jurisdictions` for checking availability, offering clear usage context and 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 cover read-only, open-world, idempotent, and non-destructive hints. The description adds valuable context beyond annotations: it explains that responses may vary by jurisdiction (e.g., empty lists for joint-stock companies, structured arrays or document pointers), includes disclosure flags, mentions caching behavior with `fresh: true`, and notes that unsupported jurisdictions return 501. It also references per-country caveats and how to access them via other tools, though it doesn't detail rate limits or auth needs.

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 well-structured with clear sections (e.g., 'When to call this tool,' public disclosure details, per-country caveats) and uses bold for emphasis. It is appropriately sized for the tool's complexity, though some sentences are lengthy. Every sentence adds value, such as explaining jurisdictional variations and tool interactions, with minimal 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 the tool's complexity (legal-registry data with jurisdictional variations), no output schema, and rich annotations, the description is highly complete. It covers purpose, usage guidelines, behavioral nuances (e.g., response shapes, caching, error codes), parameter context, and references to other tools for further details. It adequately compensates for the lack of output schema by describing possible response types and flags.

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 low (33%), with only the 'jurisdiction' parameter described in the schema. The description compensates by explaining the purpose of 'fresh' (bypasses cache) and implying 'company_id' identifies the target company. It also adds context about jurisdiction codes (ISO 3166-1 alpha-2) and references `list_jurisdictions` for details, though it doesn't fully document all parameter formats or constraints beyond what's implied.

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 returns 'the shareholders / members / quota-holders of a company' from the 'legal-statutory equity roster published by the company registry,' with explicit scope ('no ownership-threshold filter'). It distinguishes from sibling `get_persons_with_significant_control` by explaining the different registers and concepts, making the purpose specific and well-differentiated.

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 guidance on when to use this tool (e.g., for 'shareholders', 'members', 'quota-holders' in various languages) and when not to use it (e.g., not for PSC/beneficial owners unless explicitly asked). It names the alternative tool (`get_persons_with_significant_control`) and explains the conceptual differences, including examples of disagreement between registers.

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 adds valuable behavioral context beyond what annotations provide: it explains the 404 error condition ('Returns 404 if the IČO doesn't exist in that specific source register'), mentions pricing ('Pricing: free'), and describes the response structure ('full upstream record is returned verbatim under `record`'). While annotations cover read-only/idempotent aspects, the description provides important operational details.

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 well-structured with clear sections (purpose, source code list, usage guidance, error conditions), but contains some redundancy (repeating 'CZ' in the source code list header when already mentioned in title). Most sentences earn their place by providing essential information, though it could be slightly more concise in the source code explanations.

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 (multiple jurisdictions, many source registers, different parameter formats) and lack of output schema, the description provides comprehensive context: it explains what each source register contains, when to use the tool, error conditions, pricing, response structure, and references external documentation. This adequately compensates for the missing output 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?

With 75% schema description coverage, the description adds significant value by providing the complete list of CZ source codes with explanations of what each register contains (e.g., 'rzp — Trade Licence Register... trade licences a sole trader / company holds'), which helps users understand the semantic meaning of the 'source' parameter beyond what the schema provides. The description also clarifies jurisdictional differences in parameter usage.

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 ('retrieve') and resource ('record from specialised source registers'), and explicitly distinguishes it from sibling tools by naming specific alternatives (get_company_profile, get_officers/get_psc/get_charges) and explaining when to use this tool instead ('when the basic... don't have the field you need').

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 guidance on when to use this tool versus alternatives ('Use this when the basic get_company_profile or get_officers/get_psc/get_charges don't have the field you need'), includes specific examples of use cases (e.g., 'trade-licence specialisations for sole traders → rzp'), and mentions jurisdictional limitations ('Other jurisdictions return 501').

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, covering safety and idempotency. The description adds valuable context beyond annotations: performance details (cost per day, default/hard caps, caching), geographic restriction (ES only), and output format (what each hit includes). It does not contradict annotations, but could mention rate limits or error handling more explicitly.

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, with the first sentence stating the core purpose. It uses paragraphs to organize information (purpose, output details, performance, restrictions), but some sentences are lengthy and could be tightened for better readability without losing essential details.

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 (10 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose, usage, behavioral traits, and output structure. However, it lacks explicit details on error cases or response format beyond hit fields, which could be helpful given the absence of an output 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 100%, so the schema already documents all 10 parameters thoroughly. The description adds some semantic context, such as explaining that the adapter does not parse specific fields from texto_raw, but it does not provide significant additional meaning beyond what the schema descriptions already cover for parameters like company_id or act_types.

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 scans BORME Section I and B PDFs across date ranges to return acto paragraphs matching a company name, distinguishing it from the per-company search (which only indexes Section II). It specifies the resource (BORME PDFs) and verb (scans/returns), with explicit differentiation from sibling tools like search_companies.

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 guidance on when to use this tool (to recover statutory registered acts not exposed by the per-company search) and when not to use it (for Section II announcements). It mentions calling search_companies first to obtain the canonical company name form, and it notes performance considerations like date range caps and chunking longer windows client-side.

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 adds valuable behavioral context beyond annotations. Annotations indicate read-only, open-world, idempotent, and non-destructive operations, but the description elaborates on pagination behavior ('Page forward via `offset`/`limit` until the returned array is empty'), jurisdiction limitations ('CZ only'), and response structure details (e.g., 'total_changes', 'pagination', 'Raw upstream fields'). It does not contradict annotations, as it describes a data retrieval tool consistent with read-only 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?

The description is well-structured and front-loaded, starting with the core purpose, followed by mode explanations, operational details, and caveats. Every sentence adds value—e.g., clarifying pagination, jurisdiction limits, and related tool calls—without redundancy. It efficiently covers complex functionality in a compact format.

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 (two modes, jurisdiction constraints, pagination) and lack of an output schema, the description does an excellent job of explaining behavior, limitations, and usage. It covers key aspects like response fields, pagination logic, and error cases (e.g., 501 for non-CZ). A minor gap is the absence of explicit error handling details beyond the 501 note, but overall it's highly complete for the context.

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 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds some semantic context by explaining how parameters like `batch_id` and `source` switch between modes and affect behavior, but it doesn't provide significant additional meaning beyond what's in the schema. This meets the baseline for high schema coverage.

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 with specific verbs ('Access', 'returns') and resources ('change-batch feed', 'incremental delta batches', 'company ID that changed'). It distinguishes this tool from siblings by focusing on change-notification batches rather than company profiles, documents, or searches, making its scope explicit.

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 guidance on when to use this tool vs alternatives. It specifies that it's 'Currently only available for CZ; other jurisdictions return 501' and directs users to 'call `list_jurisdictions({jurisdiction:"<code>"})`' for per-country details. It also distinguishes between two modes (list vs. detail) based on parameter usage, offering clear operational context.

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, open-world, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: it specifies the data source (KBO Public Search vestiginglijst.html), pricing (free), error handling for other jurisdictions (returns 501), and details about the return structure (array with specific fields). This enriches the agent's understanding without contradicting 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: it starts with the core purpose, then explains what an establishment unit is, details the return structure, and ends with pricing and error handling. Every sentence adds value without redundancy, making it efficient and 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's moderate complexity, rich annotations, and lack of output schema, the description is complete: it explains the purpose, data source, return format, pricing, and error conditions. This provides sufficient context for an agent to use the tool effectively, compensating for the missing output schema with clear return details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents parameters. The description does not add meaning beyond the schema for parameters like 'fresh', 'company_id', or 'jurisdiction'. It implies jurisdiction must be 'BE' but doesn't clarify parameter interactions. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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 'Return[s] every establishment unit attached to a Belgian enterprise number' and distinguishes it from siblings by specifying it's for Belgian establishments only (BE only in title) and listing physical location details. It explains what an establishment unit is versus the enterprise legal entity, making the purpose specific and differentiated.

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 clear context for when to use this tool: for Belgian enterprises to get establishment units from the KBO Public Search. It implicitly excludes other jurisdictions by stating 'Other jurisdictions return 501.' However, it does not explicitly name alternatives among sibling tools or specify when not to use it beyond jurisdiction limits.

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 adds substantial behavioral context beyond what annotations provide. While annotations declare readOnlyHint=true, idempotentHint=true, etc., the description details pagination behavior (limit default 25, max 1000, cursor vs offset pagination), jurisdiction limitations (unsupported jurisdictions return 501), document availability constraints (has_document flag, paywalled bodies), and sorting order (newest-first). This provides crucial operational context that annotations don't 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 well-structured and appropriately sized for a complex tool with 7 parameters. It's front-loaded with core functionality, then addresses filtering, pagination, and jurisdiction caveats. While comprehensive, every sentence earns its place by providing necessary operational context. Minor deduction for some density, but overall efficient.

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 (7 parameters, jurisdiction variations, pagination differences) and lack of output schema, the description provides excellent completeness. It covers return format, filtering options, pagination mechanisms, jurisdiction limitations, error conditions, and relationships to sibling tools. The guidance to call list_jurisdictions for per-country details appropriately delegates complexity while maintaining completeness.

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 86% schema description coverage, the baseline would be 3, but the description adds significant value beyond the schema. It explains the relationship between category filtering and jurisdiction-specific codes, clarifies pagination behavior (cursor vs offset by jurisdiction), and provides context about company_id suffixes and jurisdiction support. The description compensates for the 14% schema coverage gap with practical usage 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 clearly states the tool's purpose: 'Return a company's filing history' with specific details about what each filing contains (filing_id, filing_date, category, description, document_id, jurisdiction_data) and that results are newest-first. It distinguishes from siblings like get_document_metadata and fetch_document by explaining the relationship, and from other list/search tools by focusing specifically on filings.

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 guidance on when to use this tool vs alternatives: it mentions using the optional 'category' parameter to filter, explains when to use get_document_metadata/fetch_document for document retrieval, and explicitly states that unsupported jurisdictions return 501 with the alternative to call list_jurisdictions for per-country caveats. It also distinguishes from sibling tools by explaining the document_id relationship.

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, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: the two distinct response shapes, the 400 error for no parameters, and the case-insensitive handling of jurisdiction codes. 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?

Extremely efficient and well-structured: first sentence establishes purpose, bullet points clearly explain the two modes, and final sentences cover error cases and sibling differentiation. Every sentence earns its place with zero 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?

Given the tool's complexity (two distinct modes with different return shapes), the description provides excellent context about what information is returned in each mode. However, without an output schema, the description doesn't fully document the return structure details. The annotations provide good safety coverage, making this mostly 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 description coverage is 100%, so the schema already fully documents both parameters. The description adds some semantic context about what each parameter triggers (full schema vs. cross-country matrix) and provides example values, but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides 'Per-country reference data dictionary' with two specific modes: full schema for one country or cross-country matrix for one tool. It distinguishes from sibling 'about' by specifying this tool is for jurisdiction-specific reference data while 'about' is for server-level info.

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 is provided: 'pass EXACTLY ONE of' the two parameters, with clear examples of each mode. It explicitly states when NOT to use this tool ('For server-level info... call `about` instead') and provides the consequence of incorrect usage ('Calling with no parameters returns a structured 400').

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 adds valuable behavioral context beyond annotations: it explains the API source ('Powered by ARES's POST /standardizovane-adresy/vyhledat'), discloses pricing ('free'), specifies jurisdiction limitations ('Other jurisdictions return 501'), and describes the response structure ('stav_standardizace' field with match statuses). While annotations cover safety (readOnly, non-destructive), the description provides operational details that help the agent understand the tool's 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?

The description is well-structured with clear sections (purpose, use cases, standardisation mode, requirements, pricing) and uses bullet points effectively. While slightly longer than minimal, every sentence adds value: the first sentence states the core purpose, followed by organized supplementary information. It could be slightly more concise but remains efficient and front-loaded.

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 (18 parameters, no output schema), the description provides excellent contextual completeness. It covers purpose, use cases, behavioral traits (pricing, jurisdiction limits), parameter requirements, and match types. With comprehensive annotations and schema coverage, the description fills remaining gaps effectively, making it complete enough for an agent to understand and use the tool appropriately.

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 100% schema description coverage, the schema already documents all 18 parameters thoroughly. The description adds minimal parameter semantics beyond the schema: it mentions that 'At least one of (text, nazev_obce, kod_obce, kod_adresniho_mista) should be supplied' and explains the two standardisation modes. This meets the baseline of 3 since the schema does the heavy lifting, but the description provides some additional guidance on parameter combinations.

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: 'Resolve a free-text or structured Czech address against the RÚIAN register' and 'Returns one or more normalised addresses with full geographic codes.' It specifies the exact resource (Czech RÚIAN addresses) and distinguishes itself from sibling tools by focusing on address standardization rather than company or document searches.

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 usage guidelines through dedicated sections: 'Use cases' lists three specific scenarios (normalization, canonical code resolution, validation), and 'Standardisation mode' explains when to use each match type. It also states jurisdictional limitations ('CZ only') and pricing ('free'), giving clear context for when 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 declare readOnlyHint=true, idempotentHint=true, etc., but the description adds crucial behavioral context: per-tier caps on country searches (anonymous=3, pro=10, etc.), confirmation dialogs for multi-jurisdiction mode, error handling for unsupported clients, cache bypass via 'fresh' parameter, and detailed output field explanations (unified fields vs. jurisdiction_data). It also notes that follow-up tools don't count against caps, enhancing operational understanding.

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 well-structured with clear sections (calling modes, caps, preferences, returns, caveats) and uses bullet-like formatting for readability. It's appropriately detailed for a complex tool but could be slightly more concise by reducing some repetitive explanations (e.g., the confirmation dialog is mentioned multiple times). Every sentence adds value, but minor trimming is possible.

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 high complexity (62 parameters, no output schema), the description provides comprehensive context: it explains the two main calling modes, tier-based caps, confirmation behavior, return fields, per-country caveats, and references to other tools for further details. It compensates for the lack of output schema by describing the return structure and status field semantics, making it complete for agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the two primary modes (jurisdiction vs. jurisdictions) and their semantics, which aren't fully captured in the schema's individual parameter descriptions. It also hints at parameter interactions (e.g., query may be empty for FR/IE with structured filters) and directs to list_jurisdictions for per-country details, though it doesn't detail all 62 parameters individually.

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 searches company registries by name or keyword, specifying two distinct calling modes (single vs. multi-jurisdiction). It distinguishes itself from siblings like search_companies_near_point by focusing on registry search rather than geographic proximity, and from get_company_profile by being a search rather than a direct lookup.

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 guidance on when to use each mode: use jurisdiction (singular) when the user names a specific country, and jurisdictions (plural) when uncertain. It warns to prefer the singular mode when in doubt and explicitly mentions follow-up tools (get_company_profile, list_filings, etc.) that don't count against caps, helping differentiate from alternatives.

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=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond annotations: pricing information ('Pricing: free'), jurisdiction limitation ('only FR exposes this endpoint'), and error behavior ('Other jurisdictions return 501'). It doesn't contradict 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 with zero waste: first defines purpose, second maps to endpoint and gives usage example, third provides pricing and jurisdiction constraints. Every sentence adds essential information, and the structure is front-loaded with core functionality.

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 moderate complexity (8 parameters), rich annotations, and no output schema, the description provides excellent completeness. It covers purpose, usage context, limitations, pricing, endpoint mapping, and return format reference. The combination with annotations makes this fully sufficient for agent understanding.

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 75%, providing good parameter documentation. The description adds some semantic context by mentioning 'radius (km)' and 'latitude/longitude point', but doesn't provide additional parameter details beyond what's in the schema. With high schema coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Search the French registry for companies'), target resource ('companies whose siège social lies within a given radius'), and scope ('only FR exposes this endpoint'). It distinguishes from siblings by specifying geographic search capability, unlike general search_companies.

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 ('Useful for companies within 2km of the Eiffel Tower style queries') and when not to use ('Other jurisdictions return 501 — only FR exposes this endpoint'). It also references the sibling tool search_companies for comparison of return format.

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. The description adds valuable behavioral context beyond annotations: it explains that snippets are 'NAVIGATION AIDS ONLY and may contain OCR errors,' specifies the default and maximum for max_hits, mentions total_hits counting raw matches, and describes the prerequisite of having a per-page text index. No contradiction with annotations exists.

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 well-structured and front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second explains usage context, the third details limits and total_hits, the fourth warns about snippet reliability and directs to next steps, and the fifth specifies prerequisites. 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?

Given the tool's complexity (search with navigation aids, OCR caveats, prerequisites) and lack of output schema, the description is complete. It covers purpose, usage guidelines, behavioral traits, parameter hints, and next steps. With annotations providing safety profile and the description filling in operational details, it adequately prepares an agent for correct use.

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 50% (only 'query' and 'jurisdiction' have descriptions). The description adds some parameter context: it explains that max_hits has a default of 20 and limits returns, and implies query is case-insensitive (though this is also in the schema). However, it doesn't fully compensate for the lack of schema descriptions for document_id and max_hits beyond basic constraints, keeping it at the 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 clearly states the tool's purpose: 'Locate pages containing a phrase' with 'Returns matching page numbers + short context snippets for navigation.' It specifically distinguishes itself from sibling tools like fetch_document_pages by explaining its role in navigation versus authoritative text retrieval, and contrasts with outline/landmark-based navigation methods.

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 guidance on when to use this tool: 'Useful when the outline/landmarks don't list your target' and gives a concrete example. It also specifies prerequisites: 'Requires get_document_navigation (or fetch_document on a PDF) to have run first' and directs to alternatives: 'call fetch_document_pages(pages=<n>) to read the authoritative text / bytes before citing anything.'

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 annotations already declare this as read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: it explains the investigative workflow (using officer_id with get_officer_appointments), describes partial name matching behavior, and clarifies what data is returned (officer_id, name, number of appointments where available). It doesn't mention rate limits or authentication needs, but adds meaningful operational context.

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 perfectly structured with three sentences that each earn their place: first states the core functionality, second explains the output and next-step workflow, third provides strategic context about investigation patterns. No wasted words, front-loaded with 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?

Given the tool's moderate complexity, rich annotations, and lack of output schema, the description provides excellent completeness. It covers purpose, usage patterns, behavioral context, and workflow integration. The annotations handle safety and idempotency, while the description adds investigative context and output interpretation guidance.

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 67% schema description coverage, the description adds meaningful context beyond the schema. While the schema documents the parameters technically, the description explains the investigative purpose of the 'query' parameter and the relationship between this search and subsequent lookups using officer_id. It doesn't provide additional syntax details for parameters, but adds strategic context about how parameters fit into workflows.

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 specific action ('Find people who hold or have held officer positions'), resource ('registry for company officers'), and scope ('by name'). It explicitly distinguishes this tool from its sibling 'get_officer_appointments' by explaining the relationship between them, making the purpose unambiguous.

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 guidance on when to use this tool ('entry point for "follow the human, not the company" investigations') and when to use an alternative ('Use the officer_id in get_officer_appointments to retrieve every company that person has been appointed to'). It also mentions jurisdictional constraints through the input schema, though not directly in the description text.

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, open-world, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: pricing (free), jurisdiction limitation (CZ only, others return 501), return format details, field variability per source, and reference to external API docs. No contradictions with annotations exist.

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 well-structured with clear sections (purpose, source codes, usage notes, return format, pricing). While comprehensive, some sentences could be more concise (e.g., the source code list is lengthy but necessary). Overall, it's front-loaded with key information and avoids 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 the tool's complexity (multiple parameters, source-specific behavior) and rich annotations, the description provides complete context. It covers purpose, usage, source options, limitations, return format, pricing, and external references. No output schema exists, but the description adequately explains the return structure.

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 100% schema description coverage, the schema fully documents all 6 parameters. The description adds minimal parameter semantics beyond the schema, mainly by listing source codes and noting that IČO filtering is optional but recommended. It doesn't provide additional syntax or format details for 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 the verb ('fetch'), resource ('raw records'), and scope ('from one specific ARES source register in a single call'), distinguishing it from sibling tools like get_specialised_record (single record) and search_companies (rich search). The title reinforces this with 'Bulk fetch records from a CZ ARES sub-register'.

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 is provided: use this for bulk fetching from specific registers with optional IČO filtering, while preferring search_companies for rich name/address/legal-form searches. The description also clarifies when not to use it (without IČO filter is 'rarely useful') and names the alternative tool (search_companies).

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