Server Quality Checklist

Tool Scores

• search_edpb_documentsC
  2.6/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds only 'through its public website', implying an external web call, which is mild context. It does not disclose return format, pagination, rate limits, or any observable behavior beyond the 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.

  Conciseness3/5

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

  The description is one sentence with no wasted words, so it is concise. However, it is under-specified for a tool with 6 parameters and multiple filters; conciseness turns into lack of substance. It earns its place but fails to cover essential details.

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

  Completeness1/5

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

  For a complex search tool with 6 parameters, 2 enums, and a 0% schema description coverage, this description is grossly incomplete. It does not mention available filters, expected output, or how results are structured (despite an output schema existing). An agent cannot call this tool correctly without further inspection.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It provides no information about the meaning of query, limit, status, document_type, date_from, or date_to. The agent must guess how to construct filters and which enums are appropriate. This is completely inadequate.

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

  Purpose5/5

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

  The description states a clear verb ('Search') and resource ('official EDPB document catalogue') and specifies it goes through the public website. It is easy to distinguish from similar siblings like search_edps_documents (different agency) and search_eu_law (broader EU law), so the agent can tell them apart.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives. It does not mention when to choose it over search_edps_documents or get_edpb_document, nor does it note any prerequisites or exclusions. The only implicit hint is the resource it searches.

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

• get_edpb_documentC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds a meaningful behavioral nuance: it preserves visible numbered paragraphs only 'where extractable', which implies extraction limitations. However, it doesn't discuss what happens when extraction fails, how the output is formatted (beyond the output schema), or any dependency on URL formats. Given annotation coverage, a 3 is appropriate.

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

  Conciseness5/5

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

  The description is a single, tight sentence that fronts the main verb and resource. It packs a specific detail (preserve numbered paragraphs where extractable) with no filler or repetition. Every word earns its place, making it optimally concise and well-structured.

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

  Completeness2/5

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

  Despite having an output schema and annotations that cover the operational profile, the description omits essential parameter information and fails to give any sense of what constitutes a valid identifier_or_url or language value. For a tool that retrieves documents, this is a substantial gap. The preservation caveat is nice but doesn't compensate for the missing param semantics or any mention of input constraints.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning the schema provides no descriptions for identifier_or_url or language. The tool description completely ignores both parameters—it doesn't explain what format identifier_or_url should take (e.g., a URL or a document ID) or what language codes are accepted. Since the schema gives zero guidance and the description adds none, the agent is left to guess parameter semantics. This is a serious deficiency.

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

  Purpose4/5

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

  The description states a specific verb ('Retrieve') and resource ('official EDPB PDF'), and adds a distinctive detail about preserving visible numbered paragraphs. This clearly distinguishes it from generic EU document retrievers, though it doesn't explicitly name sibling tools like get_eu_document or search_edpb_documents. That's a minor gap, keeping it from a 5.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus any of the many siblings (e.g., search_edpb_documents, get_article, get_recitals). It doesn't state prerequisites, conditions, or alternatives. The context signals show a rich sibling set, so a clear routing statement is warranted but absent.

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

• get_eu_caseC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the behavioral trait that paragraph numbering is preserved, which is useful for downstream tasks, but it does not disclose error handling, authentication requirements, or limitations. With annotations covering safety, this is adequate but not rich.

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

  Conciseness4/5

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

  The description is a single sentence with no filler, and it front-loads the action. It is efficient, though it omits necessary parameter guidance. The structure is good for the limited content it provides.

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

  Completeness2/5

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

  With 3 parameters (1 required), 0% schema coverage, and a large sibling set, the description is far too sparse. It does not explain how to supply the identifier, the role of document_type, or when this tool is preferable over its many siblings. Even though an output schema exists, the input guidance is missing.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain parameter semantics, but it gives none. It does not clarify what 'identifier' refers to (e.g., case number, CELEX number), what 'language' options are, or what the allowed values of 'document_type' mean. The description adds no value over the raw schema.

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

  Purpose4/5

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

  The description states a clear action ('Retrieve') and a specific resource ('an exact official EU court document'), and adds a distinctive feature ('source paragraph numbering preserved'). However, it does not differentiate from sibling tools like get_eu_document or get_case_paragraphs, which likely overlap in purpose.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives such as search_eu_cases or get_eu_document. There is no mention of context, prerequisites, or exclusion criteria, leaving the agent to guess which tool fits a given query.

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

• search_eu_casesB
  3.1/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral detail: query uses AND-of-tokens matching over titles, provision verifies direct citations and returns evidence, and interpreted_celex is instrument-level metadata. This goes 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.

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the primary purpose, then clarifies key parameter nuances. Every clause adds value, and there is no redundancy or filler. It is appropriately concise for the scope it covers.

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

  Completeness2/5

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

  With 12 parameters, no required fields, and a low schema description coverage, the description is insufficient for an agent to understand how to use the tool effectively. It covers only three parameters and omits details like date formats, court values, document types, and relationship between parameters. The presence of an output schema does not mitigate the input-side gaps.

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

  Parameters2/5

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

  The description explains the semantics of three parameters (query, provision, interpreted_celex), which adds clarity. However, schema_description_coverage is only 33%, and the description does not compensate for the other 8 parameters (ecli, celex, court, limit, date_to, date_from, language, case_number, document_type) that lack descriptions. This leaves significant ambiguity for agents constructing valid calls.

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

  Purpose4/5

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

  The description states a clear verb+resource: 'Search authoritative EU case law.' This unambiguously identifies the tool's core function. However, it does not differentiate from sibling tools such as search_eu_law, which likely overlaps in purpose, so it misses the opportunity to set it apart.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of search_eu_law or any other sibling, nor any conditions or exclusions. An agent is left to infer the context from the tool name alone.

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

• get_case_paragraphsB
  3.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the specific behavior 'Missing numbers return PARAGRAPH_NOT_FOUND', which is valuable beyond annotations. It does not mention other behavioral aspects, but given the annotation coverage, this is sufficient.

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

  Conciseness5/5

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

  Two sentences, zero fluff, and the primary purpose is front-loaded. The missing-number behavior is a valuable addition in the second sentence. Highly efficient and easy to parse.

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

  Completeness2/5

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

  With a complex input schema (anyOf array/range, required 'case' and 'paragraphs') and zero schema documentation, the description fails to guide the agent on how to format the 'paragraphs' argument or what 'case' and 'language' refer to. Although an output schema exists, the input side is underexplained for the tool's complexity.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain parameters. It hints at 'source-numbered paragraphs' and missing-number behavior, which relates to the 'paragraphs' parameter, but it does not explain 'case' or 'language' at all. The complex structure of 'paragraphs' (array or range) is not addressed. Compensation is incomplete.

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

  Purpose4/5

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

  The description states a clear verb ('Retrieve') and resource ('source-numbered paragraphs'), and adds the scope constraint 'only requested'. It is distinct from siblings like get_recitals, though it does not explicitly name an alternative. The purpose is unambiguous, but lacks explicit sibling differentiation.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus siblings like get_recitals or get_article. The phrase 'only requested' implies a selective use case, but there is no explicit context, prerequisite, or exclusion. The agent must infer the usage scenario.

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

• compare_document_versionsB
  3.3/5.0
  Behavior4/5

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

  The description adds real value beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false): it discloses determinism, whitespace/markup normalization behavior, and the explicit limitation that it does not characterize legal effect. No contradiction with annotations — returning computed differences is fully consistent with a read-only idempotent operation.

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

  Conciseness5/5

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

  A single well-constructed sentence with the main action front-loaded and the legal caveat appended. Every phrase earns its place — determinism, normalization, and scope — with zero filler or redundancy.

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

  Completeness3/5

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

  For a 5-parameter tool with zero schema coverage, the description is under-equipped: annotations cover the safety profile and the description covers determinism/normalization, but parameter semantics are left undocumented. The presence of an output schema lightens the return-value burden, yet the description still leaves an agent guessing about input meaning.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it only clarifies the output ('structural provision differences') and says nothing about what document, version_a, version_b, article, or language mean. The article and language parameters remain especially ambiguous (is article a filter? what language scope applies?), so the burden is unmet.

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

  Purpose4/5

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

  The description uses a specific verb ('Return') with a clear resource ('structural provision differences' between document versions) and adds a distinguishing qualifier about normalization and the legal-effect caveat. It clearly conveys what the tool does, but it does not explicitly name or differentiate from siblings such as list_document_versions or get_provision_at_date, so it falls short of a 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like get_provision_at_date, list_document_versions, or get_document_timeline. The 'does not characterize legal effect' clause is a behavioral limitation rather than usage routing. An agent gets no help deciding between this and related version-facing tools.

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

• get_document_timelineB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side effects. The description adds context about the specific event types returned, which is useful but not extensive. 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys the core function without any filler. Every word contributes value, and the structure is optimal for quick scanning.

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

  Completeness3/5

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

  The output schema is present, so return structure is covered. However, the description fails to clarify parameter usage and provides no usage guidelines. For a tool with only two parameters, this is moderately incomplete, especially given the 0% schema coverage for parameters.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning the description must compensate for parameter semantics. It doesn't mention the 'document' or 'language' parameters at all beyond their existence. There is no guidance on what format document identifiers should take or how language affects results. This is a significant gap given the lack of any schema documentation.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: returning original, corrigendum, amending-act, and consolidation events as distinct official resources. The verb 'return' and the resource 'document timeline' are specific. While it doesn't explicitly differentiate from siblings, the event types listed make its scope distinct from related tools like get_article or get_eu_document.

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

  Usage Guidelines3/5

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

  The description implies when to use it: when a timeline of official document events is needed. However, it provides no explicit guidance on when not to use it or which sibling tools might be preferable. Given the presence of many sibling tools with overlapping domains, this is a moderate gap.

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

• get_recitalsB
  3.3/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add context. It adds that recitals are 'selected' and 'source-numbered,' which clarifies the scope of retrieval, but does not describe error handling or version behavior. This adds some value but not rich behavioral context.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no wasted words, efficiently stating the tool's purpose. It is appropriately sized for the task.

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

  Completeness2/5

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

  While an output schema exists, the description leaves the input parameters ambiguous—what a 'document' is, how to specify 'version' options, and the meaning of 'language' are unexplained. For a tool with 4 parameters and no schema descriptions, this is insufficient for an agent to call it correctly without additional context.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only hints at 'selected' recitals but does not explain the format of the 'recitals' parameter, the meaning of 'document', or valid 'version' values. The description fails to add meaning beyond the schema's structural constraints.

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

  Purpose5/5

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

  The description states a specific verb ('retrieve') and resource ('selected, source-numbered recitals from an official EU legal text'), clearly distinguishing it from sibling tools like get_article or search_eu_law. It is unambiguous about what is returned and the source.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention search_eu_law for finding recitals or get_article for related articles, leaving the agent to infer usage from the tool name alone. No exclusions or contextual cues are given.

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

• list_document_versionsB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds a valuable behavioral detail: 'requested-language availability reported without substitution.' This tells the agent that language availability is reported but no fallback substitution occurs, which is beyond what annotations convey. This enriches the agent's understanding of output behavior.

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

  Conciseness5/5

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

  The description is a single sentence that is front-loaded with the core action and scope. It conveys the primary behavior and the key nuance about language without unnecessary filler. Every word earns its place, and it is appropriately concise for the tool's simplicity.

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

  Completeness3/5

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

  The tool has an output schema, so return format is covered structurally. However, with 0% parameter schema coverage and no parameter descriptions in the tool description, the agent lacks essential information about how to construct the request. The description is too terse to be considered complete for a tool that must handle language availability logic; it does not explain edge cases, error conditions, or input constraints beyond what the schema provides (which itself has minimal detail).

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions 'requested-language availability' which implies the language parameter, but it does not explain the format, allowed values, or meaning of the 'document' parameter. The description fails to provide any detail about how to specify the document or what constitutes a valid language code, leaving a significant gap for a tool with only two parameters.

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

  Purpose4/5

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

  The description clearly states the action (list) and the resource (original act and official consolidations), and adds the specific nuance of reporting requested-language availability without substitution. It is specific enough to distinguish from generic document retrieval, though it does not explicitly name sibling tools like get_document_timeline or compare_document_versions, so it doesn't fully differentiate itself in wording.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or references to sibling tools. While the purpose implies it is for listing versions, there is no explicit 'use this when X' or 'not for Y' guidance, leaving the agent to infer usage context.

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

• get_articleB
  3.4/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds beyond that: it specifies the structural exactness ('including numbered paragraphs and points') and the authoritative source ('official CELLAR XHTML'), which are not covered by annotations and are useful for callers.

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

  Conciseness4/5

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

  The description is a single, well-structured sentence with no filler. It front-loads the core purpose and adds key qualifiers. It is appropriately concise, though it could have incorporated parameter guidance without losing brevity.

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

  Completeness2/5

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

  With four parameters and no schema descriptions, the description must compensate but does not. It fails to clarify what each parameter represents (e.g., article numbering format, document identifier type, version options). Even though an output schema exists, the absence of parameter semantics makes the tool incomplete for reliable invocation.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description mentions none of the four parameters (document, article, version, language). It does not explain the expected format for article identifiers, version values, or language codes, leaving agents without sufficient guidance to construct valid calls.

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

  Purpose5/5

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

  The description uses a specific verb ('Retrieve') and resource ('one structurally exact article') with qualifiers ('including numbered paragraphs and points', 'from official CELLAR XHTML') that clearly distinguish it from siblings like search_eu_law or get_eu_document. It leaves no ambiguity about what is returned.

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

  Usage Guidelines3/5

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

  The description implies usage—retrieving a single exact article—but does not explicitly state when to choose this over alternatives like search_eu_law or get_provision_at_date. It provides no exclusions or explicit context, though the phrasing implies a distinct purpose.

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

• search_edps_documentsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the data source (CELLAR) and the coverage limitation, which is useful behavioral context, but it does not describe return format, pagination, or other traits. With annotations carrying the safety burden, a score of 3 is appropriate.

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

  Conciseness5/5

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

  Two short, front-loaded sentences with zero fluff. The primary purpose is stated first, and the scoping constraint follows immediately. There is no redundant information or padding.

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

  Completeness2/5

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

  Although the tool has an output schema (so return values are documented elsewhere) and annotations cover safety, the description is incomplete for a search tool with five parameters. It does not explain query syntax, date formatting, or the meaning of 'document_type'. An agent seeking to call this tool correctly would need to infer parameter usage from names alone, which is not sufficient for a complex, parameterized search.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention any of the five parameters (query, limit, date_to, date_from, document_type) or their intended semantics. While property names like 'query' and 'limit' are self-explanatory, the description adds no value beyond the schema, and the schema itself lacks descriptions for fields like 'document_type' and the date range semantics. This is a significant gap.

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

  Purpose5/5

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

  The description states a specific verb ('search'), a precise resource ('official Publications Office CELLAR metadata'), and a clear scope ('EDPS publications'). This distinguishes it from the closely related sibling 'search_edpb_documents' by naming a different entity (EDPS vs. EDPB), so an agent can tell them apart without inspecting schemas.

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

  Usage Guidelines3/5

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

  The description gives a usage condition — coverage is limited to EDPS material deposited in CELLAR — which implies when to use it (when EDPS publications are needed). However, it does not explicitly mention alternative tools or state when NOT to use it, leaving some inference required.

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

• search_eu_lawA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds that it returns metadata and provenance, which is useful behavioral context. It does not contradict annotations and provides a clear expectation of what the tool does not do (legal conclusions).

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the core purpose and scoping. No filler words or redundant information. It earns its space efficiently.

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

  Completeness2/5

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

  Despite having an output schema, the tool has 7 parameters including dates, filters, and language, none of which are explained in the description or schema. An agent would not know how to construct an effective query, what date formats to use, or how to restrict results. This is incomplete for a search tool with multiple filter options.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning parameters lack descriptions. The tool description does not mention any of the seven parameters (query, limit, date_from, etc.), leaving the agent to infer their meaning solely from names and types. This is a significant gap; the description fails to compensate for the missing schema details.

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

  Purpose5/5

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

  The description clearly states the tool searches authoritative CELLAR metadata for EU legislation and legal acts, and explicitly notes it returns metadata and provenance, not legal conclusions. This distinguishes it from legal analysis tools. Even without naming siblings, it is precise about the resource and scope.

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

  Usage Guidelines3/5

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

  The description implies this tool is for metadata retrieval rather than legal conclusions, which subtly guides away from using it for substantive legal analysis. However, it does not explicitly compare with sibling search tools like search_eu_cases, nor mention when to avoid it. Usage context is present but not fully developed.

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

• get_eu_documentA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the notion of 'exact official language/version' but does not elaborate on behavior such as default parameters or error handling. Since annotations carry the burden, score 3 is appropriate—the description adds minimal extra behavioral context.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no waste. It efficiently conveys the core action and object. However, it is so terse that it skips necessary usage details, but for conciseness and structure itself, it is well-organized. A 4 acknowledges its efficiency while flagging that brevity reduces completeness.

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

  Completeness2/5

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

  Despite having an output schema and rich annotations, the description fails to explain how to construct the identifier, what defaults apply for language/version, or any edge-case behavior. An agent cannot confidently call this tool correctly without additional context. The tool is moderately complex (3 parameters, version constraints), and the description offers only a high-level intent, making it incomplete for real-world use.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It hints that language and version play a role in selecting the exact document, but it omits details about identifier format (e.g., CELEX number) and allowed version values. The schema provides constraints (original/current_consolidated/date) but no narrative, and the description does not fill that gap, leaving the agent uncertain about how to populate parameters.

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

  Purpose5/5

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

  The description states a clear verb ('Retrieve'), a specific resource ('an exact official language/version of an EU legal act'), and the method ('by deterministic identifier'). This distinguishes it from search or article-level tools, and the phrase 'exact official language/version' conveys precision beyond generic retrieval.

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

  Usage Guidelines4/5

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

  The description implies the tool is used when you have a deterministic identifier, which differentiates it from search tools. However, it does not explicitly name alternatives or state when not to use it. The condition 'by deterministic identifier' gives clear context but no exclusions, so it's slightly above mediocre.

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

• find_cases_citingA
  3.7/5.0
  Behavior4/5

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

  Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds context beyond those: it reveals the data source (CELLAR), the relationship type (work_cites_work), and the guarantee that results are based on authoritative citations, not keyword co-occurrence. This enriches the agent's understanding of how the tool behaves without contradicting the annotations. It does not, however, describe output format or pagination, but that is partially covered by the 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.

  Conciseness5/5

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

  The description is a single sentence that front-loads the tool's core purpose ('Find citing judgments') and immediately adds distinguishing context. It contains no filler, does not repeat annotations, and every clause adds value: the mechanism ('authoritative CELLAR work_cites_work relationships') and the exclusion ('never keyword co-occurrence'). This is an exemplary concise structure.

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

  Completeness2/5

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

  Despite having an output schema, the description is insufficient for a tool with 6 parameters and only 1 required. It fails to explain how to specify the target case (identifier format?), what the court filter enumerates, how date limits behave, or what the limit parameter controls (likely max results, but not stated). The description gives no usage context on prerequisites or result filtering. An agent cannot reliably construct a correct request without additional knowledge, making the definition incomplete for practical use.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description provides no explanations for any of the 6 parameters: case, court, limit, date_to, date_from, language. While parameter names hint at their purposes, an agent does not know what format 'case' should take (e.g., ECLI, case number), what 'court' restricts, or how date filters apply. With zero coverage, the description was expected to compensate, but it stays entirely at the purpose level, leaving all parameter semantics undefined.

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

  Purpose5/5

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

  The description clearly states the verb (find), the resource (citing judgments), and specifies the mechanism ('authoritative CELLAR work_cites_work relationships'). It immediately distinguishes itself from keyword-based searches by adding 'never keyword co-occurrence', which sets it apart from sibling tools like search_eu_cases. The purpose is unambiguous and easily understood by an agent.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool: when you need formal citation relationships rather than keyword matches. The phrase 'never keyword co-occurrence' signals that this is not for keyword search, hinting at an alternative. However, it does not explicitly name the alternative tool (e.g., search_eu_cases) or provide explicit conditions like 'use this when you have a specific case identifier to find citing judgments'. The guidance is clear but not fully explicit.

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

• get_provision_at_dateA
  3.7/5.0
  Behavior4/5

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

  With annotations already declaring readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, the description adds valuable context: the notion of a 'safe official snapshot' and the explicit statement that 'legal effect is not inferred'. These are meaningful behavioral disclosures beyond the annotations. No contradiction exists.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action and immediately adds the legal-effect caveat. Every word adds value; there is no redundancy or fluff. It is appropriately brief while conveying essential information.

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

  Completeness2/5

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

  Despite having an output schema, the input semantics are inadequately defined. The description does not clarify what constitutes a 'safe official snapshot', how to identify a 'document', or the acceptable form of an 'article'. An agent would likely struggle to construct correct parameters, particularly with multiple sibling tools and no schema descriptions. The tool's complexity and legal context demand more explanatory detail.

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

  Parameters2/5

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

  The schema has 0% description coverage, so the description must compensate. However, it does not explain what 'document', 'article', or 'language' mean, nor their formats beyond the schema's pattern. The words 'article' and 'date' appear but without elaboration on how to construct valid values. This is a significant gap for an agent needing to fill parameters correctly.

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

  Purpose5/5

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

  The description states a clear, specific verb ('Return'), a precise resource ('exact article from the latest safe official snapshot on or before a date'), and adds a key scoping nuance ('legal effect is not inferred'). This distinguishes it from siblings like get_article or get_document_timeline, providing a strong operational definition.

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

  Usage Guidelines3/5

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

  The description implies a usage scenario (historical article retrieval) but does not explicitly contrast with alternative tools like get_article or list_document_versions. It does not state when not to use this tool or reference specific sibling tools. The temporal constraint is clear, but exclusion guidance is absent, leaving the agent to infer when this is the correct choice.

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

• verify_legal_quoteA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds valuable behavioral context by stating the return values (exact_match, normalized_match, no_match) and the single-anchor limitation, which goes 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.

  Conciseness5/5

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

  The description is a single, tight sentence that front-loads the verb and scope and immediately communicates the output. Every word earns its place; there is no fluff or redundancy.

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

  Completeness3/5

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

  The tool is conceptually simple, and the output schema exists (though not shown) and annotations are rich, lowering the bar. The description covers the purpose and return values, but the unresolved parameter semantics (especially evidence_id vs anchor_id) leaves an agent with incomplete knowledge to call the tool correctly. A brief explanation of the parameters would make it fully complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It mentions 'quote' and 'stored evidence anchor' but does not clarify the distinction between anchor_id and evidence_id, nor does it explain their formats or relationships. This is a significant gap that could lead to incorrect parameter values.

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

  Purpose5/5

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

  The description states a specific verb ('Compare') and a precise resource ('a quote' against 'one stored evidence anchor'), and explicitly qualifies the scope with 'only'. This clearly distinguishes the verification tool from sibling retrieval tools like search_eu_law or get_document_timeline, which are for fetching data, not matching.

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

  Usage Guidelines4/5

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

  The description clearly conveys the tool's singular purpose and its constraint to a single anchor, which implies its place among alternatives. However, it does not explicitly name alternatives or state when not to use it. The 'only' phrase gives a strong contextual hint but lacks explicit exclusions or sibling references.

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