site

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

No annotations exist, so the description carries full responsibility. It discloses exactly what data is returned (columns, numeric flags, row count, provenance banner) and implicitly signals a safe read operation. It does not mention pagination or output formatting, but for a simple schema tool this is adequate.

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, with the essential content front-loaded and the usage directive appended. Every word earns its place; no filler or repetition of the title.

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, no-output-schema tool, the description covers the key return values and the recommended calling order. The only minor gap is the unexplained term 'provenance banner,' but it is a domain-specific label rather than a missing behavioral detail.

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

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

The tool has zero parameters, so there is nothing for the description to add. The baseline of 4 applies here because no parameter semantics are needed, and the description avoids inventing fake parameter guidance.

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 provides columns, numeric indicators, row count, and provenance banner — a specific schema-discovery resource. However, it lacks an explicit verb like 'returns' and does not directly distinguish itself from sibling dataset_provenance, relying on 'Call this first' to imply its discovery role.

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 instructs 'Call this first to learn the schema,' which tells an agent exactly when to invoke it. It does not mention exclusions or alternatives, but the guidance is clear enough for a zero-parameter discovery tool.

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

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

The description discloses the core selection behavior (column matches any value) and ordering (in the order given). Since no annotations are provided, it carries the burden of transparency; it does not address edge cases like missing values, duplicate matches, or case sensitivity, but the primary behavior is clear.

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?

A single sentence with no filler. It front-loads the action (returns rows) and includes the key ordering and usage 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 what the tool returns, the filtering logic, and the intended scenario. It does not describe the output format or error behavior, but the title and name cover the side-by-side comparison aspect. For a simple two-parameter tool without output schema, it is reasonably complete.

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

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

The description explains both parameters implicitly: 'column' is the field to match on, and 'values' are the set of values to filter by. Since schema description coverage is 0%, this semantic context is valuable, though it doesn't explicitly mention that values is an array.

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 that the tool returns rows from the Recallvia dataset filtered by a column matching any of the given values, in the order provided. This distinguishes it from sibling tools like dataset_row (single row) and dataset_search (search across columns), though it doesn't explicitly name 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?

It provides the intended use case 'for X vs Y questions', which signals comparison scenarios, but it does not explicitly describe when not to use it or name alternative tools. The context is clear but not exhaustive.

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

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

With no annotations provided, the description carries the full burden. It discloses the exact content returned (source, date, licence, citation) and the intended use (attribution). It does not mention potential errors, but for a simple read-only metadata tool with zero parameters, this is adequate. No contradictions with any annotations exist.

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

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

The description is two sentences, with the first sentence front-loading the key data fields and the second providing the actionable guidance. Every word earns its place, with no fluff or redundancy.

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

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

For a tool that returns provenance metadata, the description fully covers what an agent needs: it lists the information included and when to use it. No output schema or annotations are needed because the tool has no parameters and the return content is fully described. It is complete for its simple purpose.

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

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

The tool has zero parameters, so the schema coverage is 100% and there is nothing to explain. Per the rubric, a zero-parameter tool gets a baseline of 4. The description adds no parameter info, which is appropriate since there are none.

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

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

The description clearly states the tool's purpose: providing the source, computation date, licence, and citation for the Recallvia dataset. It distinguishes itself from sibling tools that handle columns, rows, stats, etc., by focusing on provenance metadata. The verb 'read' and specific data fields make the intent unambiguous.

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

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

The description gives a direct usage instruction: 'Read this to attribute a figure correctly.' This implies when to use it (when attribution is needed) but does not explicitly contrast with alternatives or state when not to use it. Given the sibling tools are clearly different in scope, the context is sufficient.

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?

The description contributes one behavioral trait (case-insensitive matching), which is useful beyond the schema. However, it leaves ambiguity: the title says 'a row' (singular) while the description says 'the rows' (plural), and it does not disclose matching behavior for missing values, non-unique matches, or invalid columns.

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 single, front-loaded sentence that directly conveys the core operation and the key matching rule. No filler or redundancy.

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

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

For a simple two-parameter lookup, the description is mostly enough, but the singular/plural mismatch between title and description is a real gap, and with no output schema and no annotations the return-behavior expectations are under-specified.

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 schema description coverage at 0%, the description must carry parameter meaning. It maps both parameters ('column' and 'value') into the phrase 'where a column equals a value', which is minimal but sufficient. It does not specify that 'column' must be an existing dataset column or clarify value formatting nuances.

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 title and description clearly identify a row-lookup operation using an exact key match, and the description adds the case-insensitive detail. However, it does not explicitly differentiate this from the sibling dataset_search tool beyond the word 'exactly'.

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?

Usage context is implied by 'equals a value exactly' and 'case-insensitive', suggesting this is for exact-match lookups rather than fuzzy search. But there is no explicit guidance on when to choose this over dataset_search or what to do when no match exists.

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 behavioral burden. It discloses case-insensitive matching, cell-level containment semantics, and the 50-row cap. It does not cover empty-result behavior or output shape, but those are less critical for a simple 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?

A single sentence with no filler. The key matching semantics are front-loaded, and the row cap is included as essential operational detail.

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 two-parameter search tool with no annotations and no output schema, the description conveys the core behavior adequately. Minor gaps remain around output structure and behavior when no rows match, but the essential calling context 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?

Schema coverage is only 50%, but the description compensates meaningfully: it clarifies that query matching is case-insensitive and that results are capped at 50, directly illuminating the limit parameter that lacks a schema 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 states a specific behavior: returning rows whose cells contain the query, case-insensitively, up to 50. This clearly distinguishes the tool from siblings like dataset_stats or dataset_row, which serve different purposes.

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

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

The description gives clear situational context: use this when you need rows matching a text query across any cell. It does not name alternatives or exclusions, but the intent is unambiguous enough to guide selection.

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 disclosure burden and does provide meaningful behavioral details: grouping commas and currency are normalized, and non-numeric rows are excluded but still counted. It doesn't mention error behavior for missing columns or the exact response structure, but the key quirks are 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 a single, well-structured sentence that front-loads the statistic list and resource, then appends the important data-cleaning caveats. Every clause earns its place; there is no fluff or repetition.

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

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

For a one-parameter, read-only statistical tool, the description covers the operation, the input's intended meaning, and the main dirty-data behaviors. The lack of an output schema is partially mitigated by explicitly listing the returned statistics, though exact return formatting and error conditions are left unspecified.

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 adds the crucial meaning that the column should be numeric and ties it to the Recallvia dataset. However, it doesn't specify how the column should be referenced (exact name vs. label) or what happens when the column doesn't exist, so compensation 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 identifies a specific operation—computing count, min, max, mean, median, and sum—on a numeric column of the Recallvia dataset. This clearly distinguishes it from sibling tools like dataset_row, dataset_top, or dataset_compare, which handle different kinds of retrieval or comparison.

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: whenever aggregate numeric statistics for a column are needed. However, it never explicitly mentions alternatives or says when not to use it, so routing is left to inference rather than stated guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it returns highest/lowest rows but does not mention the limit parameter's default behavior, the ascending default, how ties are handled, what happens with non-numeric columns, or the return format. This is a minimal disclosure that leaves significant behavioral unknowns.

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 single, front-loaded sentence that immediately conveys the core purpose. It contains no filler or repetition. It could be slightly more informative without sacrificing conciseness, but it is efficient.

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 ranking tool with three parameters, no output schema, and no annotations, the description is insufficient. It does not explain return value structure, default limit, or edge cases. An agent would need to experiment to understand the tool's full behavior, which is a significant gap given the lack of annotations.

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 only 33% (only 'ascending' has a description). The description mentions 'numeric column' which hints at the 'column' parameter but does not explain the 'limit' parameter or the default ordering. It does not compensate for the low schema coverage, leaving the agent without clear meaning for two of the three 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 clearly states the tool ranks rows by a numeric column, returning the highest or lowest rows, and provides a concise phrasing ('which is the most/least X'). It distinguishes itself from siblings like dataset_search (search) and dataset_stats (aggregate statistics) by focusing on ordering. However, it does not explicitly use the verb 'rank' or 'sort', and the phrase 'Recallvia dataset' is assumed context.

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 offers no guidance on when to use this tool versus alternatives. It does not mention that this is for top-N ranking as opposed to searching or comparing, nor does it specify any prerequisites (e.g., the column must be numeric). An agent has to infer usage from the schema and name.

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