conformi-search

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

Disclosures beyond annotations: 'pre-generated' (no dynamic creation), 'no API key required', and disclaimers (not legal advice). Complements readOnlyHint=true and destructiveHint=false effectively with no contradiction.

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

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

Two concise sentences covering all key aspects: purpose, free, no API key, research tool, citations, disclaimer. No fluff.

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

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

Describes output as a knowledge report with legal-status metadata and primary-source citations, which is sufficient given no output schema. Could mention pagination or format but not essential for a simple single-input tool.

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

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

Schema covers celex with full description and pattern. Description adds example (AI Act) and context (one EU legal act). While not adding syntactic meaning, it clarifies purpose of the 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?

Clearly states it retrieves a pre-generated knowledge report for a specific EU legal act via CELEX number. Includes unique features (free, no API key) and differentiates from siblings (timeline, search) by being pre-generated and report-focused.

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?

Mentions it's free and a research tool with disclaimers, implying appropriate use. However, no explicit guidance on when to use vs siblings (e.g., timeline or search). Context is clear but lacks exclusion statements.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description goes beyond by noting it is free, no API key required, and that it provides primary-source citations (CELEX/EUR-Lex) with a disclaimer that it is not legal advice. This adds valuable behavioral context beyond annotations.

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

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

The description is two sentences: the first clearly states the tool's function, and the second adds important context (free, citations, disclaimer). It is concise, front-loaded, and every sentence adds value.

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

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

Given the tool's simplicity (single parameter with full schema coverage, annotations, and no output schema), the description covers purpose, usage context, and behavioral aspects effectively. It is complete enough for an agent to select and use the tool correctly.

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

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

The input schema covers 100% of parameters with a clear description of the 'celex' parameter. The tool description does not add any additional parameter-specific meaning beyond what the schema already 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 identifies the tool's purpose: generating application-date timelines for major EU acts with staggered obligations. It specifies the resource (EU act), verb (get timeline), and scope (e.g., AI Act), and it implicitly distinguishes from siblings like search_eu_law or get_knowledge_article by focusing on timeline generation.

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 indicates the tool is free and no API key is required, but it does not explicitly state when to use this tool versus its siblings (get_knowledge_article, search_eu_law). There is no guidance on when not to use it or alternatives, leaving some ambiguity for the agent.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds value by disclosing metering per query and the nature of results (CELEX citations, not legal advice). No contradictions.

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

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

Two sentences, each serving a purpose: first explains core functionality, second adds critical caveats (metering, disclaimer). No extraneous words.

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

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

Covers purpose, language support, metering, and disclaimers. Lacks output format details (e.g., structure of results), but given no output schema, some guidance would be beneficial. Still, adequate for a search tool with annotations providing safety context.

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

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

Schema description coverage is 75% (3 of 4 parameters described). The description does not add further parameter-level detail beyond what the schema provides. Baseline 3 is appropriate since coverage is high but no extra value from description.

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

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

The description clearly states a specific verb and resource: 'Semantic search across the EU secondary-law corpus (DE/EN/FR)'. It distinguishes from siblings 'get_knowledge_article' and 'get_legal_timeline' by focusing on search with CELEX citations, not single article retrieval.

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

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

Provides context for when to use: for searching EU secondary law via semantic queries. Mentions metering and disclaims legal advice, but does not explicitly contrast with alternatives. Still, the purpose is clear enough for an agent to select appropriately.

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