Legal Data Hunter

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

No annotations provided, so description carries full burden. It effectively discloses return structure by enumerating specific fields (ISO codes, case law/legislation/doctrine source counts, total document counts), compensating for missing output schema. Does not mention side effects or rate limits, but sufficiently describes the data contract.

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 total with zero waste. Front-loaded with purpose statement, followed by return value specification and usage guideline. Every clause contributes necessary 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?

For a zero-parameter discovery tool with no output schema, the description fully specifies the resource domain (countries), the payload structure (ISO codes and counts), and the operational context (pre-search validation). No gaps remain for the agent to select or invoke this tool.

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

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

Zero parameters exist (empty properties object), which per rules establishes a baseline of 4. Description correctly requires no parameter explanation.

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?

Clear specific verb ('List') + resource ('countries') + scope ('with their document counts and source counts'). Explicitly states return format includes 'ISO 2-letter' codes, distinguishing it as a metadata/discovery tool rather than a search tool.

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

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

Contains explicit workflow guidance: 'Use this to find valid country codes before searching.' This establishes the temporal relationship to the sibling 'search' tool. Lacks explicit 'when not to use' exclusions, but the context is clear.

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 full burden and successfully discloses the return structure (source IDs, data types, court names, tiers, document counts, date ranges). However, it omits mutation safety (implied read-only by 'List' but not stated), error behaviors (e.g., invalid country codes), or operational traits like caching/rate limits.

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

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

Well-structured with clear information hierarchy: purpose → return values → usage guidance → parameter details. Every sentence earns its place. The Args section is necessary given the zero schema coverage, preventing this from being a 5 (ideally schema would self-document).

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

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

For a simple single-parameter discovery tool without output schema, the description adequately covers inputs (via Args) and outputs (via return value description). Minor gap: no mention of error handling for invalid country codes or whether the tool requires specific permissions.

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?

Outstanding compensation for 0% schema coverage. The Args section provides the critical ISO 2-letter format specification and concrete examples ('FR', 'DE', 'EU') that the JSON schema completely lacks. This adds essential semantic meaning beyond the bare 'string' type in the schema.

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

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

Excellent purpose statement with specific verb 'List', clear resource 'data sources', and scope 'for a specific country'. The second sentence distinguishes it by detailing the specific return fields (source IDs, court names, tiers, etc.), clearly positioning it as a discovery/directory tool rather than a search tool.

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

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

Provides explicit temporal guidance: 'Use this to understand what data is available before filtering your search.' This clearly indicates it should be used as a precursor to searching. Would be perfect if it explicitly named the sibling tool (e.g., 'search') to use afterward, but the guidance is clear enough to infer the workflow.

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 adds valuable context by describing the return payload ('complete text, metadata, and all available fields') since no output schema exists. However, it omits other critical behavioral traits: error handling (e.g., 404 if source_id invalid), rate limits, caching behavior, or whether the operation is idempotent/safe.

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 follows a logical, front-loaded structure: action (retrieve), output (returns...), workflow (use values from...), and parameter specifications (Args). There is minor redundancy between 'Retrieve a full legal document' and 'Returns the complete text,' but overall it is appropriately sized with no extraneous filler.

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

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

Given the zero schema coverage and lack of output schema, the description is adequately complete. It documents both parameters, describes the return structure, and provides workflow context (dependency on search results). It could be improved by noting error conditions or authentication requirements, but it covers the essential information needed for successful 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 0% (neither parameter has a description in the JSON schema), so the description fully compensates. It provides clear semantics for both: 'source' includes concrete examples ('FR/Judilibre', 'DE/BVerfG') showing the expected format, and 'source_id' is defined as 'Document identifier within the source.' This sufficiently documents the two parameters.

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 ('Retrieve') and resource ('full legal document'), clearly stating the tool's function. It implicitly distinguishes from the sibling 'search' tool by instructing users to 'Use source and source_id values from search results,' establishing a clear retrieval-vs-discovery relationship without explicitly naming the alternative.

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

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

Explicitly states the prerequisite workflow: 'Use source and source_id values from search results.' This guides the agent to use the 'search' tool first and then feed those specific identifiers into this tool. While it doesn't explicitly state negative constraints (when NOT to use), the dependency on search results provides sufficient context for correct invocation sequencing.

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 disclosure burden. It effectively describes what gets returned (distinct filter values across multiple categories), acting as a proxy for the missing output schema. However, it lacks details on idempotency, caching behavior, rate limits, or error conditions (e.g., invalid source).

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

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

The description is appropriately compact with a clear front-loaded purpose statement. The structure separates the return value description from the parameter documentation. The 'Args:' formatting is slightly informal but efficient. No sentences appear redundant or wasteful.

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

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

For a single-parameter tool, coverage is adequate but incomplete. It provides examples for the parameter and lists return categories, but fails to mention that valid source identifiers can be discovered via 'discover_sources'—a critical missing link for the user workflow. Without an output schema, the return structure could also be better characterized.

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

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

The schema has 0% description coverage (only a title 'Source'). The description compensates by providing the Args section with critical semantic context: 'Source identifier' and concrete examples ('FR/Judilibre', 'AT/RIS'), clarifying the expected format of the identifier.

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

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

The description clearly states the tool retrieves 'available filter values for a specific data source' and lists the specific categories returned (courts, jurisdictions, etc.). However, it does not explicitly differentiate from sibling 'discover_sources' which could confuse the relationship between listing sources vs getting filters for a source.

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

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

The description implies usage context by stating the filters 'can be used to filter search results', suggesting a relationship with the 'search' sibling. However, it lacks explicit workflow guidance such as 'call this before search to obtain valid filter values' or contraindications for when not to use it.

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

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

Lacking annotations, the description carries the full burden. It adds value by stating 'Reports are reviewed by the platform maintainer,' explaining the post-submission workflow. However, it omits mutation details, return values, or side effects that annotations would typically cover.

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?

Well-structured with purpose first, then usage guidelines, behavioral note, and parameter details. Each sentence earns its place. The 'Args:' section is slightly verbose but clearly organized and appropriate for the zero-coverage schema.

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

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

Given 3 simple parameters, no output schema, and no annotations, the description covers essential operational context. Could improve by noting expected return value (e.g., confirmation ID) given the absence of an output schema, but sufficient for the tool's complexity.

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

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

With 0% schema description coverage, the description fully compensates by documenting all 3 parameters: 'source' includes format examples ('FR/Judilibre'), 'issue_type' enumerates allowed values, and 'description' explains free-text purpose. Essential semantic information missing from schema is provided.

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

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

Description states specific action ('Report') and resource ('issue with a data source'), clearly distinguishing from retrieval siblings like 'get_document' and 'search'. The opening sentence is precise and immediately actionable.

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?

Lists specific trigger scenarios ('missing data, broken URLs, indexing errors, or data quality issues') and context ('during research'). Implies when to use versus normal data retrieval, though does not explicitly name alternatives.

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 provided, so description carries full burden. Discloses that it returns exact record(s) and supports multiple identifier formats. Missing disclosure on error behavior (no match found?), ambiguity handling (multiple matches?), destructiveness, or authentication requirements.

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?

Well-structured with purpose first, examples second, sibling distinction third, supported formats fourth, and Args section last. Every sentence earns its place; no boilerplate. Front-loaded with the critical 'NOT a search' distinction early.

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?

Mentions it 'finds and returns the matching document(s)' but lacks output schema and provides no details on return structure (IDs vs full documents?), pagination for multiple matches, or error response format. Given 0% schema coverage and no annotations, more behavioral context is needed.

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?

Fully compensates for 0% schema description coverage. Defines all three parameters in the Args block with types ('Legal reference string', 'Optional ISO country code'), constraints, examples ('FR', 'ECLI:FR:CCASS:2006:CO00559'), and allowed values ('legislation' or 'case_law').

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

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

Description opens with specific verb+resource ('Resolve a loose legal reference to the exact document(s)') and immediately distinguishes from the sibling 'search' tool by stating 'This is NOT a search — it resolves a specific citation to the exact record.' Lists concrete examples (art. 6 code civil, BVerfG, CELEX) that clarify 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?

Clearly contrasts its purpose against searching via 'This is NOT a search' given the sibling 'search' tool exists. Provides multiple input examples showing citation formats. Does not explicitly name the sibling 'search' as the alternative for general queries, though the distinction is clear from 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?

No annotations provided, so description carries full burden. Adds valuable context about search methodology (alpha weighting explanation) and corpus scope. However, omits operational details like rate limits, result ranking logic, caching behavior, or what happens when no results match—critical gaps for a complex search 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?

Excellent structure: purpose statement → scope → usage guidance → parameter reference. Every sentence carries load (scope establishes coverage, namespace line provides enums, discover_countries line provides workflow). Appropriate length given 11 undocumented parameters.

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, description fails to specify return format (document IDs? snippets? scores? full text?), which is essential for a search tool. Strong on inputs (compensating for poor schema), but incomplete regarding outputs and error handling (e.g., invalid country codes).

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 has 0% description coverage (only titles), but the description compensates perfectly with an 'Args:' block documenting all 11 parameters including types, ranges (e.g., '1-100' for top_k), formats (e.g., 'YYYY-MM-DD'), and examples (e.g., 'DE-BY' for subdivision). Fully bridges the schema documentation gap.

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

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

Description opens with specific verb+resource ('Search legal documents') and methodology ('hybrid semantic + keyword matching'). Scope clarification ('18M+ documents: case law, legislation, and doctrine across 110+ countries') clearly distinguishes this from sibling get_document (retrieval) and discover_* tools (metadata).

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

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

Explicitly directs users to 'Use discover_countries first if you're unsure which country codes are available,' establishing a clear prerequisite workflow. Also documents valid namespace values ('case_law', 'legislation', or 'doctrine'). Lacks explicit contrast with get_document for ID-based retrieval, preventing a 5.

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