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

No annotations provided, so the description carries the full burden. It discloses that the tool returns metadata, statistics, freshness, and provenance. This is transparent and consistent with a read-only information 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?

Two concise sentences front-load key terms and provide actionable guidance. 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?

Given zero parameters and no output schema, the description is fully complete. It explains what the tool returns and when to use 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?

No parameters exist, so schema coverage is trivially 100%. The description adds meaning by explaining what the tool returns, exceeding the baseline of 4.

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 specifies 'Server metadata, dataset statistics, freshness, and provenance' and explicitly states the action 'verify data coverage, currency, and content basis'. This clearly distinguishes it from sibling tools that perform specific legal research functions.

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

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

The description explicitly states 'Call this to verify data coverage, currency, and content basis before relying on results', providing clear context for when to use it. It does not explicitly mention when not to use, but the usage guidance is strong.

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?

No annotations are provided, so the description carries the burden. It does disclose a key behavioral trait (simultaneous search across three categories) and implies a read-only operation through the word 'searches.' However, it does not describe the output format, potential for many results, or any performance/time implications of a broad search, leaving some behavioral uncertainty.

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

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

Four sentences with no filler. The primary purpose is front-loaded, followed by a concise behavior summary and then a clear 'when NOT to use' section. 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?

For a six-parameter tool with no output schema and no annotations, the description covers the main needs: what it does, when to use it, and how it differs from alternatives. It tells the agent the return is a 'set of citations,' which is sufficient at a high level, though it could additionally describe how the categories are combined or how limits apply.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning for parameters like limit, as_of_date, or include_case_law, but the schema already fully documents each parameter. The description's 'broad legal research' phrasing loosely aligns with query semantics but does not materially 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 opens with a specific verb and resource ('Build a comprehensive set of citations for a legal question') and then clarifies the mechanism ('Searches across statutes, case law, and preparatory works simultaneously'). This clearly differentiates it from siblings like get_provision and search_legislation, which are targeted lookups.

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

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

The description explicitly states when to use it ('Use this for broad legal research questions') and when not to, naming exact alternatives ('use get_provision or search_legislation instead'). This gives the agent a clear decision rule with no inference required.

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 no annotations, the description carries the behavioral burden. It discloses that the tool only returns status, not legal text, lists the possible statuses, and mentions dates and warnings. It does not discuss error behavior or permissions, but the read-only 'check' semantics and output categories are clearly conveyed.

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 short and front-loaded: purpose first, return values second, usage hint third, and exclusion last. Every sentence provides actionable information with no filler 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?

Despite no output schema and no annotations, the description covers purpose, return statuses, the historical-date parameter, and when to use a sibling tool. It does not elaborate on the nature of 'warnings' or invalid inputs, but for a simple status-checking tool it is largely 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 description coverage is 100%, so the baseline is 3. The description reinforces as_of_date for historical evaluation but does not add meaningful parameter semantics beyond what the schema already provides for document_id, as_of_date, and provision_ref.

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 names a specific action ('Check if'), a precise resource ('Finnish statute or provision'), and the outcome ('in force (current or historical)'). It enumerates the returned statuses and explicitly distinguishes itself from get_provision, so an agent can tell it apart from siblings without opening schemas.

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 clear when-to-use guidance ('Check if... in force') and an explicit 'When NOT to use' rule with a named alternative ('use get_provision'). It also instructs when to pass as_of_date for historical evaluation, leaving little to inference.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the three output formats with examples, indicating that the tool transforms a citation string into a standard formatted string. It does not mention behavior for invalid input or edge cases, but for a pure formatting operation this is a minor gap. The description is transparent about its main function.

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. It opens with a clear purpose statement, then lists the three formats in a compact list, and ends with an explicit when-not-to-use note. Every sentence earns its place; there is no fluff or redundancy. The structure is front-loaded with the core functionality, making it 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?

For a simple formatting tool with no output schema, the description provides sufficient context: it defines the input (a citation), the output formats, and when not to use it. The examples imply the return value is a string. A minor gap is that it doesn't explicitly state the return type or behavior for invalid inputs, but given the tool's simplicity and the clear format examples, the description is nearly 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 schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing concrete examples for each enum value of 'format' (e.g., 'Laki 1050/2018 3 luku 5 §', '1050/2018 3:5', '3 luku 5 §'). This helps the agent understand the expected output format without opening the schema. The 'citation' parameter is already described in the schema, but the examples enrich the semantics of the 'format' 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 states a clear verb and resource: 'Format a Finnish legal citation per standard conventions.' It lists the three output formats with concrete examples, which distinguishes it from sibling tools like validate_citation (which checks existence) and search_case_law (which searches). An agent can immediately understand what this tool does and how it differs from its siblings.

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

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

The description explicitly provides a 'When NOT to use' section: 'If you want to check whether a citation exists in the database, use validate_citation instead.' This gives a clear exclusion and names the alternative, leaving no ambiguity about when to choose this tool over others. The format examples also implicitly clarify when each output style is appropriate.

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

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

With no annotations present, the description carries the full behavioral burden. It states that the tool returns all relevant directives/regulations, lists the included data (reference types, article citations, primary-implementation flag), and implies a read-only lookup. It does not cover errors, pagination, or permission requirements, but for a simple GET-style tool the disclosed behavior 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 and front-loaded: the core purpose appears in the first sentence, return contents follow, and exclusions are placed at the end. Every sentence earns its place; the when-not-to-use section is particularly high-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?

For a low-complexity 3-parameter tool with no output schema and no annotations, the description covers the purpose, the return contents, the expected input (with schema example), and sibling alternatives. Nothing an agent needs to decide whether and how to invoke it 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 100%, so the schema already documents sfs_number, reference_types, and include_articles. The description mentions reference types and article citations in the return value, which loosely aligns with parameters, but it does not add new semantic detail about how to use them. 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 opens with a specific verb and resource: 'Get EU legal basis (directives and regulations) for a Finnish statute.' It then clarifies the exact return scope (directives/regulations the statute implements, supplements, or references), and differentiates from siblings by naming get_provision_eu_basis and get_finnish_implementations.

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?

An explicit 'When NOT to use' section names the two alternatives and the exact conditions for choosing them: provision-level references go to get_provision_eu_basis, and Finnish laws implementing EU law go to get_finnish_implementations. This gives an agent decisive routing 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool 'returns all Finnish statutes that implement, supplement, or reference it' and that it 'Shows implementation status and which articles are referenced,' giving concrete insight into the output. It does not mention side effects, auth, or rate limits, but as a read-only search tool this is acceptable. It adds value beyond the schema by describing the returned information.

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. It opens with the core purpose, provides an example, and then includes a 'When NOT to use' note that directs to a sibling. Every sentence earns its place, and there is no fluff or redundancy. The structure is front-loaded with the most important 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 having no output schema, the description explains what the tool returns (statutes with implementation status and referenced articles). It covers the direction of the query, the input format, and the alternative tool for the opposite case. The tool is simple enough that no additional context is needed for correct invocation.

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

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

Schema description coverage is 100%, so all three parameters are already documented. The description adds an example for eu_document_id ('regulation:2016/679') and implies the purpose of the boolean filters, but these are already present in the schema. The description does not materially enhance parameter understanding beyond the schema, so the baseline of 3 applies.

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: finding Finnish statutes that implement a specific EU directive or regulation. It provides a concrete example ('regulation:2016/679') and explicitly differentiates from the sibling tool get_eu_basis by noting the opposite direction. This makes the purpose unambiguous and distinguishable from siblings.

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

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

The description includes a 'When NOT to use' section that explicitly tells the agent to use get_eu_basis for the reverse direction. It also states the tool is 'Essential for finding Finnish law corresponding to EU requirements,' providing clear context on when to apply it. This is explicit guidance with no 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?

With no annotations, the description carries the full burden, and it does disclose key behavioral expectations: what the tool returns and its boundary (legislative intent, not current law). It does not mention failure modes or output format, but for a simple read-oriented lookup this is reasonably transparent.

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 organized and front-loads the core purpose before the not-to-use guidance. It is slightly repetitive, with both 'essential for understanding legislative intent' and the final sentence making the same point, but every sentence otherwise 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?

Given a single required parameter, no output schema, and no annotations, the description supplies the essential context: what the tool returns, why it is useful, and how it differs from the nearest sibling. Minor missing details like result formatting or error behavior do not undermine 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%, and the document_id parameter already includes explicit examples of accepted formats. The description adds only the contextual note that the statute is Finnish, so it provides no significant additional parameter semantics 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 identifies the specific operation (get preparatory works) and the resource (Finnish statute), and enumerates the concrete result types: government proposals, committee reports, and related documents with summaries. It also differentiates this tool from get_provision, making its purpose 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 explicitly states when to use the tool (understanding legislative intent) and when not to use it (when the statute text itself is needed), naming the alternative tool get_provision. This is clear, actionable routing 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that omitting chapter/section/provision_ref returns all provisions and gives reference format examples. However, it does not mention the as_of_date historical behavior in the description text (only in the schema), does not describe the return shape, and never explicitly states that the operation is read-only. Core behavior is transparent but with gaps.

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: purpose, parameter guidance, examples, default behavior, and when-not-to-use. The examples are valuable and not filler, and each sentence contributes. It is slightly longer than minimal, but the structure front-loads the main purpose and remains 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?

For a 5-parameter read tool with no output schema or annotations, the description covers selection logic and alternatives well. However, it does not describe what the returned provision looks like and does not mention as_of_date in the description, relying on the schema for that. An agent can call the tool confidently, but small informational gaps remain.

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 3. The description adds meaning beyond the schema by explaining parameter combinations (chapter+section OR provision_ref), providing concrete examples for each mode, and clarifying what happens when optional parameters are omitted. This materially helps an agent choose the correct inputs.

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 and resource: 'Retrieve a specific provision from a Finnish statute.' It also provides concrete examples and distinguishes itself from the sibling search_legislation by explaining that keyword searches should use that tool instead. This is clear and more than a tautology.

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 specifies the parameter combinations to use (document_id with either chapter+section or provision_ref) and the default behavior when parameters are omitted. It also includes a 'When NOT to use' clause directing keyword searches to search_legislation, giving clear, actionable 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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states that the tool returns the complete provision text, validity dates, and optionally the amendment history after the queried date. It also discloses support for historical, current, and future provisions. The description does not mention any side effects, but as a retrieval tool this is expected to be read-only. The main behavior is well-documented, though edge cases or error handling are not addressed.

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 purpose statement followed by use cases and a supports list. It front-loads the core functionality and then expands with examples and features. While it is somewhat longer than necessary, every section adds value and no sentences are redundant. The bullet points improve readability, making it effective despite its length.

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 there is no output schema, the description appropriately explains what the tool returns: complete provision text, validity dates, and optional amendment history. It also covers supported date scenarios and examples. However, it does not mention potential error conditions, limits, or how to handle invalid citations, but these are likely covered by sibling tools like validate_citation. For a retrieval tool with clear inputs and outputs, the description is fairly 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?

All four parameters have schema descriptions with examples and patterns, so schema coverage is 100%. The description adds minimal extra context—for instance, it mentions the default for include_amendments and gives an example of provision_ref, but these are already implied by the schema. The description does not significantly enhance parameter understanding beyond what the schema provides, so 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 clearly states the tool's core function: retrieving Finnish statute provision text as of a specific date, explicitly labeled a 'time-travel query.' It distinguishes itself from siblings like get_provision by the temporal dimension, making its unique value obvious. The resource (statute provision), verb (retrieve), and scope (as read on a date) are all 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 concrete use cases with examples (e.g., 'What did Tietosuojalaki 1:3 say in 2019?') that illustrate when to use the tool. It also explicitly lists supported scenarios: historical versions, current version, and future provisions. However, it does not explicitly name alternative tools like get_provision for current text or check_currency for currency checks, relying on inference from context. The guidance is clear but lacks explicit 'when not to use' 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?

With no annotations, the description carries full burden. It clearly states the return type (EU directives/regulations) and precision (article-level), and gives an example. It does not disclose edge cases like missing provisions or error behavior, but for a read-only retrieval tool, the main behavior is adequately disclosed. A minor gap is lack of mention of potential failures.

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

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

The description is concise, with clear structure: purpose, return, usage, and exclusion. Every sentence adds value, and the most important information is front-loaded. 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 two parameters and no output schema, the description explains what the tool returns and provides an example. It differentiates from the sibling tool. It does not detail the exact structure of the return or error handling, but for a focused retrieval tool, it is largely complete. A 4 reflects that it could be slightly richer on return format but is 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 the schema already describes both parameters. The description adds an example ('DSL 2:1 references GDPR Article 6.1.c') that illustrates how the provision_ref maps to the EU source, which is helpful beyond the schema. This slightly exceeds the baseline 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 states a specific verb and resource: 'Get EU legal basis for a specific provision within a Finnish statute.' It clearly distinguishes from sibling get_eu_basis by focusing on provision-level vs statute-level. The example further clarifies the 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?

Explicit guidance is provided: 'Use this for pinpoint EU compliance checks at the provision level.' It also states when NOT to use and names the alternative tool (get_eu_basis), leaving no 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?

No annotations are provided, so the description carries the behavioral burden. 'List' implies a read-only operation and the described output (sources with metadata) is clear. However, it does not state whether any side effects or external calls occur, or whether the returned list is cached or dynamic. This is a minor gap for such a simple 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 two sentences with no filler. The primary action and resource are front-loaded, and the usage hint is placed in the second sentence. Every word 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?

For a zero-parameter listing tool, the description is complete: it names the resource, explains the metadata categories returned, and gives an explicit use case. No output schema exists, but the description provides enough expectation-setting for an agent.

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

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

The tool has zero parameters, so the baseline is 4. The description adds useful information about what the returned metadata includes, which goes beyond the empty schema. No parameter-specific explanations are needed.

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 action (list), the resource (authoritative data sources used by this server), and the content (provider, license, coverage, freshness metadata). It is specific and informative, though it does not explicitly contrast with sibling tools like 'about' or 'search_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 explicit guidance: 'Call this to understand where the data comes from.' This tells the agent when to use it. It does not name alternatives or exclusions, but for a simple listing tool this is sufficient 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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains that it searches case summaries and keywords and that it only covers court decisions, which is useful scope clarification. However, it does not explicitly state that the operation is read-only, nor does it describe the return format (e.g., list of matching summaries). This is a moderate gap for a search tool without an output 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 and well-structured: it leads with the core purpose, follows with the filtering capabilities, and ends with the when-not-to-use guidance. Each sentence earns its place with 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 search tool with no output schema, the description should explicitly state what the tool returns (e.g., a list of case summaries) and any limitations. It does not, instead only implying that it searches summaries. It also doesn't mention whether results are paginated or what the limit parameter does beyond the schema. The description is adequate for basic usage but leaves some important details to inference.

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 all parameters are already documented. The description reiterates the court and date range filters but adds no new meaning beyond what the schema provides. It does not clarify parameter formats or provide additional context, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool searches Finnish court decisions (oikeustapaukset) and explicitly distinguishes itself from search_legislation by noting it covers only court decisions. The verb 'search' and resource 'court decisions' are specific, and the differentiation from the sibling tool is 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 when-not-to-use guidance, naming the alternative tool (search_legislation) and the condition (need for statute text). This is a clear, actionable usage directive that leaves no ambiguity about selection between siblings.

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 no annotations provided, the description carries the full burden. It discloses that it returns matching documents with counts of Finnish statutes referencing them, which is a key behavioral detail. It doesn't mention pagination or default limit, but that's covered in schema; a small gap is acceptable.

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 with the core purpose, followed by usage guidance and alternatives. Every sentence earns its place. It's structured effectively for quick scanning.

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 a filterable search with 7 optional parameters, no output schema, and no annotations. The description covers purpose, typical use, and alternatives, which is sufficient for an agent to decide when to call it. It doesn't detail return format but given all parameters are optional and schema covers them, this is reasonably complete.

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

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

Schema description coverage is 100%, so each parameter is already well-documented. The description adds minimal extra meaning beyond the schema, just that the search can be by 'keyword, type, year range, or community' which is a useful summary but not essential. 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 states a specific verb ('Search'), resource ('EU directives and regulations'), and scope ('with Finnish implementation information'). It clearly distinguishes from the sibling get_finnish_implementations by mentioning that this is for exploratory searches and returns counts of Finnish statutes.

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

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

The description gives explicit when-to-use guidance ('Use this for exploratory searches'), and explicitly states when NOT to use it and which alternative to use ('get_finnish_implementations for direct lookup'). This is excellent routing.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the search algorithm (FTS5 with BM25), supported query syntax (boolean operators, phrase search, prefix matching), and return contents (provisions, snippets, relevance scores, document metadata). It does not mention rate limits, pagination, or error behavior, but for a search tool the disclosed behavior is substantial and useful.

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

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

The description is well-structured and front-loaded: the core purpose is stated in the first sentence, followed by search capabilities, return values, and explicit exclusions. Every sentence earns its place, and the 'When NOT to use' section is a model of efficient guidance.

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 search tool with 5 parameters, 100% schema coverage, and no output schema, the description is nearly complete. It covers what the tool does, how the search works, what it returns, and when not to use it. The only minor gap is that it doesn't describe the structure of the returned metadata or snippets, but the absence of an output schema makes that a small omission.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds context about FTS5 syntax support and the as_of_date historical filter, but does not add significant meaning beyond what the schema provides. 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's function: searching Finnish statutes and regulations by keyword, with specific details about the search technology (FTS5, BM25), supported operators, and return values. It distinguishes itself from siblings by explicitly naming get_provision and build_legal_stance as alternatives for different use cases.

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

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

The description provides explicit 'When NOT to use' guidance, naming two sibling tools (get_provision and build_legal_stance) and the conditions that should route an agent to them. This is exactly the kind of decision support an agent needs to select the correct 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?

With no annotations, the description carries the full burden, and it delivers meaningful behavioral detail: it parses, checks document/provision existence, returns status warnings, and supports legacy formats. It does not specify exact return shape or invalid-input handling, but for a read-oriented validator the core behavior is clearly disclosed.

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 efficient: a one-sentence purpose, a clear behavior summary, a compact list of supported formats, and an explicit when-not-to-use section. Every part earns its place, and the key purpose is front-loaded.

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

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

The description covers the tool's purpose, behavior, supported formats, and sibling differentiation. Since there is no output schema, the main missing piece is a precise return contract or error behavior for invalid citations, but for a single-parameter validator this is a relatively minor gap.

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 says 'Citation string to validate,' but the description adds concrete supported formats such as 'Laki 1050/2018 1 luku 1 §', '1050/2018 1:1', and 'NJA 2020 s. 45.' This goes well beyond the schema and is essential for correct invocation.

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

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

The description states a specific verb and resource: 'Validate a Finnish legal citation against the database.' It clearly explains what validation entails—parsing, checking existence of document and provision, and returning warnings—and distinguishes itself from the sibling format_citation. An agent can immediately tell this tool's job from its siblings.

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

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

The description explicitly says when not to use the tool and names the alternative: 'If you want to format a citation string, use format_citation.' It also clarifies that this tool checks existence in the database. This gives an agent actionable routing guidance rather than leaving usage to inference.

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?

No annotations are provided, so the description carries the burden. It discloses the return values (compliance status with warnings and recommendations) and the Phase 1 limitation, which is useful. However, it doesn't disclose whether this is a read-only operation, whether it makes external calls, or what happens when the statute isn't found. The description adds some behavioral context but not comprehensive 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?

The description is well-structured with a clear opening sentence, a bulleted list of checks, return value summary, a phase note, and a 'When NOT to use' section. It's slightly longer than necessary but every section earns its place and the most important information is front-loaded.

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

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

For a tool with 3 parameters, 100% schema coverage, and no output schema, the description covers the purpose, scope, return values, and limitations. It could be more complete by mentioning error behavior or whether the tool is read-only, but given the schema covers parameters and the description covers the core behavior, it's reasonably complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context about what the tool checks (repealed directives, missing implementation status) which helps interpret the eu_document_id parameter, but it doesn't add significant meaning beyond the schema. 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 states a specific verb ('Validate') and resource ('EU compliance status for a Finnish statute or provision'), and lists concrete checks (repealed directives, missing implementation status, outdated references). It also distinguishes itself from the sibling get_eu_basis by explicitly saying it assesses compliance status rather than doing basic reference 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 says 'When NOT to use' and names the alternative tool (get_eu_basis) for basic EU reference lookup. It also clarifies this is Phase 1 validation, setting expectations about scope. This is strong guidance for an agent deciding between tools.

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