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 only says the tool analyzes cherry-picking and returns a CherryPickingAnalysis dict; it does not reveal how the time series is processed, how dates are interpreted, whether the claimed variation is recalculated, or any edge cases.

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 well-structured, leading with the purpose and then listing parameters and return type. It avoids unnecessary prose, though some parameter descriptions are slightly redundant with the parameter names.

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 five required parameters, nested objects, and no annotations, the description is not complete enough for an agent to invoke the tool confidently. The return value is mentioned only as a dict, and input formats for dates and time_series are not specified. The existence of an output schema helps, but input construction remains underspecified.

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%, so the description must compensate. It does add basic meaning for each parameter, including the allowed values for claimed_direction ('hausse', 'baisse', 'stable') and the role of claimed_variation. However, it omits critical format details such as date string formats and the expected structure of the TimeSeries object.

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 clear, specific verb and resource: 'Analyze whether a claimed time-period variation is cherry-picked.' This is enough to distinguish it from general data retrieval siblings like eurostat_get_data or compare_values, though it does not explicitly name or contrast those alternatives.

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?

There is no guidance on when to use this tool versus siblings such as compare_values or score_check_worthiness. The description states what the tool does but gives no context about the expected analytical workflow or when cherry-picking analysis 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?

No annotations are present, so the description carries the full behavioral disclosure burden. It states that deviations are qualified and that a ComparisonResult is returned, but it does not explain how qualification is determined, what deviation metrics are produced, or any edge-case behavior such as missing values or mismatched periods.

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

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

The description is compact and front-loaded with the core purpose, followed by an Args section and a Returns line. Each section adds value without excessive verbosity, though the Args definitions could have been tighter by combining parameter semantics with format details.

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 all four parameters and notes the return type, and an output schema exists. Still, it lacks context about period formatting, required unit alignment, qualification thresholds, and how the tool behaves when inputs are invalid or incomplete.

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 has 0% description coverage, but the Args block provides meaningful semantic definitions for all four parameters, distinguishing claimed vs. actual values and periods. This compensates well, though it omits expected formats or units for period strings and numeric values.

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 operation: compare a claimed value to actual data and qualify the deviation. This clearly identifies the tool's function and distinguishes it from the data-retrieval siblings, though it does not explicitly differentiate it from analysis tools like analyze_cherry_picking.

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?

No usage guidance is provided. The description does not say when to use this tool versus alternatives, how it fits into a fact-checking workflow, or what prerequisites or exclusions apply. The purpose implies a use case, but no explicit when/when-not guidance is given.

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 burden and does disclose the return shape: a list of TimeSeries, one per requested country, plus optional year and filter arguments. It does not mention API errors, units, time-range behavior, or how filters map to Eurostat query parameters.

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 docstring is organized into Args and Returns with a one-line summary up front; every section is informative. It is not overly verbose, though the parameter list is a conventional format rather than the tightest possible prose.

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 all four parameters and the return shape, and an output schema exists so the return contract is further specified. However, it omits selection context among siblings and behavioral caveats, leaving an agent without enough cues for when to call it instead of related tools.

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% and the schema only provides types, but the description supplies concrete examples for dataset_code ('nama_10_gdp') and geo (['FR', 'DE']), and clarifies time_period as an optional year filter. The filters parameter remains vague ('additional filters dict'), which prevents a 5.

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: 'Retrieve Eurostat data' and adds a distinctive output shape ('convert to TimeSeries per country'), making the core purpose clear. It does not explicitly contrast with siblings like eurostat_search_datasets or eurostat_get_dataset_structure, so it stops 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.

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

No guidance is given on when to choose this tool over nearby siblings such as eurostat_search_datasets, eurostat_get_dataset_structure, or eurostat_get_ranking. The docstring explains how to call it, but not the conditions that should trigger this tool versus 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it stays mostly at surface level. It discloses what the tool returns (a Dict of dimensions to value lists), which is useful, but it does not describe potential failure modes (e.g., what happens with an invalid dataset_code), network/API behavior, pagination, rate limits, or whether the call is safe/idempotent. For a read-only metadata lookup, this is acceptable but not thorough.

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: first sentence states the action and resource, followed by an Args section and a Returns section. Every sentence serves a purpose and there is no filler. The Docstring-style format is clean and immediately scannable for an agent.

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 an output schema, the return type is partly covered by the schema, but the description also adds the return shape. The tool is a simple 1-parameter getter, so it does not need extensive context. However, it lacks information about error handling (e.g., what happens for an unknown dataset_code) and does not give example codes, which would make the tool fully self-contained.

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 0%, so the description must compensate for the fact that 'dataset_code' is only defined as a string in the schema. The description does state 'Eurostat dataset code' and its use in the Args section, which adds minimal meaning beyond the schema but the description is still thin. It doesn't provide examples of valid codes or format guidance, so a new agent would still be uncertain what to pass. The description adds a little value but does not fully compensate for 0% schema coverage.

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 ('Get') and resource ('dimension info for a Eurostat dataset'), clearly distinguishing it from siblings like insee_get_data or insee_get_indicator_metadata, which are different statistical agencies and operations. The mention of return value ('Dict mapping dimension names to lists of possible values') adds clarity. However, it does not explicitly name sibling tools for differentiation, and the purpose could be slightly sharper about what 'dimension info' means in Eurostat terms.

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 this is the tool to use when an agent needs to know the dimensions (and their allowed values) of a Eurostat dataset before making a data request. There is no explicit when-to-use/when-not-to-use guidance or mention of alternatives (e.g., insee_get_indicator_metadata for INSEE). The context is clear enough for a knowledgeable agent, but lacks explicit routing instructions to distinguish it from 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?

No annotations are provided, so the description carries the full burden. It discloses meaningful behavioral details: results are sorted by value descending, year=None uses the most recent available year, and geo_scope is ignored in the basic implementation. It does not mention side effects or error behavior, but for a read-only ranking tool the disclosed details are substantive.

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

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

The description is a clean, front-loaded docstring with a one-line summary and structured Args/Returns sections. It is slightly longer than necessary, but every section contributes useful 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 tool with four parameters, no annotations, and an existing output schema, the description covers the essential invocation details: defaults, sort order, and an unused parameter. It does not explain how to discover valid dataset_code or metric values, but sibling tools like eurostat_search_datasets can fill that 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?

Input schema description coverage is 0%, yet the description documents all four parameters in the Args section. It clarifies what dataset_code and metric mean, explains the year default behavior, and warns that geo_scope is unused, adding critical meaning beyond the raw schema.

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

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

The description starts with a specific verb and resource: 'Rank countries by a Eurostat indicator value.' This clearly distinguishes the tool from siblings like eurostat_get_data or worldbank_get_country_ranking, whose scope is different.

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 first sentence implies the tool should be used when a ranking of countries by a Eurostat indicator is needed, but it never explicitly states alternatives or when-not-to-use conditions. The geo_scope 'unused in basic implementation' caveat adds some guidance, but no routing against sibling tools is given.

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 must carry the behavioral disclosure load. It states that the tool searches by keyword and returns a list of dicts with code, title, and last_update fields, which clarifies the basic outcome. However, it does not disclose edge behaviors such as matching rules, pagination, errors, or whether the operation is read-only, leaving some behavioral ambiguity.

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

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

The description is compact and front-loaded with the main purpose, then provides an efficient Args/Returns structure. Every line adds information, and there is no fluff or repetition of schema data beyond what is necessary.

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

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

For a simple two-parameter search tool, the description supplies enough operational detail: purpose, parameter meanings, and return shape, while the optional limit default is in the schema. It lacks only the sibling-routing context that would make selection fully unambiguous, but nothing needed to invoke the tool 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 0%, yet the description's Args section fully compensates by defining query as 'Search keyword' and limit as 'Maximum number of results to return.' Both parameters receive meaningful semantics beyond the bare type/default information 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?

The description opens with 'Search Eurostat datasets by keyword,' naming a specific verb and resource, which makes the core purpose immediately clear. It does not explicitly differentiate itself from sibling tools like eurostat_get_dataset_structure or eurostat_get_data, though the search-versus-retrieval distinction is implied by the wording.

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?

There is no guidance on when to choose this tool over alternatives such as eurostat_get_data, eurostat_get_ranking, or eurostat_get_dataset_structure. The description only implies use for keyword-based dataset discovery and provides no exclusions or selection criteria.

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 disclosure burden. It does state that this is a read ('Get') and that it returns a TimeSeries, and it discloses inclusive period filtering. It does not mention idbank format requirements, ordering, pagination, or error behavior, but for a simple read tool the basic behavior is covered.

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, front-loaded with the core purpose, and uses a clean Args/Returns structure. Each line adds semantic value and there is no 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 simple tool with one required parameter and three optional filters, the description covers the inputs and the return type. It is complete enough for an agent to call correctly, though it could optionally point to insee_search_indicators for finding an idbank.

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%, so the description must carry parameter meaning and does: idbank is the INSEE IDBANK identifier, start/end period are inclusive optional filters, and last_n limits to the last N observations. This adds meaning beyond the raw types in the schema, though it omits period format details.

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

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

The opening line names the verb ('Get'), the resource ('time series data'), and the domain ('INSEE indicator'), so the tool's purpose is immediately clear. The mention of 'time series data' distinguishes it from sibling metadata/search tools, though it does not explicitly name an 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?

The description implies usage: provide an idbank to retrieve time series, optionally filtered by period or limited to last N observations. It does not state when to prefer this tool over insee_get_indicator_metadata or insee_search_indicators, nor does it mention any prerequisites.

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. It conveys that this is a read-style metadata operation and that it returns an IndicatorMetadata object, which is useful. It does not disclose error behavior, idbank validity requirements, or any rate limits, but for a simple metadata getter this is acceptable rather than severely lacking.

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 well-structured: a clear purpose sentence followed by short Args and Returns lines. Every sentence earns its place, and there is no filler or redundant exposition.

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 a single required parameter and an existing output schema, the description provides enough to invoke it correctly: the operation, the target resource, and the meaning of the only parameter. It omits explicit sibling differentiation, but the low complexity and output schema coverage make the definition functionally complete.

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

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

The input schema only defines idbank as a string with 0% description coverage. The description's Args line says it is 'The INSEE IDBANK identifier,' which adds the semantic role of the parameter. However, it does not provide an example, format, or guidance on how to obtain a valid idbank, so compensation for the schema gap is only partial.

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 full metadata for an INSEE series by idbank code.' This clearly distinguishes the tool from sibling data-retrieval and search tools, and the idbank-scoped target leaves no ambiguity about what it operates on.

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 this tool should be used when full metadata for a known INSEE idbank is needed, and it contrasts implicitly with data-fetching or search siblings. However, it never explicitly states when not to use it or names an alternative, such as insee_search_indicators for discovering idbanks or insee_get_data for series values.

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 present, so the description carries the full behavioral burden. It only says 'Search' and 'Returns: List of GeoResult.' It does not disclose filter matching behavior, pagination, ordering, error conditions, or any limitations, leaving the agent to guess important execution details.

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-loads the main purpose in the first sentence. The Args and Returns sections are clearly structured without unnecessary prose, though it could have added a brief example or filter behavior note.

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

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

For a simple two-parameter search with an output schema, the description is minimally viable. It identifies the key parameter values but omits important contextual details like how name_filter behaves, whether the result list is bounded, and how this tool relates to the many geographic-adjacent siblings.

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 0%, so the description must compensate. It does add meaning to geo_type by listing 'commune, departement, region,' which the schema does not. However, name_filter is only described as 'Optional name filter,' adding minimal semantic detail 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 clear verb and resource: 'Search INSEE geographic entities.' The Args line further defines the resource as commune, departement, or region, which separates it from sibling indicator/data tools, though it does not explicitly differentiate by name.

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?

There is no explicit guidance about when to use this tool versus alternatives like insee_search_indicators or insee_get_data. The phrase 'Search INSEE geographic entities' only implies a lookup use case; it does not state exclusions, prerequisites, or preferred scenarios.

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 burden of behavioral disclosure. It does state that the tool returns a list of matching IndicatorResult, which is useful, but it does not explain matching semantics, result limits, or any error behavior. For a simple search tool this is acceptable but minimal.

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 well-structured, with a one-line summary followed by Args and Returns sections. Every sentence contributes meaningful information without redundancy or unnecessary elaboration.

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 search tool with an output schema available, the description covers the core need: what to pass and what to expect back. It lacks notes on matching details and alternative tool selection, but given the low complexity, the description is largely complete.

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

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

The input schema provides no description for the keyword parameter and schema coverage is 0%. The description compensates somewhat by defining keyword as a 'Search pattern for indicator names,' but it does not clarify whether matching is partial, exact, case-sensitive, or whether wildcards are supported.

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: 'Search INSEE macrodata indicators by keyword.' This clearly identifies what the tool does and differentiates it from nearby siblings like insee_search_geography and various get_data tools.

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

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

The usage is implied: an agent should use this when it needs to find INSEE indicators by name keyword. However, it gives no explicit guidance about when to choose this over sibling search tools such as eurostat_search_datasets or worldbank_search_indicators, and no exclusions or alternatives are mentioned.

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 disclosure burden. It usefully states the return result (a list) and the non-obvious behavior that errors or a missing key yield an empty list rather than an exception. It does not disclose matching semantics, pagination, or data-source behavior, so the disclosure is only partial.

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

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

The description is compact and front-loaded with the purpose sentence, followed by tersely useful Args and Returns sections. There is no filler, and each line contributes operational 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?

The tool is simple and an output schema exists, so the description covers the core args and return behavior. However, it leaves gaps: an agent is not told what matching means (fuzzy/exact), why the result could be empty on 'missing key', or how this step fits into a fact-checking workflow.

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%, so the description must explain the parameters, and it does: query is described as the claim text and language_code as a BCP-47 code with a default. This adds real meaning beyond the bare string types 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?

The opening sentence names a specific verb ('Search'), a resource ('existing fact-checks'), and a match condition ('matching a claim'), so an agent immediately knows what is returned. The domain is clearly distinct from statistical-data siblings like eurostat_search_datasets and worldbank_search_indicators.

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 when to use it — when a claim needs to be checked against previously fact-checked content — but it does not explicitly state when not to use it or how it relates to related siblings such as score_check_worthiness or analyze_cherry_picking. No alternative tool is named.

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 behavioral disclosure burden. It does reveal the return shape (List of TimeSeries, one per country) and implies a read-only retrieval, but it does not mention error behavior, API quirks, limitations, or how filters/time_period affect results.

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-organized with a front-loaded one-line summary followed by a compact Args/Returns structure. Itavoids filler and presents the most important information first.

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 relatively simple data retrieval tool with four parameters and an output schema, the description gives enough parameter semantics and return behavior to make an initial call. It could be more complete by naming the sibling tools that are not appropriate and by specifying time_period/filter syntax, but it is not critically incomplete.

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%, so the description must compensate. It explains all four parameters with examples for dataflow and country, and gives meaningful descriptions for time_period and filters. Some details are still vague, such as the exact format for time_period, but overall it adds substantial value beyond the bare schema.

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

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

The description clearly states the action, resource, and output: 'Retrieve OECD data and convert to TimeSeries per country.' This is distinct from search-style siblings like oecd_search_datasets, though it does not explicitly name an alternative or contrast with them.

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 intended use is implied: call this when you need OECD data converted into TimeSeries by country. However, it does not state when not to use it or name alternatives such as oecd_search_datasets, eurostat_get_data, or worldbank_get_data, leaving some context 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 behavioral disclosure burden. It does disclose that the tool returns a list of dicts with code and title fields and that limit caps the result count. However, it does not mention behavior like ordering, pagination, error handling, or confirm that the operation is read-only.

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 well-structured: a one-line purpose, followed by explicit Args and Returns sections. There is no filler or redundant content.

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

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

For a simple two-parameter search tool with an output schema, the description is sufficient for correct invocation: it defines both inputs and the result shape. It lacks routing context relative to sibling tools, but that is already captured under usage guidelines.

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 provides the only meaning for both parameters: 'query' is a search keyword and 'limit' is the maximum number of results. This adds genuinely useful semantics beyond the bare parameter names and types.

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?

States a specific operation: 'Search OECD datasets by keyword.' The OECD scope clearly distinguishes it from sibling search tools like eurostat_search_datasets and worldbank_search_indicators, and the returns section confirms it produces dataset 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?

There is no guidance on when to choose this tool over alternatives, such as eurostat_search_datasets or oecd_get_data. The description does not mention prerequisites, use cases, or exclusions, so an agent gets little help routing between related tools.

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 explicitly discloses the return ('List of IndicatorResult ranked by relevance') and a failure mode ('IndicatorNotFoundError'), and it describes the disambiguation and source-preference behavior. It doesn't claim side effects, though a pure resolver's read-only nature is implied rather than stated.

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 definition is compact and front-loaded: a one-line purpose followed by clean Args, Returns, and Raises sections. Every sentence earns its place and the structure is scannable for an agent.

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

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

For a straightforward resolver with an output schema available, the description covers all required calling details: required term, optional disambiguation, optional source preference, return type, and error behavior. It could be more complete by explicitly stating that it resolves ambiguity across the four data sources and how that differs from direct source-specific searches, but the core invocation is complete.

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

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

The schema has zero property descriptions, but the Args section gives each parameter a meaningful role: term gets concrete examples, context gets its disambiguation purpose, and preferred_source gets an explicit allowed-value list ('insee, eurostat, worldbank, oecd'). This fully compensates for the schema's lack of descriptions.

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

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

The description opens with a specific verb and resource: 'Resolve a natural-language term to ranked indicator codes.' It clearly conveys what the tool does and the example terms ('chomage', 'PIB') reinforce it. It doesn't explicitly contrast itself with sibling search tools such as insee_search_indicators, so it falls short of full sibling differentiation.

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 phrase 'Resolve a natural-language term' and 'context... for disambiguation' imply when to use it: when the input is an imprecise natural-language expression rather than a structured source-specific search. However, there is no explicit guidance about when to choose this over the many sibling search tools, and no 'use X instead' 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?

There are no annotations, so the description carries the full burden. It discloses the output shape, the empty-list-on-error behavior, and the dependency on an API key, which are useful behavioral traits beyond the basic purpose.

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, front-loads the main purpose, and uses a clean Args/Returns structure. Every sentence adds useful information, with no filler or redundant elaboration.

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 one-parameter tool with an output schema, the description is complete: it states the input, the operation, the return format, and the error behavior. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema coverage is 0% and the schema only says 'text' is a string. The description adds meaningful semantics: 'The text containing one or more sentences to score.' For the single parameter, this fully compensates for the lack of schema-level documentation.

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: 'Score sentences in a text for check-worthiness using ClaimBuster.' It clearly identifies what the tool does and is easily distinguishable from the sibling data-search and retrieval tools.

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

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

The description implies its usage context—when sentence-level check-worthiness scores are needed—and gives an input constraint ('text containing one or more sentences'), but it never explicitly states when to prefer this tool over alternatives or when not to use it. The usage is clear but left implicit.

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?

There are no annotations, so the description must carry the behavioral burden. It does disclose sorting order ('sorted by value descending'), the year default behavior ('uses most recent available'), and optional filtering by income group. This is solid but does not address error conditions, missing data handling, or whether the tool is read-only.

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 well-structured: a one-sentence purpose followed by Args and Returns sections. No filler or redundant wording, and the core 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?

For a low-complexity tool with an output schema, the description covers the key execution context: parameters, default behavior, and return ordering. Minor gaps like invalid indicator codes or rate limits would be nice but are not essential to 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%, so the description must compensate. It provides meaningful explanations for all three parameters: indicator as a World Bank code, year with default behavior, and income_group as an optional filter. This fully covers the semantic gap left by 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: 'Rank countries by a World Bank indicator value.' This clearly distinguishes the tool from siblings like worldbank_get_data (raw data retrieval) and worldbank_search_indicators (indicator discovery).

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 when to use the tool—when you want a ranking rather than raw data—but it never explicitly states alternates or exclusions. No mention of 'use worldbank_get_data for raw values' or conditions under which this tool would be inappropriate.

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 disclosure burden. It does state the return shape ('List of TimeSeries, one per country'), which is useful, but it does not mention rate limits, error behavior, missing-data handling, or other runtime quirks.

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 leading summary sentence followed by Args and Returns sections. Every line contributes useful information and there is no redundant 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 straightforward data retrieval tool, the description covers the essential context: what it does, all parameters, and the return shape. It lacks explicit usage routing to siblings and deeper edge-case behavior, but it is still complete enough for an agent to call it correctly in most cases.

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%, so the description must compensate. It does: each parameter is explained with an example or format, including indicator code ('NY.GDP.MKTP.CD'), ISO3 country codes, year range format 'YYYY:YYYY', and most_recent as an optional count.

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: 'Retrieve World Bank indicator data for given countries.' This clearly distinguishes it from sibling tools like worldbank_search_indicators (search) and worldbank_get_country_ranking (ranking), and the scope is precise.

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 by mentioning 'indicator', 'country', and optional filters, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. There are no exclusion criteria or references to sibling tools.

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 burden of explaining behavior. It states that it returns a list of IndicatorResult matching the query and implies a read-only search, which is positive. However, it does not disclose matching semantics (exact, substring, case-sensitive), pagination behavior, rate limits, or how to interpret no results. It does not contradict any 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 3 compact sections: one-line summary, args, returns. It is front-loaded, has no fluff, and each sentence contributes essential information. It is appropriately sized for a simple two-parameter search tool.

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 low-complexity tool with only two parameters and an existing output schema, the description covers the essential details needed to invoke it. A short sentence about when to prefer worldbank_get_data or other sibling search tools would make it fully complete, but nothing critical is missing for actual 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?

The input schema only provides names, types, and a default for limit; the description adds functional meaning by explaining query as a search keyword and limit as the maximum number of results. That is sufficient to invoke the tool correctly despite 0% schema description coverage, though more detail such as accepted query syntax would be beneficial.

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: 'Search World Bank indicators by keyword.' It clear distinguishes itself from sibling tools like insee_search_indicators and eurst/s output by making 'World Bank' explicit, and from data-retrieval tools by being a keyword search. The source and action are unambiguous even without naming alternatives.

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: use this when you need to find Word Bank indicator metadata by keyword. However, it does not name any alternatives or state when not to use it, such as when an exact indicator code is already known and worldbank_get_data would be more suitable. The usage context is clear but only implicit.

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