Velvoite — EU Financial Regulatory Compliance

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

Annotations already declare readOnlyHint=true, and the description adds valuable context: it requires an admin API key, returns specific per-regulation analysis fields, and has no parameters. This goes beyond the annotations and describes the tool's behavior and output structure.

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 a clear opening sentence, a useful bulleted list of return fields, and a concise usage note. Every sentence contributes meaning, and the front-loaded purpose makes it 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?

For a parameterless read-only audit tool with no output schema shown, the description covers all necessary context: what it does, what it returns, why to use it, and the auth requirement. It is complete for an agent to decide when and how to invoke it.

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, the baseline is 4. The description explicitly states 'No parameters needed — returns full corpus audit,' which clarifies the parameterless nature and the scope of the operation.

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 starts with a specific verb 'Audit' and identifies the resource 'actor role taxonomy', clearly contrasting with sibling get_* tools. It explicitly states the comparison between model-defined and deployed roles, making its unique function unmistakable.

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

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

The description states 'Use this for QA validation of the actor role taxonomy,' providing a clear context for when to use it. However, it does not explicitly name alternatives or exclusion criteria, so it falls short of a 5.

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

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

Beyond the read-only annotation, the description discloses that results are 'grouped by regulation, sorted by obligation count' and each role includes 'a human-readable label and description.' It also specifies the behavior of an omitted regulation parameter. 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 concise and well-structured: a one-sentence summary, a brief conceptual explanation, usage guidance, return behavior, and an Args section. Every sentence adds value, with examples aiding 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?

For a single-parameter, read-only discovery tool with an output schema present, the description covers purpose, usage, parameter semantics, and return structure. No critical gaps exist.

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

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

The schema provides minimal information (anyOf string/null), but the description's Args section fully explains the 'regulation' parameter with examples and default behavior, compensating for the 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 opens with a specific verb-resource combo: 'Get available actor roles per regulation with obligation counts.' It further clarifies the concept with concrete examples (e.g., 'credit_institution' for CRD/CRR) and distinguishes its role as a discovery step before using get_obligations, the key sibling tool.

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

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

Explicitly instructs to 'Use this to discover which roles exist before filtering obligations with get_obligations(actor_role=...)', naming the alternative and giving a clear usage scenario. This provides both a positive use case and an implicit exclusion (not for filtering itself).

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 the description builds on that by disclosing deduplication behavior, per-actor-role structure, and the inclusion of compliance difficulty, guidance, and enforcement metrics. This adds meaningful context beyond the annotation alone.

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 a one-sentence purpose, followed by a crisp usage note and a well-organized Args block. There is no redundant text; every line contributes necessary decision-making or invocation 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 output schema exists, the readOnly annotation, and the detailed parameter documentation, the description fully equips an agent to select and call this tool. It covers purpose, differentiation from siblings, all filters, sorting options, and pagination 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?

The schema has 0% descriptive coverage, but the Args list comprehensively documents all 8 parameters with exact value examples, accepted strings, defaults, and constraints like per_page max 100. This fully compensates for the schema's lack of 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 opens with a specific verb and resource: 'Get deduplicated canonical obligations with enforcement intelligence.' It clearly distinguishes itself from get_obligations by emphasizing deduplication and enforcement risk enrichment.

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

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

It explicitly tells the agent to 'Use this instead of get_obligations when you want a clean, deduplicated view' and names the alternative. However, it doesn't specify when get_obligations would be a better choice, so it lacks a full when-not exclusion.

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, and the description adds meaningful context: the profile is determined by the API key, profile_complete=false indicates incomplete onboarding, and the profile serves as a baseline. It also details the returned structure. No contradiction with annotations.

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

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

The description is front-loaded with a clear purpose, then provides structured usage guidance, edge-case handling, and a detailed return section. Every sentence adds value, and the length is justified by the complexity of the return object.

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 comprehensively covers the tool's role within a workflow, its output structure with examples, the meaning of profile_complete, and what to do in the incomplete case. It pairs well with the existing output schema (or provides sufficient detail if none 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?

There are zero parameters, and the description explicitly states this and explains why ('No parameters needed — the profile is determined by the API key.'). This exceeds the baseline for 0-param tools by adding clarity about authentication context.

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: retrieving the calling company's regulatory posture (entity types, actor roles, conditions). It also distinguishes itself from siblings like get_obligations and get_actor_roles by explaining how the profile relates to 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?

The description explicitly explains when to use this tool ('The profile defines WHICH regulations and roles apply'), how to use it for filtering obligations, and when to consider get_actor_roles for extension. It also provides guidance for the incomplete profile case, directing the agent to help the user complete onboarding.

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, so the description adds value by disclosing chronological ordering, days remaining/overdue annotations, the default for include_overdue, and the max for days_ahead. This is useful behavioral context beyond the annotation.

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 well-structured: opening purpose, return behavior, then parameter list. Every sentence contributes value with no redundancy or 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 presence of an output schema and annotations, the description covers the tool's purpose, return characteristics, and all parameters. It is complete for a read-only query tool, with no missing critical information.

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%, but the description's Args section fully explains every parameter with examples, defaults, and constraints (e.g., days_ahead max 730). This adds significant meaning beyond the schema's bare titles.

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 function: 'Get upcoming regulatory deadlines for compliance calendar tracking.' It specifies a distinct resource (deadlines) and includes unique behavior (chronological order, days remaining/overdue annotations) that differentiates it from sibling tools like get_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?

It provides a clear use case ('Essential for compliance planning') and the filter parameters imply when it should be used. However, it does not explicitly mention alternatives or when NOT to use it, so it falls short of a full 5.

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

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

Beyond the readOnlyHint=true annotation, the description discloses specific return content: metadata, AI summary, classification tags, inline obligations (up to 50 with total count), and a link to the original source. It also explains that the URL provides access to the full text on official websites, adding practical behavioral 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 concise and well-structured: a clear purpose statement, a list of return contents, a hint about using the URL, and an args section for the parameter. Every sentence serves a distinct purpose with no 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?

The tool is simple with one parameter and no nested objects, and an output schema exists. The description covers how to obtain the parameter, what the response includes, and how to access the full text. This is fully sufficient for an agent to select and invoke the tool correctly.

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

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

The schema has 0% description coverage, so the description compensates by explaining that document_id is 'The Velvoite document ID (integer from search/list results)'. This adds context about the type and source of the ID, which is valuable beyond the schema's bare integer type declaration.

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 'Get' and the resource 'full details of a specific regulatory document by its ID'. It distinguishes from sibling tools like search_regulations and list_documents by indicating this is a retrieval tool for a single known document, not a search or list operation.

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 tells the agent to obtain the document_id from search_regulations or list_documents results, providing clear context on when to use this tool. It also mentions using the URL for full text access, but does not explicitly state when not to use it or mention alternatives for other use cases.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds context about the content (penalty amount, sanctioned entity, violation categories, appeal status) and filterable dimensions, which goes beyond the schema. It does not disclose pagination behavior or sorting, but the output schema likely covers return 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 structured with a clear opening, return details, usage examples, and a well-formatted argument list. Each sentence earns its place and there is no redundant fluff. The front-loaded purpose statement makes it immediately clear what the tool does.

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 7 parameters, an output schema, and annotations, the description is exceptionally complete. It covers purpose, return fields, usage scenarios, related tool, and all parameter semantics. No critical gaps remain for an agent to select and invoke the tool correctly.

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

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

Every parameter is described with meaning and examples: regulation codes like 'aml', entity types, authority, penalty_min with EUR example, violation_category examples, and page/per_page defaults. Since the schema has no parameter descriptions (0% coverage), the description fully compensates by explaining each parameter's purpose and allowable values.

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 starts with 'Get enforcement decisions with structured penalty data' and specifies what is returned: fines, warnings, license withdrawals with penalty amount, entity, violation categories, and appeal status. This clearly identifies the tool's purpose and differentiates it from siblings like get_enforcement_intelligence or 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?

Provides explicit example questions and states 'Combine with get_company_profile to find enforcement actions relevant to the caller's entity type and regulations.' This gives clear context for when to use the tool, though it does not explicitly mention exclusions or alternative tools in the sibling set for cases where enforcement intelligence is more 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?

With readOnlyHint=true annotation, the safety profile is known. The description adds behavioral context by explaining the filtering behavior (only obligations with at least one enforcement action via min_enforcement_count default of 1) and ranking by enforcement activity. It does not describe return format or performance, but the output schema covers return values.

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 a summary, an explanatory paragraph, and an args list. However, there is slight redundancy: 'Get top enforced canonical obligations' and 'This is a focused view of canonical obligations filtered to only those with at least one enforcement action' convey similar information. Overall, it is 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 8-parameter complexity, the presence of an output schema, and read-only annotations, the description is complete. It documents all parameters with examples, notes the default filtering behavior, and explains the tool's purpose, leaving no critical gaps for the agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must fully document parameters. It does so comprehensively, listing all 8 parameters with types, examples, and defaults (e.g., 'regulation: Filter by regulation code (e.g. 'dora', 'mica', 'aml')'). This adds significant meaning beyond the bare 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 function: 'Get top enforced canonical obligations' with a specific verb and resource. It further distinguishes itself from siblings by noting it is 'a focused view of canonical obligations filtered to only those with at least one enforcement action,' which separates it from broader obligation-listing tools like get_canonical_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?

The description provides clear usage context: 'Use this to identify which obligations regulators are actively enforcing.' It implies differentiation from broader obligation views but does not explicitly name alternative tools or state when not to use it. This is clear context without explicit exclusions.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds valuable behavior: it confirms the tool queries the corpus directly, avoids web fetching due to EUR-Lex blocking, and requires a Premium API key. It also clarifies that the corpus is authoritative. This goes beyond the annotations by explaining the data source and access prerequisites. However, it does not disclose potential error conditions or response format, though an output schema exists, so it never falls below a 4.

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 purpose sentence, rationale, key requirement, supported codes, and an Args section. It front-loads the primary action. The list of 20 supported codes is somewhat long but necessary for correct invocation; it could arguably be moved to an external reference, but keeping it in the description prevents errors. No redundant words, and each sentence adds value. Slightly verbose due to the code list, but appropriately so.

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 parameters, one optional; read-only; output schema present), the description covers all necessary ground: what it returns, data source, why not to use web fetch, API key requirement, supported inputs, and the behavior of omitting article. The output schema handles return structure, so no additional format explanation is needed. It is complete for an agent to select and invoke correctly.

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

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

The schema provides only titles without descriptions (0% coverage), so the description carries full responsibility. It delivers: 'regulation: Short regulation code (case-insensitive, e.g. 'gdpr', 'dora')' and 'article: Optional article number (e.g. '28', '30', '5'). Omit to browse all obligations for the regulation.' These are clear, include examples, and explain default behavior for article. The list of acceptable regulation codes is also included, making both parameters fully self-documenting.

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 clear statement: 'Return verbatim obligation text from the Velvoite corpus for an EU regulation article, plus the canonical EUR-Lex URL for reference.' This names a specific verb (return), resource (EU regulation article in Velvoite corpus), and output (verbatim text + URL). It also lists supported regulation codes, further clarifying scope and distinguishing it from broader tools like get_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?

The description explains why this tool exists: 'Queries the Velvoite corpus directly — no web fetching required. EUR-Lex blocks direct web fetch; the corpus has the authoritative text.' This gives the agent a clear decision heuristic (use when you need verbatim obligations and want to avoid web fetch issues). It also states the API key requirement and the optional article parameter behavior. However, it does not explicitly name alternatives or exclusions (e.g., vs. search_eu_regulation_text), so it doesn't fully earn a 5.

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

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

Discloses the Velvoite Premium API key requirement, the live nature of the query, and a known limitation: 'CELLAR does not reliably index final legislative acts via SPARQL.' This adds context beyond readOnlyHint and openWorldHint annotations, with 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?

The description is well-structured and front-loaded, but it is somewhat lengthy due to multiple examples. All content is useful, yet some examples could be condensed without losing meaning.

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 (so return values are structurally defined), the description covers the tool's scope, limitations, auth requirements, and alternatives. It is complete for a single-parameter lookup tool.

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

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

The schema provides no description for the celex parameter (0% coverage), but the description fully compensates with an 'Args' section, CELEX format examples, and case-insensitivity note.

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 action and resource: 'Look up any EUR-Lex document by CELEX number via CELLAR SPARQL (live).' It also differentiates from siblings by explicitly recommending get_eu_regulation_article for known regulation codes.

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 guidance: 'Use get_eu_regulation_article for known regulation codes (gdpr, dora, mica…).' Additionally, it explains when CELLAR SPARQL is used vs. direct URL for legislative acts, clarifying alternatives and limitations.

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 the description adds the admin API key requirement, a valuable behavioral disclosure. 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 compact: a clear purpose sentence, an auth requirement, and a well-structured filter list. Every sentence provides necessary 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 output schema exists and annotations cover safety, the description adequately covers purpose, auth, and filter options. This is sufficient for a simple filtered-list 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 schema description coverage at 0%, the description compensates by enumerating valid values for status, feedback_type, and context_type. It omits any explanation of the limit parameter, but the name and default value make it self-explanatory.

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 the tool retrieves user feedback for QA review, using a specific verb and resource. Distinguishes itself from sibling tools that fetch obligations, documents, or 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?

Provides clear context (QA review) and a prerequisite (admin API key). However, it does not explicitly mention alternatives or when not to use the tool, so it stops short of full usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them. It adds value by specifying the exact return fields ('company name, status, registered address, company form, registration date'), which gives the agent a clear expectation beyond the annotation's safety 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 two concise sentences plus a single parameter explanation. Every sentence provides distinct information: the lookup action, the returned fields, and the parameter format. 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?

For a simple 1-parameter lookup with output schema, annotations, and a clear parameter format, the description is sufficiently complete. It covers what the tool does, what it returns, and how to provide the input, making it easy for an agent to invoke correctly.

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

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

The input schema provides no description for 'business_id', but the tool description includes an Args section that defines it as 'Finnish business ID / Y-tunnus' and provides the required format '1234567-8'. This fully compensates for the 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 states a specific verb ('Look up'), a specific resource ('Finnish company in the PRH Trade Register'), and a specific key ('business ID (Y-tunnus)'). This clearly distinguishes it from siblings like search_finnish_companies, which would be used to find companies without a known 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?

The description implies usage when a business ID is known, but it does not explicitly say when to use this tool over alternatives or mention sibling tools. It offers no exclusions or alternative recommendations, leaving the comparison to be inferred from the parameter 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 already declare readOnlyHint=true, and the description adds important context: Finlex has no public JSON API, so the URL must be fetched via WebFetch, and the tool returns a URL, not the statute text. It does not mention failure modes, but the annotations lower the burden.

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 opens with the core purpose, then provides useful background, input modes, and an explicit list of known codes. The structure is clear (paragraphs and an Args section), and 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?

It fully covers purpose, input syntax, when to use an alternative, external fetch behavior, and defaults. Given the tool's simple scope and the presence of an output schema, no critical information is missing.

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

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

Schema description coverage is 0%, so the description must carry the parameter-semantics burden. It fully explains law_code (short code OR year/number, case-insensitive) and section ('chapter:paragraph' format, omit for full act), which is not present in the schema.

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

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

The description states a specific action ('Return the canonical Finlex URL for a Finnish statute') and clearly identifies the resource and outcome. This distinguishes it from sibling tools like search_finnish_statutes and other Finnish legal tools.

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

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

It explicitly says to use search_finnish_statutes for unknown statutes and specifies the two accepted input forms (law code or year/number). This gives clear when-to-use guidance and names an alternative.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful context: requires 'Velvoite Premium API key', mandates a search-first access pattern, and warns that Finlex requires prior search provenance. It also implies a returned search_query field.

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 information-dense and well-structured: starts with purpose, then prerequisites, citation context, alternative, and a numbered access pattern. Every sentence contributes essential guidance, and the Args section is clearly formatted.

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 (access pattern, API key requirement, citation format) and the presence of an output schema, the description covers all necessary aspects for selecting and invoking the tool correctly. It also references sibling functionality for broader browsing.

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 provides no descriptions (0% coverage), but the description's Args section explains both 'year' and 'number' with format and examples ('Decision year (e.g. '2024')', 'Decision number within the year (e.g. '52')'). This fully compensates for the schema 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?

The description clearly states 'Return access details for a Finnish Supreme Administrative Court (KHO) precedent decision' with a specific verb and resource. It also differentiates from sibling search_kho_decisions by explicitly noting that tool for browsing all 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?

It directly references an alternative ('Use search_kho_decisions(year) to browse all decisions for a given year') and provides a detailed access pattern with ordering and an explicit prohibition ('Do NOT fetch finlex_url directly'). This gives clear when-to-use and how-to-use 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?

The description adds significant behavioral context beyond the readOnlyHint annotation: pagination limits, trigram + ILIKE search, canonical mode semantics, and the structure of returned obligations. It provides rich detail about how the tool behaves, far exceeding what annotations alone convey.

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 a clear summary, usage notes, and a detailed Args list. Each sentence provides essential information without redundant padding. The length is justified by the complexity of the tool, and the organization improves 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?

The description covers the tool's purpose, key behaviors, all parameters, pagination, search, and canonical mode. With an output schema present, describing return values is unnecessary. For an 8-parameter tool, this description is complete and self-contained.

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 the schema having no per-parameter descriptions (0% coverage), the description's Args section thoroughly explains every parameter, including valid examples, value ranges, and cross-references (e.g., actor_role uses get_actor_roles). This fully compensates for the schema's lack of detail.

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

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

The description clearly states it retrieves regulatory obligations, with a specific verb ('Get') and resource ('regulatory obligations'). It distinguishes itself from siblings by explaining the difference between raw obligations and canonical obligations via the canonical flag. The phrase 'specific requirements extracted from regulations' adds precision.

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 guidance on when to use the tool, including combining filters and using get_actor_roles first. However, it does not explicitly mention alternatives (e.g., get_canonical_obligations) or when not to use this tool, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. It adds valuable behavioral context by stating the output is counts only, the grouping by regulation_code, and the status breakdowns. It also sets expectations about what is NOT included (full obligation text), which goes beyond the annotations.

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

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

The description is concise, front-loaded with the main purpose, then the return summary, then parameter details. Every sentence provides value without redundant information. The structure is logical 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 an output schema exists (so return fields are documented elsewhere), the description covers all necessary context: what the tool does, what it returns, what filters are available, and how to find valid filter values. It is sufficiently complete for an agent to select and invoke this 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 0% schema description coverage, the description fully compensates by explaining both parameters with concrete examples ('credit_institution', 'financial_entity,credit_institution') and referral to related tools for discovering valid roles. This adds meaningful semantics beyond the bare 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 uses a specific verb ('Get') and resource ('obligation counts grouped by regulation_code'), and clearly distinguishes itself from sibling tools by explicitly stating 'No full obligation text — just counts for a quick overview.' This directly separates it from get_obligations and similar retrieval tools.

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

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

The description implies when to use this tool ('quick overview') and contrasts it with full obligation text, but it does not explicitly name the alternative tool (e.g., 'use get_obligations for full details'). It does provide excellent guidance for parameter values by pointing to get_company_profile and get_actor_roles.

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 include readOnlyHint=true, and the description adds valuable behavioral details: it returns documents from the last N days, sorted by publication date (newest first), and explains the urgency_max logic (1=critical, 2=high). This goes beyond the annotations, though it doesn't discuss authentication or rate limits.

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 and front-loaded: a one-sentence purpose, a brief use-case statement, and a clean Args list. Every sentence earns its place with no fluff or repetition.

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 read-only tool with four optional parameters, the description covers the purpose, the timing scope, the sort order, and the meaning of each parameter. An output schema exists, so return values are not the description's responsibility. This 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?

The schema has no descriptions for properties, but the description's Args section provides clear explanations for all four parameters: days (look back N days, default 7), entity_type (filter by code), regulation (filter by family code), and urgency_max (at or above this urgency). This fully compensates for the schema's lack of 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 clearly states the tool's purpose with a specific verb+resource: 'Get recently published or updated regulatory documents.' It also positions itself as a 'Shortcut for what is new this week,' distinguishing it from sibling tools like search_regulations or get_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 provides clear usage context ('Useful for weekly regulatory briefings') and explains the lookback window and sorting. However, it does not explicitly mention alternatives or when not to use this tool, though the context is sufficient for most cases.

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

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

The description adds context about the returned statistical summaries and date range, but the readOnlyHint and openWorldHint annotations already cover safety and scope. It does not disclose potential rate limits or other behavioral traits, but the tool is a simple read-only overview, so the added detail is moderate.

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 concise sentences: first states the purpose, second lists outputs, third gives usage guidance. Information is front-loaded and every sentence earns its place with no 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 is a zero-parameter overview with an output schema present, the description fully covers what it returns, when to use it, and that no parameters are needed. It is complete for the tool's simplicity.

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

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

The tool has 0 parameters, so the description's note 'No parameters needed' is sufficient. Baseline for 0 params is 4, and the description clearly states this, adding minimal but necessary confirmation.

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 an overview of the Velvoite regulatory corpus' with a specific verb and resource, and enumerates the output categories (counts by source, regulation family, etc.). This distinguishes it from sibling tools like get_document or list_documents, which serve different 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?

Explicitly instructs 'Call this FIRST to orient yourself before running queries,' providing clear usage context. It does not mention alternatives or when not to use it, but for a zero-parameter overview tool this is sufficient. No exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable return-format details: 'total, verified, unverified counts overall and per regulation, with percentage verified.' This goes beyond the annotations and schema.

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

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

The description is concise: three short sentences that cover purpose, return contents, and usage. No filler or redundant details. It is well-structured 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?

The tool is simple with no parameters and an output schema. The description covers purpose, return data, and intended usage. It is fully sufficient for an agent to select and invoke this 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?

There are zero parameters, and the description explicitly states 'No parameters needed,' which is helpful for the agent. With 0 params, the baseline is 4, and the description confirms the absence of parameters without redundancy.

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: 'Get verification progress for obligations across all regulations.' This is a specific verb+resource+scope description. It doesn't explicitly differentiate from siblings like get_stats, but the resource is distinct enough.

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 an explicit usage context: 'Use this to track human review progress.' It doesn't mention when not to use it or list alternatives, but the guidance is clear for the intended use case.

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 include readOnlyHint=true and openWorldHint=false, but the description goes beyond annotations by disclosing the return format (paginated list with summaries, tags, doc_purpose, doc_jurisdictions), the semantics of urgency_max, and days filtering. No contradiction with annotations. The behavioral traits are well disclosed for a read-only browsing tool.

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 efficient and front-loaded with the main purpose, followed by a structured 'Args:' block. It is somewhat lengthy due to enumerating many allowed values, but each sentence earns its place. Minor redundancy could be trimmed, but the structure is clear and scannable.

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 optional filters, pagination), the description is complete: it documents all parameters, explains return fields, provides a usage example, and points to the alternative search_regulations tool. The presence of an output schema further reduces the need to explain return structure. The description leaves no major gaps for an agent to misuse 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 description coverage is 0%, so the description carries full burden. It thoroughly explains all 7 parameters: source and regulation list allowed enum-like values, entity_type lists allowed types, urgency_max explains the ordinal scale (1=critical to 5=informational), days specifies range (1-365), and page/per_page have defaults and max limit. This adds significant meaning beyond the bare 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 function: 'Browse regulatory documents with filters and pagination.' It distinguishes itself from sibling tool search_regulations by explicitly noting this is for filtered browsing rather than keyword search. The verb 'browse' and resource 'regulatory documents' are specific and 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 usage guidance: 'Use this for filtered browsing (e.g. all DORA documents from the last 30 days). Use search_regulations instead when you have specific keywords to search for.' This tells the agent exactly when to use this tool vs. the alternative, eliminating ambiguity.

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

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

Annotations declare readOnlyHint and openWorldHint, and the description adds the critical Velvoite Premium API key requirement and the fact that results are based on title matching. It also mentions fetching the returned URL for full judgment text. This provides valuable context beyond the 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 concise and well-structured, with a brief summary paragraph followed by a clearly formatted Args section. Every sentence adds value, and there is no redundancy with the annotations or schema.

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 that an output schema exists and the description covers purpose, usage context, parameter semantics, authentication requirements, and next steps (fetch URL for judgment), the description is complete for an AI agent to select and correctly invoke this tool.

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

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

The input schema itself has minimal descriptions, but the Args block provides rich semantics for both parameters, including concrete examples ('money laundering', 'Directive 2015/849') and usage advice ('keep it specific', 'use the regulation name instead'). This fully compensates for the schema's lack of description.

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

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

The description clearly states it searches CJEU case law via EUR-Lex CELLAR SPARQL and returns cases matching keywords in the case title. The phrase 'live — not limited to Velvoite corpus' distinguishes it from other potential search tools. The verb-resource structure is specific and 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?

Explicitly says 'Use to find court decisions on a specific regulation, topic, or legal concept.' It also provides practical search tips like 'Phrase search — keep it specific' and warns that CJEU titles rarely contain article numbers. However, it does not explicitly name alternative tools for other use cases, so it stops short of a 5.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description's contribution is the API key requirement and the clarification that it returns a URL rather than the actual text. This adds value beyond annotations without contradicting them.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by usage context, a requirement, and parameter explanations. Every sentence contributes value without redundancy or filler.

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

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

For a simple tool with two parameters and an output schema, the description covers purpose, usage, auth requirement, and parameter semantics. The existence of an output schema means return value details are not necessary, and the description sufficiently communicates the tool's scope.

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 explaining both parameters: query is described with an example ('data processing agreement processor obligations') and regulation as an optional scope example ('gdpr'). This provides meaningful semantics beyond the bare property names.

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 EUR-Lex search URL for finding regulation provisions by keyword.' This is a specific verb+resource combination. It also distinguishes from siblings by mentioning 'when you don't know the exact article number,' implying an alternative for article 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 an explicit usage trigger: 'Use when you don't know the exact article number but need to find relevant provisions.' It also mentions the Velvoite Premium API key requirement, but does not explicitly name alternative tools like get_eu_regulation_article, so it lacks full alternative guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds that the search is by exact or partial name and accepts optional city filtering, plus a mention of the PRH Trade Register source. It doesn't disclose any limitations, but for a simple search, this is sufficient.

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

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

The description is compact, front-loads the primary action, and uses a structured Args list. All sentences are purposeful.

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 search context, read-only annotations, and existing output schema, the description covers purpose, use cases, and parameters. It is complete enough for an agent to select and invoke correctly.

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

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

Schema properties have no descriptions; the description documents both parameters: name ('Company name or partial name') and city ('Optional municipality to narrow results') with examples. This fully compensates for 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 'Search Finnish companies by name in the PRH Trade Register' with specific use cases, distinguishing it from sibling search tools targeting statutes or 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?

It provides explicit use cases: 'find a business ID when you only know the company name' and 'check whether a company name is already taken.' It does not explicitly name alternatives like get_finnish_company, but the guidance is clear enough.

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 a critical behavioral trait: it returns a URL rather than direct results because Finlex has no public JSON API. This is significant context beyond annotations, fully clarifying the tool's operational 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 concise and front-loaded. The first sentence states the purpose, the second explains the rationale for the unusual return type, and the args list adds parameter guidance. No unnecessary words or repetition.

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 single parameter, existing output schema, and annotations, the description provides complete context: it explains the return type, the query parameter, and the external constraint (no API). Nothing important is missing.

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

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

The schema provides only the parameter name 'query' with no description (0% coverage). The description fully compensates by explaining the parameter: 'Search terms in Finnish or English' and providing examples like 'kilpailukielto' and 'non-compete'. This gives clear guidance on what to input.

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 Finlex search URL for Finnish statute keyword search.' It specifies the resource (Finnish statutes via Finlex) and the action (search keyword), distinguishing it from sibling tools like search_finnish_companies or 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?

The description provides clear context: Finlex has no public JSON search API, so the tool returns a search URL for Claude to fetch. This implies when to use the tool (searching Finlex statutes) and how to handle the output. However, it does not explicitly mention alternative tools or 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?

The description discloses that it returns a search query rather than decisions, requires a premium key, and cannot directly fetch the Finlex page. These are valuable behavioral details beyond the readOnlyHint and openWorldHint annotations, with 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 the core purpose, and structured with a NOTE and Args section. Each sentence adds necessary 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 simplicity of a single parameter and the existence of an output schema, the description is complete. It covers the prerequisite, the limitation, the workflow, and the next step, making it fully contextual.

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

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

The schema only labels the parameter as 'Year', while the description adds 'Year to browse (e.g. '2024', '2023')', providing context and examples. While basic, this compensates for the 0% schema description coverage adequately for a single simple 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?

The description clearly states that the tool returns a search query to discover KHO precedent decisions for a given year. It distinguishes itself from get_kho_decision by explaining the returned query is for web_search, not direct 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?

Provides explicit workflow: use the returned search_query with web_search, then fetch individually with get_kho_decision. Also mentions the API key requirement and explains why direct fetching is impossible (client-side rendering), giving clear when-to-use 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?

Beyond the read-only annotation, the description discloses the underlying mechanism (PostgreSQL trigram similarity on titles/summaries) and the output characteristics (ranked by relevance, with summaries and classification tags). 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 succinct: a brief purpose opener, a technical detail sentence, a returns sentence, usage guidance, and parameter docs. Every sentence adds value and is front-loaded with the core purpose.

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

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

Given the output schema exists, the description doesn't need to explain return values. It covers inputs, usage context, behavioral expectations, and parameter semantics comprehensively for a search tool with moderate 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?

The schema has 0% description coverage, but the description thoroughly documents both parameters: 'query' with concrete examples and 'per_page' with default and maximum. This fully compensates for the schema's lack of explanatory text.

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 function: searching the regulatory corpus using keyword/trigram matching. It distinguishes itself from sibling tools like list_documents by explicitly naming it as the structured-filter alternative, and from other search tools by specifying the corpus scope.

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

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

The description provides explicit guidance: 'Prefer list_documents with filters first' and 'Only use this for free-text keyword search when structured filters aren't sufficient.' This directly tells the agent when to use this tool versus an alternative.

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