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

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds useful context by enumerating the returned data elements (server identity, version, data sources, runtime capabilities). However, it does not disclose additional behavioral traits such as response format, caching, or authentication requirements. The bar is lower due to annotations, but this is only a modest improvement over the annotation's safety profile.

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

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

The description is two sentences, well-structured, and front-loaded with the main outcome. The first sentence states what the tool returns; the second adds a usage scenario and an alternative. Every sentence earns its place, with zero fluff or repetition of schema fields.

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 tool with no parameters, no output schema, and simple read-only behavior, the description is complete. It explains the return content, the use case, and even an alternative access method. No further context is needed to understand when and how to use this tool effectively.

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

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

The tool has zero parameters, so schema coverage is 100% and there are no parameter semantics to clarify. The baseline for 0 parameters is 4, and the description does not need to explain anything about parameters since there are none. It correctly implies no arguments are needed by omitting any mention of them.

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 server identity, version, data sources, and runtime capabilities.' It uses a specific verb ('Return') and resource (server metadata), making it distinct from sibling tools that search or fetch specific legal data. It also explains the use case of discovering tier and capabilities, which further clarifies its unique role.

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

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

The description explicitly says 'Use this tool to discover what tier and capabilities are available' and provides an alternative: 'Equivalent to reading the MCP resource case-law-stats://dutch-law-mcp/metadata but callable as a tool.' This gives clear context on when to use the tool and even names the resource alternative, satisfying the 'alternatives' criterion.

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 destructiveHint=false. The description adds meaningful behavioral context beyond that: it aggregates multiple legal source types, provides a structured response, and gracefully degrades on free tier (omitting case law and preparatory works). This extra information helps the agent anticipate output limitations without contradicting annotations.

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

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

The description is concise and well-structured: three sentences each serve a distinct purpose (function, best-use scenario, alternatives/degradation). No redundant or filler content, making it easy for an agent to quickly parse the essential information.

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

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

Given the tool's aggregative complexity and lack of an output schema, the description adequately conveys the scope (multiple source types, structured response) and limitation (free tier degradation). It could potentially list the return structure or error handling, but the current description covers the main decision-making context for an agent. The explicit alternative referrals complete the contextual picture.

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

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

Schema description coverage is 100%, so parameters are already well-documented in the input schema. The description does not add significant parameter-level details beyond implying that 'query' is the legal question and 'limit' may apply per category based on the aggregation context. This meets the baseline for high schema coverage but does not exceed it.

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: 'Build a comprehensive legal stance... aggregating statute provisions, case law, preparatory works, and cross-references into a single structured response.' It uses a specific verb and resource and distinguishes itself from sibling tools by noting it is 'best for broad legal research questions' and explicitly contrasting with targeted 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 provides explicit usage guidance: 'Best for broad legal research questions' and directs users to 'use search_legislation or get_provision for targeted single-source queries instead.' It also mentions the free tier degradation behavior, giving context on when the tool may be less complete.

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 destructiveHint=false, so the safety profile is established. The description adds valuable output details: status values (in_force/repealed/not_yet_in_force), in-force date, warnings, and optional cross-references, which go 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 compact and front-loaded with the core purpose, followed by return values, usage advice, optional parameters, and cross-references. No sentence is redundant or off-topic.

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 lack of an output schema, the description adequately covers the return status, date, warnings, and optional related case law. It could be slightly more complete by noting behavior if the document is not found or invalid, but it is sufficient for a read-only legal checking 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 100%, so all three parameters (document_id, as_of_date, provision_ref) are already documented. The description's mention of 'specific provision and date' adds minimal semantic value beyond what the schema states, leaving the baseline at 3.

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

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

The description clearly states the tool checks whether a Dutch statute or provision is currently in force, with a specific verb (check) and resource (statute/provision). It distinguishes itself from siblings like get_provision or get_provision_at_date by focusing on legal validity status rather than content 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 explicitly says 'Essential before relying on a provision — always check currency for legal advice,' providing a clear when-to-use context. However, it does not mention alternatives or when not to use, though siblings imply the alternative of retrieving provisions directly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond that: it specifies output contents (last-updated timestamps, statuses) and the exact staleness thresholds per source. 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?

Two concise sentences pack a clear purpose, return values, staleness thresholds, and usage guidance without redundancy. Every sentence earns its place, and the structure is front-loaded with the core action.

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 one optional parameter, the description fully covers when to use, what it returns, and how to interpret results via thresholds. No output schema exists, but the description explicitly mentions the output format (timestamps, statuses), making it 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?

The input schema already fully describes the optional 'source' parameter with enum values and the behavior when omitted. Schema description coverage is 100%, so the description adds no additional parameter meaning. The baseline of 3 is appropriate.

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

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

The description states a specific action ('Check the freshness (age) of each data source') and identifies the key resources (statutes, case_law, eu_references) and return values (timestamps, fresh/stale/unknown status). It clearly distinguishes from siblings like check_currency, which focuses on legal validity, not data age.

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

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

The description gives explicit usage context: 'Use this before relying on legal data for time-sensitive analysis.' It also specifies staleness thresholds, providing concrete decision criteria. However, it does not mention exclusions or alternative tools, 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 annotations (readOnlyHint=true, destructiveHint=false), the description adds key behavioral context: 'no database lookup, no validation.' This tells the agent the tool has no side effects, performs no data retrieval, and won't validate existence. This goes beyond 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 two concise sentences, front-loaded with the purpose and immediately clarifying scope, limitations, and alternatives. Every sentence adds value; there is 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?

For a simple tool with no output schema, the description covers all necessary context: purpose, behaviors, formats, and alternative for validation. It provides a complete picture for an AI 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?

Schema coverage is 100%, so the bar is lower, but the description enriches parameter meaning by expanding the format enum values: 'full (formal), short (abbreviated), and pinpoint (with subsection).' This provides semantic clarity beyond the schema's basic 'full, short, or pinpoint' 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?

Description clearly states the tool formats Dutch legal citations, with a specific verb and resource. It distinguishes itself from sibling tools by explicitly noting 'Pure formatting — no database lookup, no validation' and points to validate_citation for validation, making it 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 gives explicit when-to-use guidance by defining the scope as pure formatting, and explicitly directs the agent to 'Use validate_citation instead if you need to verify the citation actually exists.' This is a clear exclusion and alternative, meeting the highest standard.

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 destructiveHint=false, so the safety profile is known. The description adds value by specifying the exact return payload (BWB-IDs, statute titles, implementation status) and the required format for eu_document_id, offering transparency beyond the simple read-only hint.

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

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

The description is three sentences long, front-loaded with the core purpose, and every sentence adds useful information: reverse lookup direction, return fields, forward-lookup alternative, and input format. No redundant content.

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 straightforward read-only lookup with three parameters and no output schema, the description is complete. It states what the tool returns and provides the essential input format. The boolean parameters are adequately explained in the schema, so no further detail is required here.

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?

Although the schema already covers all three parameters with descriptions (100% coverage), the tool description adds crucial format guidance for eu_document_id ('directive:YYYY/NNN' or 'regulation:YYYY/NNN', with an example). This goes beyond the schema's generic description, justifying a score above the baseline 3.

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

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

The description opens with 'Reverse EU lookup' and clearly states the function: find Dutch statutes implementing a given EU directive or regulation. It distinguishes itself from the sibling tool get_eu_basis by explicitly labeling the direction of 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 explicitly tells the user to use get_eu_basis for the forward lookup (Dutch law → EU basis), providing a clear alternative. This directly addresses when to use this tool versus a known sibling.

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 destructiveHint=false. The description adds useful behavioral context by detailing the return payload (CELEX numbers, EUR-Lex links, reference types, primary implementation flag). It doesn't describe edge cases (e.g., empty results) but goes beyond annotation coverage.

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

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

Three sentences: the first states the core function, the second lists outputs, and the third mentions alternative tools. Front-loaded, no redundant words, every sentence earns its place.

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

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

With no output schema, the description summarizes key return values (CELEX, links, reference types, primary implementation) and points to related tools. This is sufficient for a 3-parameter read-only tool, covering purpose, output, and alternatives comprehensively.

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

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

Input schema has 100% parameter description coverage, so baseline is 3. The description mentions reference types (implements/references/supplements) which mirrors the schema, adding no new semantic information about parameters. It aligns with the reference_types filter but doesn't elaborate further.

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 'Get the EU legal basis (directives/regulations) for a Dutch statute' and lists specific return elements (CELEX numbers, EUR-Lex links, reference types, primary implementation). It distinguishes itself from sibling tools get_provision_eu_basis (provision-level) and get_dutch_implementations (reverse 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?

Explicit guidance is given: 'Use get_provision_eu_basis for provision-level EU references' and 'Use get_dutch_implementations for the reverse lookup.' This clarifies when to choose alternatives, leaving no ambiguity about this tool's niche.

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 destructiveHint=false. The description adds meaningful behavioral context by specifying the return contents (parliamentary documents) and the tier-based behavior (upgrade notice on free tier), which are not present in the annotations. No contradiction exists between description and 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 consists of three sentences, each serving a distinct purpose: stating the function, listing return contents, and providing usage context and tier restriction. It is front-loaded, efficient, and contains no redundant words 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 read-only tool with three well-documented parameters and no output schema, the description adequately covers purpose, return content, tier restriction, and recommended use case. It lacks details about pagination or output format, but these are not critical given the annotations and parameter documentation, making it complete enough for an agent to 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?

The input schema covers all three parameters with descriptive text, achieving 100% schema description coverage. The description's mention of document types like MvT and MvA mirrors the schema's document_type examples without adding new information. Thus, the description adds little beyond the schema, supporting a baseline score of 3.

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

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

The description clearly identifies the tool's function with a specific verb and resource: 'Get preparatory works ... for a Dutch statute.' It enumerates the exact document types returned (MvT, MvA, nota, amendments), making the purpose unambiguous. While it doesn't explicitly name sibling tools, the focus on a specific statute's documents distinguishes it from similar search tools.

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

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

The description gives an explicit use case: 'Use when you need legislative intent or historical context for a statute.' It also states a key constraint: 'Professional tier only — free tier returns an upgrade notice.' However, it does not discuss alternatives or when not to use the tool, falling just short of full guidance.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful context (returns full text, metadata, source URL; fallback to all provisions with size warning). However, it directs historical queries to get_provision_at_date while the schema includes an as_of_date parameter for historical versions, creating a confusing inconsistency about the tool's actual 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 yet informative, starting with the main purpose, then return information, warnings, examples, and alternatives. Every sentence earns its place, and it is well-structured for quick parsing.

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

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

Without an output schema, the description states the return format (full text, metadata, source URL) and covers key use cases. It warns about large responses and provides examples. The as_of_date discrepancy is a minor gap, but overall it gives enough context for safe and correct invocation.

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

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

Schema coverage is 100%, so the baseline is high. The description adds value with concrete examples (document_id='BWBR0005289', book='6', article='162') that clarify parameter combinations beyond the schema descriptions. It does not need to repeat parameter details.

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: 'Retrieve a specific provision (article) from a Dutch statute by BWB-ID.' It specifies the verb, resource, and identification method, and distinguishes itself from siblings like search_legislation and get_provision_at_date.

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 search_legislation if you don't know the BWB-ID' and 'Use get_provision_at_date if you need a historical version.' It also warns about the behavior when no article is specified, covering when to use with care.

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 destructiveHint=false. The description adds valuable behavioral details: it uses version history, returns not_found if no version exists for the date, and the effect of include_amendments=true. 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?

Five concise sentences, each serving a distinct purpose: main action, rationale, optional parameter usage, error case, and alternative tool. No 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?

Comprehensive for a read-only tool: covers purpose, usage, error condition, and alternative. No output schema, but description indicates it returns the text valid at that date. Could mention response structure, but overall 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 covers 100% of parameters, so baseline is 3. The description enhances semantics by elaborating on include_amendments (full amendment chain) and clarifying that date is for historical querying, adding value beyond the schema.

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

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

The description clearly states the tool retrieves a provision at a specific historical date using version history. It specifies the verb 'Retrieve', the resource 'provision', and the temporal qualifier, distinguishing it from the sibling tool get_provision.

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 ('analyzing past legal situations or tracking how a provision changed over time') and directs users to use get_provision for the current version. Additionally explains the include_amendments option for amendment chains.

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 and destructiveHint=false already declared, the description adds value by specifying that it shows EU directive/regulation articles and that it returns empty results if no EU references exist. This goes beyond the annotations by explaining the return behavior and the nature of the references.

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 three sentences with no fluff: purpose, granularity comparison, and empty-result behavior. Each sentence earns its place, front-loaded with the main action.

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 two-parameter, read-only tool with no output schema, the description provides essential context: what it returns, how it differs from the sibling, and the empty-results edge case. This is complete enough for an agent to select and invoke it 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 covers 100% of parameters with descriptions, so the schema does the heavy lifting. The description adds no additional meaning beyond saying 'specific provision', which is already captured in the provision_ref parameter description. Baseline 3 is appropriate.

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

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

The description clearly states the tool gets EU references for a specific provision in a Dutch statute, with a specific verb and resource. It explicitly distinguishes itself from get_eu_basis by noting it is more granular (provision-level vs statute-level), which differentiates it from the most similar sibling.

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 on when to use this tool: when provision-level EU references are needed, as opposed to statute-level via get_eu_basis. It names the alternative tool, though it doesn't explicitly state 'use this instead' or list other exclusions. This is strong comparative guidance, but not perfectly explicit.

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 destructiveHint=false, covering safety. The description adds valuable context about the return content (coverage, licensing, freshness, update frequency) and the optional stats behavior, providing transparency about what the tool does beyond the 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 three sentences, front-loaded with the core purpose, and each sentence adds distinct information: what the tool does, what it returns, and how to use the parameter. No waste or 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 (one optional boolean parameter) and the description fully conveys its scope, output, and usage. It mentions the types of metadata returned, which is sufficient given no output schema exists. The description adequately completes the context needed for an agent to decide when 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?

Schema coverage is 100% (the only parameter include_stats is fully described). The description repeats the parameter behavior ('Set include_stats=true to get row counts per table') without adding new meaning, so it aligns with the baseline but doesn't go 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 lists authoritative data sources backing the server, names specific sources (wetten.overheid.nl, rechtspraak.nl, EUR-Lex), and specifies the output (provenance metadata). This distinguishes it from sibling tools like check_data_freshness, which focuses on currency of specific provisions rather than the sources themselves.

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 context: 'Use this tool to verify data origin and understand what data is available.' It explains the tool's role in data provenance verification, though it does not explicitly mention when not to use it or name alternative tools for other tasks.

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 destructiveHint annotations, the description discloses several behavioral traits: returns specific fields (ECLI, court, date, summary, keywords), supports FTS with filters, handles direct ECLI lookups alternatively, returns an empty array when no matches, and notes the free-tier upgrade notice. This gives the agent a clear picture of expected outcomes and limitations.

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

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

The description is three sentences long, with the primary purpose stated first, followed by return value, features, and a critical caveat. Every sentence earns its place: function, capabilities, ECLI alternative, tier restriction, and empty result behavior. There is no 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 tool with 8 optional parameters and no output schema, the description covers the essential aspects: what it does, what it returns, key behavioral details (empty array, tier restriction), and the main usage pattern (query vs. ecli). It does not list every filter, but the schema covers those details, and the description summarizes them sufficiently. Given the tool's complexity, 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?

Since the input schema already describes all 8 parameters with 100% coverage, the baseline is 3. The description adds value by explaining the relationship between 'ecli' and 'query' (mutually exclusive use cases) and by summarizing the filter categories (court, legal domain, procedure type, date range), which reinforces the schema. However, it doesn't add significant new syntax or format details beyond the schema.

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

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

The description clearly states the tool's function: 'Search Dutch court decisions from rechtspraak.nl (202K+ decisions)'. It specifies the resource (Dutch case law), the source (rechtspraak.nl), and the scope (202K+ decisions), distinguishing it from sibling tools like search_legislation and search_parliamentary_proceedings. The verb 'Search' is action-oriented and concrete.

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

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

The description gives specific usage guidance, notably 'For direct ECLI lookup, use the ecli parameter instead of query.' It also mentions the professional tier limitation, which is critical for deciding whether to use the tool. While it doesn't explicitly contrast with all sibling alternatives, the focus on case law naturally separates it from legislation and parliamentary searches.

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 destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context beyond the annotations: it states the database size (1,008 documents), what is returned (EU document metadata with Dutch implementation counts), and the available filtering dimensions. This provides a fuller picture of the tool's behavior.

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

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

The description is three sentences long, front-loaded with the main action, and every sentence earns its place: the first states what the tool does, the second describes the output and filter capabilities, and the third gives the usage context. No redundant or irrelevant 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?

Despite no output schema, the description sufficiently explains what is returned ('EU document metadata with Dutch implementation counts') and the context for use. For a search tool with read-only annotations, this is complete: it covers purpose, output, and usage without needing to enumerate every parameter detail, which the schema handles.

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

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

Schema coverage is 100% with each parameter having a description, which sets a baseline of 3. The description enhances this by summarizing the key filter groups ('type (directive/regulation), year range, community (EU/EG/EEG), and whether a Dutch implementation exists'), giving the agent a quick understanding of how the parameters combine to filter results. This adds value beyond the raw 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 with a specific verb and resource: 'Search EU directives and regulations in the database.' It also distinguishes from siblings by noting 'Use when browsing EU instruments rather than looking up a specific one,' which separates it from lookup-style tools like get_eu_basis or get_provision.

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

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

The description gives explicit usage guidance with both a positive directive ('Use when browsing EU instruments') and a negative one ('rather than looking up a specific one'). Although it does not name a specific alternative tool, the contrast with lookup behavior is clear enough for an agent to decide when to choose this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral details: it returns an empty array (not an error) when no results match, and notes the FTS5 BM25 ranking implementation. It also warns that higher limit values consume more tokens. These go beyond the 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 concise and well-structured: starts with the core purpose, then data source, return format, parameter usage, edge-case behavior, and alternative tool. Each sentence earns its place and no content is redundant with the 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?

With no output schema, the description fully explains what is returned (matching provisions, article text, title, BWB-ID). It also covers the empty-array edge case and provides guidance on all key parameters. For a search tool of this complexity, the description is complete and self-sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context: it provides example query terms, explains multi-word AND/OR fallback logic, and gives a concrete document_id example (BWBR0005289). This significantly helps the agent formulate correct queries beyond the raw schema descriptions.

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

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

The description clearly states the tool's function: 'Search Dutch statutes and regulations by keyword using full-text search' and specifies the return content (provisions with article text, statute title, BWB-ID). It also differentiates from the sibling tool get_provision by advising to use that when the exact BWB-ID and article number are known.

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 suggests using this tool for keyword searches and directs users to get_provision as an alternative when the exact ID is known. It also explains how to narrow results with document_id and query historical versions with as_of_date, providing clear context for when to use these parameters.

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 destructiveHint annotations, the description reveals critical behavioral traits: it returns an empty array when no results match, it covers only Tweede Kamer speeches, and it returns an upgrade notice on the free tier. These specifics help the agent set expectations for both normal and edge-case responses.

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

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

The description is a compact four-sentence paragraph, front-loaded with the primary action and result type. Each subsequent sentence provides valuable context (use cases, scope limits, tier restriction, empty-array behavior) without any redundant phrasing. The structure is logical and easy to scan.

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 absence of an output schema, the description adequately covers what the tool returns (speeches, motions, transcripts, speaker metadata) and how it behaves with no matches. It also addresses coverage limitations and access tiers. This is sufficient context 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 description adds minimal parameter-level meaning beyond the schema, reiterating that search uses FTS and date filters are available. Since the schema already has 100% coverage with clear descriptions and examples, the description's contribution is marginal. The added value is limited to confirming that the query is full-text and dates are filters.

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

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

The description clearly identifies the tool's specific function: searching Dutch parliamentary proceedings from the ParlaMint-NL corpus. It explicitly names the resource (Tweede Kamer/Handelingen) and the types of content returned (floor speeches, motions, debate transcripts). It distinguishes itself from sibling tools by focusing on parliamentary debates rather than legislation or case law.

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 contexts for use, such as understanding legislative intent, political debate context, and parliamentary questions. It also notes important constraints like the professional tier requirement and the exclusion of Eerste Kamer content. However, it does not explicitly mention alternative tools or when not to use this tool, leaving room for a more direct comparative guideline.

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 destructiveHint=false. The description adds behavioral context by stating it checks existence against the database and returns 'validation status with details on what was/wasn't found.' This goes beyond the annotations, though it doesn't detail error handling or exact return structure—acceptable given the low-risk read-only nature.

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

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

The description is front-loaded with purpose, then usage, then format examples, then alternative—all in three sentences. Every sentence provides essential information, with no filler. The format list is lengthy but necessary for correct invocation.

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 single-parameter validation tool, the description is complete: it states what it does, when to use it, what formats are accepted, what it returns (status with details), and which sibling to use instead. Even without an output schema, the return behavior is adequately described.

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 describes the single parameter only as 'Citation string to validate' (100% coverage). The description adds significant meaning by listing supported formats (e.g., 'Art. 6:162 BW', 'ECLI:NL:HR:2019:376') and clarifying what constitutes a valid citation. This materially helps the agent construct the parameter value.

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 specific purpose: 'Validate a Dutch legal citation against the database — checks whether the referenced document and provision actually exist.' It uses a specific verb ('validate') and resource ('Dutch legal citation'), and explicitly distinguishes from sibling 'format_citation' by contrasting validation vs. formatting.

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 verify citations before including them in legal analysis (zero-hallucination check).' It also names an alternative: 'Use format_citation instead if you just need to format a citation string.' This clearly tells the agent when to use and when not to use the tool.

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

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

Annotations already declare readOnlyHint: true, and the description adds behavioral context by stating it returns compliance issues with severity levels and recommendations in Dutch. No contradictions, and the description does not promise any destructive actions.

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 three sentences, each serving a distinct purpose: main function, output format, and usage order. It is front-loaded and free of 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?

Given the absence of an output schema, the description compensates by specifying the return value (compliance issues with severity levels and recommendations). It also covers the optional narrowing and the prerequisite relationship with get_eu_basis, making it sufficiently complete.

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

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

Schema coverage is 100% for all three parameters. The description adds semantic value by noting the optional narrowing to a specific provision or EU document, reinforcing the purpose of provision_ref and eu_document_id.

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 'Validate' with a clear resource 'EU compliance for a Dutch statute'. It further specifies the nature of checks (missing, partial, or outdated implementations) and distinguishes itself from sibling tools like get_eu_basis by focusing on validation rather than 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 gives explicit usage guidance: 'Use get_eu_basis first to see what EU instruments apply.' It also states optional narrowing with provision_ref and eu_document_id, making it clear when to use this tool versus others.

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