Velvoite — EU Financial Regulatory Compliance

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

Annotations declare readOnlyHint=true; description adds critical behavioral context including authentication requirements ('Requires admin API key') and detailed output semantics (explaining that 'model_only' indicates gaps while 'deployed_only' indicates data quality issues). Does not 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?

Efficiently structured with purpose front-loaded, followed by detailed return value documentation using bullet points for scanability, then usage context and requirements. Every sentence provides unique information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 0 parameters and an output schema exists, the description appropriately focuses on explaining the audit methodology, return value semantics, and access control rather than parameter mechanics. Covers all necessary context for a specialized QA 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?

Input schema has 0 parameters. Description explicitly confirms 'No parameters needed — returns full corpus audit,' which meets the baseline expectation for parameterless tools and prevents confusion about missing arguments.

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?

Opens with specific verb+resource: 'Audit the actor role taxonomy' and immediately clarifies the scope ('compare model-defined roles vs deployed roles'). Distinct from sibling 'get_actor_roles' by focusing on comparative QA analysis rather than simple retrieval.

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: 'Use this for QA validation of the actor role taxonomy.' Includes prerequisite restriction ('Requires admin API key') acting as an implicit exclusion. Lacks explicit naming of alternatives (e.g., 'use get_actor_roles for standard retrieval'), but the admin requirement and QA focus provide clear contextual boundaries.

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?

Adds valuable behavioral context beyond readOnlyHint annotation: specifies that returns are 'grouped by regulation, sorted by obligation count' and include 'human-readable label and description'. Minor gap regarding pagination or rate limiting prevents a 5.

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

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

Efficiently structured across four logical blocks: operation summary, domain concept explanation with examples, usage guidance, and parameter documentation. No redundant or wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description adequately covers the necessary context: domain terminology, return structure (grouping/sorting), and filtering semantics. Sufficient for correct agent invocation.

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

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

With 0% schema description coverage, the Args section fully compensates by explaining the regulation parameter filters to specific codes, providing concrete examples ('dora', 'ai_act'), and documenting the default behavior when omitted.

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?

Opens with specific verb-resource combination ('Get available actor roles per regulation') and includes scope detail ('with obligation counts'). Distinguishes from sibling get_obligations by defining actor roles conceptually and explaining their relationship to obligations.

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 prescribes workflow: 'Use this to discover which roles exist before filtering obligations with get_obligations(actor_role=...)'. Names the sibling tool directly and clarifies the sequencing of calls.

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; description adds valuable behavioral context about deduplication logic ('Returns one obligation per unique legal requirement per actor role') and output enrichment ('compliance difficulty, guidance, and enforcement metrics'). Does not disclose rate limits or auth requirements.

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?

Well-structured with purpose upfront, followed by behavioral details, explicit usage guidelines, and Args section. Every sentence serves a distinct function; no redundancy with schema titles.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, the description appropriately hints at return contents without over-explaining. Covers the critical deduplication logic distinguishing it from siblings. Could explicitly mention total count availability or pagination limits beyond parameter defaults.

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 has 0% description coverage (only titles), but the Args section fully compensates with detailed descriptions for all 8 parameters including format examples ('dora', 'mica', 'aml'), syntax notes ('Comma-separated'), and valid enum values for sort options.

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

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

The description opens with specific verb+resource ('Get deduplicated canonical obligations with enforcement intelligence') and immediately distinguishes from sibling get_obligations by emphasizing 'deduplicated' and 'enforcement intelligence' 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?

Explicitly states 'Use this instead of get_obligations when...' providing clear sibling differentiation and when-to-use context ('clean, deduplicated view' vs presumably raw obligations).

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?

While annotations declare readOnlyHint, the description adds critical behavioral context: the profile is determined by API key (not parameters), explains the onboarding state edge case, and defines profile_complete semantics. Could mention caching or error states for a 5.

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

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

Efficiently structured with purpose first, then usage patterns, edge case handling, and return value documentation. No redundant text; every sentence provides actionable guidance or structural clarity.

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?

Despite output schema existing, description provides comprehensive return value documentation with examples (e.g., {'dora': ['financial_entity']}) and semantic notes ('always includes eu'). Thoroughly covers the nested profile structure and completion status.

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?

Zero parameters present (baseline 4). Description adds value by explaining why no parameters are needed ('determined by the API key'), which clarifies scoping behavior beyond the empty 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?

Opens with specific verb 'Get' and clear resource 'calling company's regulatory posture'. Distinguishes from siblings by explicitly referencing get_obligations and get_actor_roles with specific usage patterns ('Use the actor_roles to filter...', 'extend beyond it using get_actor_roles()').

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

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

Provides explicit workflow guidance: use actor_roles to filter obligations, use get_actor_roles() to discover additional roles beyond the profile. Includes clear conditional logic for empty profiles (profile_complete=false) with specific remediation action (guide to app.velvoite.eu/account).

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 indicate readOnlyHint=true, and the description adds valuable behavioral details beyond this: it specifies that results are returned in 'chronological order' and annotated with 'days remaining or days overdue.' This reveals sorting behavior and computed fields not evident in the schema or annotations. It does not contradict annotations, though it omits pagination or rate limit 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 efficiently structured with no wasted words: a one-sentence purpose, a one-sentence return value description, a brief value statement ('Essential for compliance planning'), and a structured Args block. Information is front-loaded with the core action before 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 has an output schema (not shown but indicated), the description appropriately focuses on the purpose, filtering capabilities, and behavioral traits (chronological ordering) without needing to exhaustively document return fields. With four optional parameters fully documented and the read-only nature established, the description provides complete context for agent invocation.

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

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

With 0% schema description coverage (only titles like 'Days Ahead'), the description fully compensates by documenting all four parameters in the Args section. It provides clarifying examples ('credit_institution', 'dora') and critical constraints ('max 730') that are absent from the JSON schema, effectively serving as the primary source of parameter semantics.

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

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

The description opens with a specific verb ('Get') and resource ('upcoming regulatory deadlines'), and immediately contextualizes it for 'compliance calendar tracking.' This distinguishes it clearly from sibling tools like get_obligations or get_canonical_obligations by emphasizing the deadline/calendar aspect rather than general obligation retrieval.

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 implied usage context through phrases like 'Essential for compliance planning' and 'compliance calendar tracking,' indicating when the tool is valuable. However, it lacks explicit guidance on when to use this versus siblings like get_obligations or get_obligation_summary, and does not state any prerequisites or exclusions.

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

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

Annotations cover read-only safety (readOnlyHint: true). Description adds valuable behavioral context beyond annotations: specific return structure (metadata, AI summary, tags, obligations), pagination limits ('up to 50 with total count'), and external source domains (EUR-Lex, EBA, ESMA, FIN-FSA). Does not mention error cases or rate limits, preventing a 5.

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

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

Well-structured with clear information hierarchy: purpose → return value details → usage guidance → parameter definition. The enumerated return fields (metadata, AI summary, etc.) justify the length. Minor deduction for slight verbosity in listing external sources, but 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?

Despite having an output schema (which reduces descriptive burden), the description comprehensively details what the tool returns, including behavioral limits (50 obligations) and external references. For a single-parameter retrieval tool with rich output, this is complete.

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

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

With 0% schema description coverage, the description fully compensates by documenting the parameter in the Args section: specifies it is a 'Velvoite document ID', an integer, and crucially explains provenance ('from search/list results'). This semantic context (where to get the ID) is essential for correct invocation.

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

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

Description opens with specific verb ('Get') + resource ('regulatory document') + scope ('full details by ID'). It clearly distinguishes from siblings like search_regulations and list_documents by emphasizing ID-based retrieval and explicitly naming those tools as sources for the document_id.

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

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

Provides explicit prerequisite guidance: 'Get the document_id from search_regulations or list_documents results.' Also guides usage of results ('Use the URL to access the full text'). Could be improved by explicitly stating when NOT to use (e.g., 'do not use for searching'), but the prerequisite instruction effectively implies the workflow.

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, confirming safe read operations. The description adds valuable behavioral context about return content (penalty amount, sanctioned entity, violation categories, appeal status) that annotations don't cover. Does not 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?

Well-structured with logical flow: purpose → return data → usage examples → cross-tool reference → parameters. Front-loaded with clear action statement. Minor verbosity in four example questions, but they serve legitimate guideline purposes.

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 output schema exists (not shown but indicated in context), the description appropriately focuses on query capabilities and data highlights rather than return structure. Coverage is complete for a 7-parameter filtering tool with optional cross-tool integration.

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 0% schema description coverage (only titles present), the Args section comprehensively compensates by documenting all 7 parameters with rich examples (e.g., regulation codes like 'aml', 'dora', 'mifid2'; entity types like 'credit_institution'). Essential semantics for filtering are fully provided.

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

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

The description opens with 'Get enforcement decisions with structured penalty data' and specifies the exact resource (enforcement actions including fines, warnings, license withdrawals). It distinguishes from sibling get_enforcement_intelligence by focusing on structured penalty data and specific decision attributes.

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

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

Provides explicit usage patterns through four concrete example questions (e.g., 'What fines has FIN-FSA given to credit institutions?'). Explicitly names cross-tool workflow: 'Combine with get_company_profile to find enforcement actions relevant to the caller's entity type and regulations.'

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 read-only safety, allowing the description to focus on domain logic. Adds valuable context about ranking methodology ('ranked by enforcement activity'), default filtering behavior ('only enforced obligations'), and pagination constraints ('max 100').

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?

Efficiently structured with purpose statement first, differentiation second, use case third, followed by comprehensive Args documentation. No redundant text; every sentence provides actionable 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 presence of an output schema, the description appropriately focuses on input parameters and filtering logic. Covers all 8 optional parameters with business context (e.g., explaining that min_enforcement_count defaults to 1 to enforce the 'enforced only' constraint).

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 0% schema description coverage, the description fully compensates by documenting all 8 parameters with examples (e.g., 'dora', 'mica', 'aml' for regulation) and valid value ranges ('low', 'medium', 'high', 'critical' for compliance_difficulty). Essential for agent to construct valid calls.

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

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

States specific action ('Get top enforced canonical obligations'), resource type, and business purpose ('risk prioritization'). Clearly distinguishes from sibling 'get_canonical_obligations' by noting this is a 'focused view' filtered to obligations 'with at least one enforcement action.'

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

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

Provides clear context for when to use ('identify which obligations regulators are actively enforcing') and implicitly distinguishes from the broader 'get_canonical_obligations' by emphasizing the enforcement filter. Lacks explicit 'when not to use' or named alternative tools.

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, which is consistent. The description adds important behavioral context: requires Velvoite Premium API key, no web fetching, and that the corpus has authoritative text. This goes beyond the sparse 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 purpose first, followed by usage context, requirements, supported codes, and parameter details. It is slightly verbose but 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 simple tool with 2 parameters, existing annotations, and an output schema, the description is complete: it covers purpose, prerequisites, parameter semantics, and usage 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?

Schema has 0% parameter descriptions, but the description fully explains both parameters: regulation (case-insensitive code with examples) and article (optional number, browse behavior). It also lists supported regulation codes.

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 verbatim obligation text from the Velvoite corpus for an EU regulation article plus a EUR-Lex URL. It distinguishes from siblings like search_eu_regulation_text (search vs. direct retrieval) and get_eurlex_document (raw document vs. obligation text).

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 explains when to use this tool (e.g., no web fetching needed, authoritative corpus) and lists supported regulation codes. However, it does not explicitly contrast with sibling tools or state when not to use it.

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 readOnlyHint=true and openWorldHint=true. The description adds significant behavioral context: it queries CELLAR SPARQL live, explains that legislative acts are handled differently because 'CELLAR does not reliably index final legislative acts via SPARQL,' and specifies the output (title, date, URLs). This goes beyond annotations without contradiction.

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

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

The description is well-structured: a concise opening sentence followed by elaboration on behavior, alternative, requirements, and examples. It is front-loaded with the core purpose. While slightly lengthy, each sentence adds necessary value, and the structure aids readability.

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 (different behavior for CJEU vs legislative acts) and the presence of an output schema, the description fully covers usage context: it explains the live query nature, the alternative tool, the required API key, and provides multiple CELEX examples. No gaps remain for an agent to invoke the tool correctly.

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

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

The input schema has no description for the celex parameter (0% coverage). The description compensates comprehensively with a detailed 'CELEX format' section and examples for regulations, directives, and CJEU cases. It also notes case-insensitivity. This fully explains the parameter's meaning and format.

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 'Look up any EUR-Lex document by CELEX number via CELLAR SPARQL (live).' It specifies the verb (look up), resource (EUR-Lex document), and method (CELEX number). It distinguishes between CJEU case law and legislative acts, and the sibling tool get_eu_regulation_article is mentioned for known regulation codes, differentiating the purpose.

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

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

The description provides explicit guidance: 'Use get_eu_regulation_article for known regulation codes (gdpr, dora, mica…).' It also states the requirement for a 'Velvoite Premium API key,' and includes CELEX examples to clarify usage. This clearly tells the agent when to use this tool versus 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?

Adds critical auth requirement not in annotations. Enumerates valid filter values (new/reviewed/resolved/dismissed, etc.) that constrain input behavior, supplementing the annotations (readOnlyHint/openWorldHint) with domain-specific 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?

Extremely efficient two-line structure: first line establishes purpose and auth, second line lists filters with values. No redundant text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and safety annotations, the description adequately covers the essentials: purpose, authentication, and filter semantics. Only minor gap is omission of 'limit' parameter description.

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 0% schema description coverage, the description compensates well by documenting three of four parameters (status, feedback_type, context_type) including their valid enum values. Only omits the 'limit' parameter.

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

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

States specific action ('Get') and resource ('user feedback') with context ('for QA review'). Clearly distinct from sibling retrieval tools like get_document or get_obligations, though it could explicitly contrast with them.

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

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

Provides authentication prerequisite ('Requires admin API key'), but lacks explicit guidance on when to use this versus other retrieval tools or what triggers a need for QA review.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by specifying the return fields and input format. However, it does not disclose potential errors or rate limits, which would be useful.

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

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

The description is concise, with the main purpose in the first sentence followed by a brief list of return fields. The Args section is well-structured. No superfluous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's function, input format, and output fields adequately for a simple lookup tool. However, it omits details about error handling (e.g., invalid Y-tunnus) and does not mention the output schema, though it exists.

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

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

The only parameter 'business_id' is described with a clear format example ('1234567-8') and context (Finnish business ID / Y-tunnus). This adds significant meaning beyond the schema's bare type definition, especially given 0% schema description 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 'looks up a Finnish company in the PRH Trade Register by business ID (Y-tunnus)' and lists the specific return fields. This distinguishes it from siblings like 'search_finnish_companies' and 'get_company_profile'.

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

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

The description implies usage when a Y-tunnus is known but does not explicitly state when not to use it or provide alternative tools. For example, it does not mention that 'search_finnish_companies' should be used when the business ID is unknown.

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 and openWorldHint. Description adds context about no public JSON API and that the URL can be fetched with WebFetch. It does not contradict annotations. Could mention error handling but overall good.

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

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

Description is well-structured with clear sections and concise sentences. No extraneous information; 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 presence of output schema and sibling tools, the description is complete. It explains purpose, inputs, and relationship to search_finnish_statutes without needing to describe 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?

Despite 0% schema coverage, the description thoroughly explains both parameters: law_code (short code or year/number) and section (optional chapter:paragraph format). This compensates well for the lack of 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?

Description clearly states the tool returns a canonical Finlex URL for a Finnish statute, specifying input types (short code or year/number). It distinguishes from sibling tools like search_finnish_statutes.

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 this tool (known statute) and when to use search_finnish_statutes (unknown statute). Provides list of known codes and acceptable reference formats.

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

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

Discloses requirement for Velvoite Premium API key, citation format KHO:YYYY:N, and the three-step access pattern. Annotations already mark readOnly and openWorld, and description adds crucial behavioral context without contradiction.

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

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

Description is moderately lengthy but well-structured with clear sections. Each sentence adds value, though some redundancy could be trimmed.

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 output schema exists and parameters are simple, the description covers purpose, prerequisites, usage pattern, and parameter meaning comprehensively. No gaps.

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

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

Schema coverage is 0%, but description explains both parameters (year and number) with examples ('2024', '52'), adding meaning beyond the schema. Compensates well for the gap.

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

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

Description clearly states 'Return access details for a Finnish Supreme Administrative Court (KHO) precedent decision,' specifying the resource and action. It distinguishes from sibling tool search_kho_decisions by noting it is for browsing.

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

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

Explicitly tells when to use search_kho_decisions instead and provides a detailed access pattern (use search_query, fetch kho.fi URL, avoid Finlex). This guides the agent on correct usage.

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; description adds pagination limits (max 50), search algorithm details (trigram + ILIKE), and distinct behavioral modes (canonical vs raw obligations). Adds context about enforcement intelligence and compliance difficulty in results without contradicting safety 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?

Well-structured with clear progression: purpose → result contents → search/pagination → canonical mode → prerequisites → parameter reference. Every sentence provides unique information; no repetition of schema or annotation data.

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 8 parameters, complex filtering logic, and existence of output schema, description appropriately covers all operational modes (canonical vs raw), prerequisite workflows, and result characteristics without redundant return value documentation.

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 0% schema description coverage, the Args section comprehensively compensates by documenting all 8 parameters with data types, examples (e.g., 'credit_institution', 'dora'), and format constraints (comma-separated, max 50). No ambiguity remains.

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?

Opens with specific verb+resource ('Get regulatory obligations') and clarifies scope ('specific requirements extracted from regulations'). Effectively distinguishes from sibling get_canonical_obligations by explaining the canonical parameter as an alternative mode.

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

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

Provides explicit prerequisite ('Use get_actor_roles first'), explains when to use canonical=True versus default mode, and advises combining filters for precise results. Lacks explicit 'when not to use' guidance comparing to siblings like search_regulations or get_canonical_obligations.

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 (safe read), so the description adds valuable behavioral context by detailing the return payload structure (per-regulation breakdown with specific status counts) and explicitly noting exclusions (no full obligation text). No contradictions 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 purpose first, return value specification second, scope limitations third, and parameter details last. Every sentence provides distinct value—no repetition of the tool name or tautology. The Args section is appropriately detailed without verbosity.

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 existence of an output schema (not shown but indicated), the description appropriately summarizes rather than fully specifies return values. Both parameters are thoroughly documented despite zero schema coverage, and prerequisite workflows (discovering actor roles) are addressed via sibling tool references.

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 0% schema description coverage, the description carries the full documentation burden and excels: it explains entity_type filtering with concrete examples ('credit_institution'), clarifies actor_role formatting ('Comma-separated'), and provides discovery mechanisms via cross-references to get_company_profile and get_actor_roles.

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

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

The description opens with a specific verb ('Get') and clearly identifies the resource (obligation counts) plus the grouping key (regulation_code). It distinguishes itself from sibling 'get_obligations' by explicitly stating 'No full obligation text — just counts,' clarifying this returns aggregations rather than complete records.

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

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

The description implies when to use this tool ('quick overview' vs full details) and provides explicit prerequisites by naming specific sibling tools ('Use get_company_profile... or get_actor_roles') for discovering valid parameter values. It lacks an explicit 'when not to use' contrast with get_obligations, though the limitation is implied.

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

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

Annotations establish readOnlyHint=true (safe read). The description adds valuable behavioral details beyond annotations: sorting behavior ('sorted by publication date, newest first') and the urgency scale semantics ('1=critical, 2=high, etc.'). Does not mention pagination or caching, but provides more behavioral context than typical.

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?

Well-structured with front-loaded purpose statement followed by use case explanation and structured Args section. No redundant text; every sentence serves to clarify tool selection or parameter usage.

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 output schema exists (per context signals), the description appropriately omits return value details. With 4 parameters fully documented in the Args section and clear behavioral scope, the description is complete for this tool's complexity level.

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 0% schema description coverage, the description fully compensates via the Args section. It documents all 4 parameters (days, entity_type, regulation, urgency_max) with clear semantics, including the default for days (7) and the urgency scale mapping (1=critical), which is critical for correct invocation.

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 'Get recently published or updated regulatory documents' with specific verb and resource. It further distinguishes itself from siblings like search_regulations or list_documents by emphasizing the temporal focus ('recently', 'last N days', 'what is new this week').

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

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

Provides clear usage context ('Useful for weekly regulatory briefings', 'Shortcut for what is new this week') implying when to select this tool. However, it lacks explicit 'when not to use' guidance or named sibling alternatives despite the 'Shortcut' phrasing implying their existence.

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?

While annotations declare readOnlyHint=true, the description adds valuable behavioral context by detailing exactly what the overview contains: document counts by source, regulation family, entity type, urgency distribution, obligation summary, and date range. This specifics what would otherwise be an opaque 'overview' return value.

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

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

Four sentences efficiently cover purpose, return value structure, usage guidelines, and parameter status. Each sentence provides distinct information without redundancy, creating a well-structured, front-loaded description that agents can scan quickly.

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 low complexity (zero parameters, read-only), the presence of an output schema, and the description's enumeration of return fields (counts, distributions, summaries), the definition is complete. The guidance to 'Call this FIRST' appropriately contextualizes it within the broader tool suite.

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 zero parameters and 100% schema coverage of the empty object, the description appropriately confirms 'No parameters needed,' aligning with the schema. This meets the baseline expectation for parameter-less tools by explicitly acknowledging the lack of inputs rather than leaving ambiguity.

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

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

The description opens with the specific action 'Get' and resource 'overview of the Velvoite regulatory corpus.' It distinguishes itself from sibling query tools (like search_regulations or get_document) by positioning itself as a high-level aggregation tool that returns counts and distributions rather than specific records.

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 'Call this FIRST to orient yourself before running queries,' providing clear temporal guidance on when to use the tool. This implicitly defines the alternative workflow (direct querying) and establishes this as a prerequisite discovery step for unfamiliar users.

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. Description adds valuable behavioral context by detailing return structure (total/verified/unverified counts, percentages) and clarifying the domain purpose (tracking human review). No contradictions 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?

Four sentences efficiently structured: purpose, return values, usage context, and parameter note. No redundancy or filler. Information is front-loaded with the specific action in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 0 parameters, readOnly annotations, and an output schema exists, the description provides sufficient completeness. It summarizes return values appropriately without needing to fully document the output schema 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?

Tool has zero parameters. Description explicitly states 'No parameters needed,' which confirms the schema structure. With 100% schema coverage of an empty parameter set, this meets the baseline for zero-parameter tools.

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

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

Description uses specific verb 'Get' with clear resource 'verification progress' and scope 'obligations across all regulations'. It distinguishes itself from sibling 'get_stats' by specifying 'verification' and 'human review progress' rather than general statistics.

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

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

Provides explicit usage context 'Use this to track human review progress' which clarifies the tool's purpose. However, it lacks explicit when-not-to-use guidance or direct comparison to sibling 'get_stats' for alternative statistical needs.

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

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

While annotations confirm the read-only nature, the description adds valuable behavioral context by detailing the return structure (paginated list with summaries, tags, doc_purpose types, and jurisdiction formats) and explaining the urgency_max scale (1=critical through 5=informational). This helps the agent understand what data structure to expect and how to interpret the results.

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 the core purpose upfront, followed by return value details, usage guidelines, and parameter documentation. While the Args section is lengthy due to listing enum values, this is necessary given the schema lacks descriptions and enums, making the overall size appropriate for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description appropriately summarizes the return format without redundancy, while thoroughly covering parameter semantics and sibling differentiation. The documentation adequately supports the 7-parameter filtering interface despite the schema's lack of descriptions.

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 0% schema description coverage, the description compensates comprehensively by documenting all seven parameters in the Args section, including valid values for source codes (eur_lex, eba), regulation families (dora, mica), entity types, and constraints like days (1-365) and per_page (max 100).

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

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

The description opens with the specific action 'Browse regulatory documents' and clearly identifies the tool's scope as filtered browsing with pagination. It effectively distinguishes itself from the sibling tool by explicitly stating 'Use search_regulations instead when you have specific keywords to search for.'

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 guidance by contrasting it with the alternative tool, stating when to use 'filtered browsing' versus keyword search. It includes a concrete example ('all DORA documents from the last 30 days') that clarifies the intended use case for filtering over searching.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by stating 'live — not limited to Velvoite corpus' and 'Requires Velvoite Premium API key,' providing behavioral context beyond annotations.

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

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

Description is appropriately sized, front-loaded with purpose, and every sentence earns its place. Examples and requirements are included without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (not shown but indicated), the description covers purpose, usage, parameter semantics, and requirements completely. No missing aspects for an AI agent to correctly select and invoke the tool.

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

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

Schema coverage is 0%, but the description thoroughly explains both parameters: 'query' with examples and guidance for phrase search, and 'article_ref' with usage tips including the caveat about CJEU titles. This adds significant meaning beyond the minimal 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 searches CJEU case law via EUR-Lex, returns cases matching keywords in case title, and distinguishes itself from sibling tools by specifying 'live — not limited to Velvoite corpus' and focusing on court decisions.

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

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

Explicitly says 'Use to find court decisions on a specific regulation, topic, or legal concept' and provides examples. Mentions required API key. However, it does not explicitly mention when not to use or provide alternatives like 'get_eurlex_document' for fetching documents.

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 and openWorldHint=true, indicating a safe read operation with external variability. The description adds that the tool returns a URL and requires an API key, which is useful context beyond annotations.

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

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

The description is two short paragraphs with a bullet list of parameters. It is concise, front-loaded with the purpose, and every sentence adds value. 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 has 2 simple parameters, an output schema (so return details are covered), and annotations, the description covers purpose, usage guidance, parameters with examples, and auth requirement. It is complete for the tool's complexity.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining each parameter: query is 'Search terms' with an example, and regulation is 'Optional regulation code to scope the search' with an example. This adds significant meaning.

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 'Return EUR-Lex search URL for finding regulation provisions by keyword,' using a specific verb and resource. It distinguishes from sibling tools like 'get_eu_regulation_article' which gets a specific article, and 'search_regulations' which may be broader.

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 says 'Use when you don't know the exact article number but need to find relevant provisions,' providing clear when-to-use context. It also mentions the API key requirement. However, it does not explicitly state when not to use or name 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 and openWorldHint. The description adds context about the data source (PRH Trade Register) but does not disclose additional behavioral traits. No contradictions.

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

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

The description is concise, front-loaded with purpose, and every sentence adds value. No 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?

For a simple search tool with 2 parameters and an output schema present, the description covers purpose, usage, and parameter semantics adequately. No missing critical 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 0% schema description coverage, the description compensates fully: explains 'name' as company name or partial, and 'city' as optional municipality to narrow results. This adds significant meaning 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 searches Finnish companies by name in the PRH Trade Register, with specific use cases like finding a business ID or checking name availability. This distinguishes it from siblings like get_finnish_company (retrieval by ID) and search_finnish_statutes.

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 the tool: to find a business ID from a name or check if a name is taken. Implicitly contrasts with retrieval tools, but lacks explicit 'do not use for' guidance.

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

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

Annotations declare readOnlyHint and openWorldHint; description adds context about Finlex lacking a JSON API, justifying the URL return pattern. No contradiction.

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

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

Two concise sentences plus args block, efficient and front-loaded. Could be slightly more structured, but 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?

Simple tool with one param and URL output; description explains why URL is returned. For the complexity level, it is adequately 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 has 0% description coverage; description adds examples and language guidance ('in Finnish or English'), significantly enhancing parameter understanding.

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

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

Clearly states 'Return Finlex search URL for Finnish statute keyword search' with specific verb (return) and resource (search URL), distinguishing from sibling tools like get_finnish_statute.

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

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

Explains why a URL is returned due to lack of public API, implying the agent should fetch it. Missing explicit when-not or alternative mentions, but context is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that tool returns a search query (not actual data), requires API key, and the result is an indexed list to be fetched individually. Enhances behavioral understanding without contradiction.

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

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

Description is multi-paragraph but each paragraph serves a purpose: purpose+requirement, workflow+limitation, parameter. Could be slightly more concise, but well-structured with front-loaded key info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, workflow, prerequisite, and output nature. Output schema exists, so return value details not needed. Complete for a tool that generates a search query.

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?

Only parameter 'year' has description 'Year to browse (e.g. '2024', '2023')'. Schema coverage is 0%, so description compensates minimally with format examples. Does not specify constraints like range or format beyond example.

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

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

Description clearly states it returns a search query to discover KHO precedent decisions for a given year. Verb 'return' and resource 'search query for KHO decisions' are specific. Distinguishes from sibling 'get_kho_decision' which retrieves a specific decision.

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

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

Explicitly says when to use: to get an indexed list from kho.fi, then use get_kho_decision. Notes that Finlex cannot be fetched directly, provides workflow: use returned search_query with web_search. Also mentions API key requirement.

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 (safe read). Description adds valuable behavioral context: 'PostgreSQL trigram similarity' explains the fuzzy matching algorithm, and 'Returns documents ranked by relevance with summaries and classification tags' previews the output structure. Does not mention rate limits or false positive characteristics of trigram matching, preventing a 5.

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

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

Four tightly structured sentences followed by Args block. Every sentence earns its place: purpose statement, technical implementation, return format, and usage guidelines. No redundant or filler text.

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?

Tool has output schema (context signals confirm), so detailed return value documentation isn't required. Description provides sufficient overview of returns ('ranked by relevance with summaries and classification tags'). Covers algorithm, parameters, usage boundaries, and safety (via annotations) completely.

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

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

Schema description coverage is 0% (parameters have titles but no descriptions). Description fully compensates by documenting both parameters under 'Args:' with clear semantics and constraints: query includes concrete examples ('strong customer authentication', 'ICT risk'), per_page specifies default (20) and max (100).

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

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

Description opens with specific verb ('Search') + resource ('regulatory corpus') + method ('keyword / trigram matching'). Explicitly distinguishes from sibling 'list_documents' by stating preference for structured filters first, clarifying this tool's specific niche.

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

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

Provides explicit when-to-use guidance: 'Prefer list_documents with filters... first' and 'Only use this for free-text keyword search when structured filters aren't sufficient.' Names the specific alternative tool and defines the boundary condition clearly.

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