site

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

No annotations are provided, so the description carries the burden, and it does disclose what the call returns (columns, numeric flags, row count, provenance banner), effectively signaling a safe read-only introspection. It doesn't state that there are no inputs or side effects, but for a zero-arg listing tool the disclosed return contents are the main behavioral fact an agent needs.

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 tight sentences with the resource and returned fields front-loaded and the usage cue placed last. No filler; only a slightly loose phrase ('the provenance banner') costs it the top mark.

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?

With no parameters, no output schema, and a simple read-only shape, the description supplies enough for correct invocation by enumerating the returned fields. It lacks any note on return format or ordering, but for a zero-arg describe tool this 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 tool takes zero parameters, so per the rubric the baseline is 4. The schema is empty and there is nothing further to document.

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 names a specific resource (the Excurvo dataset) and enumerates exactly what the tool surfaces: column names, which are numeric, row count, and provenance banner. It reads more like an inventory/describe operation than its siblings, though the 'provenance banner' overlaps conceptually with the sibling dataset_provenance, which it does not explicitly distinguish itself from.

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?

'Call this first to learn the schema' is explicit ordering guidance that tells the agent when to reach for this tool. It stops short of naming alternatives or exclusion conditions, so it is clear context without full when-not routing.

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 full behavioral burden. It helpfully discloses the matching semantics (any of the values = inclusion/OR) and that output order follows the given values, which is genuine behavioral info. It omits limits such as max 10 values, behavior on no matches, and any output shape.

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 front-loaded sentence with no filler; the selection semantics come first and the question-type hint last. It is efficient, though arguably too terse given zero schema-coverage support.

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 2-parameter read tool with no annotations or output schema, the description covers selection semantics and ordering adequately. It leaves gaps around return format, value-count limits, and edge cases like nonexistent columns.

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 implies the meaning of both params: 'column' is the field to match and 'values' are the match targets, OR-combined and order-sensitive. It does not mention the 2-10 item bounds present 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 states a specific retrieval behavior: rows of the Excurvo dataset whose column matches any of the given values, returned in the given order. The 'for X vs Y questions' clause signals intent. It distinguishes itself from dataset_search by emphasizing order preservation, though it never names siblings explicitly.

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 'for "X vs Y" questions' gives an implied usage context, which is a real cue. However, it never says when to use this over dataset_row or dataset_search, nor any exclusions or 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?

With no annotations, the description carries the full burden, and it does convey that this is a passive metadata read with no arguments. However it says nothing explicit about side effects, idempotency or whether the tool ever mutates anything — it is trivially safe by construction, but the safety profile is inferred, not 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?

Two short sentences, zero filler, with the returned fields front-loaded before the usage clause. Every sentence earns its place.

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?

No output schema exists, and the description compensates by naming the four pieces of information returned, which is what an agent needs to decide whether to call it for attribution. It could go slightly further by noting the format of the citation or whether the data is stable, but it is sufficient for a zero-argument 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing further for the description to document here.

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?

Names the exact resource (the Excurvo dataset's provenance) and enumerates what it returns: source, computation date, licence, citation. Against siblings like dataset_columns, dataset_stats and dataset_search, which all expose data rather than metadata, an agent can tell this one apart immediately.

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?

"Read this to attribute a figure correctly" gives a concrete when-to-use condition, which is unusual and helpful for a lookup tool. It stops short of naming alternatives or stating exclusions, so it is a clear context statement rather than full routing 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, the description carries the full behavioral burden, yet it only discloses case-insensitive matching. It says nothing about how many rows are returned, whether the first match is returned or all matches, pagination, behavior on no match, or whether the column must exist — all material for a lookup 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, and the core operation is front-loaded. Nothing is repeated from the title or schema, and every phrase ('rows', 'column equals value', 'exactly', 'case-insensitive') carries meaning.

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 with no output schema and no annotations, the description is minimally adequate but leaves the return shape, match cardinality, and empty-result behavior undefined. Those gaps matter because no structured field fills them.

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 clarify the semantics of both parameters — column is a column identifier and value is the comparison target matched case-insensitively — but omits whether value must be a string form of numbers/dates and how column names are validated.

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 retrieval operation — the rows where a column equals a value — which is clear enough to act on. It does not, however, distinguish itself from siblings like dataset_search (likely fuzzy/substring) or dataset_top, so the agent must infer the distinction from 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 is only implied: the phrase 'equals a value exactly' signals this is for precise lookups rather than fuzzy search, but no alternative tool is named and no when-not condition is given. An agent could reasonably still be unsure whether to pick this or dataset_search.

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 full behavioral burden. It does disclose useful traits: matching is case-insensitive, it scans any cell, and results are capped at 50. However it omits ordering of results, pagination/truncation behavior beyond the cap, and any read/permission context, so meaningful gaps remain.

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 front-loaded sentence with zero filler; the resource, match rule, and cap are all packed in without 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 two-parameter search with no output schema, the description conveys the returned entity (rows), the match rule, and the result ceiling. What is still missing is result ordering and whether the 50 cap implies truncation of a larger match set.

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% (the 'limit' parameter has no schema description), and the description compensates by conveying the 50-row ceiling and the case-insensitive any-cell match for 'query'. It adds real meaning beyond the schema, though it does not explain how a caller could lower the limit to narrow results.

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 verb and resource: returns rows of the Excurvo dataset whose cells contain the query. The matching semantics (case-insensitive, any cell) make it unmistakable against siblings like dataset_stats or dataset_provenance, though it never names those siblings to draw the boundary explicitly.

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 when-to-use guidance at all: nothing tells the agent to prefer this over dataset_row, dataset_top, or dataset_compare, and no exclusions or prerequisites are given. Only the implied usage of a text search is conveyed, which is the definition of no explicit 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, the description carries the full burden and does add real behavioral detail: commas/currency are normalized, non-numeric rows are excluded and counted. It stops short of stating the operation is read-only, error behavior for a non-numeric column, or how the excluded count is surfaced.

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?

One sentence, front-loaded with the returned metrics, with the handling caveats parenthetically appended. No wasted words, though the parenthetical packs three distinct behaviors together.

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?

No output schema exists, so the description correctly enumerates the return values (count, min, max, mean, median, sum). For a one-parameter read tool the coverage is nearly sufficient; only result structure/pagination and failure modes are unstated.

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 single 'column' parameter is undocumented in the schema (0% coverage), so the description must compensate. It does constrain the parameter semantically to a numeric column and describes how non-numeric values are handled, which is more than the bare schema offers, but it gives no naming/format guidance for the column 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?

Names the exact operation (count, min, max, mean, median, sum) and the exact target (a numeric column of the Excurvo dataset). An agent can distinguish this from dataset_columns or dataset_top by the returned metrics, though no sibling is named explicitly.

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 is only implied by the stated output metrics; there is no explicit when-to-use statement and no mention of alternatives such as dataset_compare or dataset_top. The agent must infer that this is the tool for per-column aggregates.

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 burden, yet it only restates that it ranks rows. It does not disclose direction defaults beyond the schema, tie-breaking behavior, the 1-50 limit cap, return format, or any access/permission requirements. This leaves substantial behavioral gaps for a ranking 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 front-loaded sentence that leads with the operation and follows with a short clarifying gloss. Efficient, with no wasted clauses, though the gloss is somewhat redundant with the opening clause.

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 three-parameter read tool with no output schema and no annotations, the description is minimally adequate: it explains the core ranking concept but omits tie handling, the limit bound, and any sense of the returned shape or ordering guarantees.

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% (ascending is documented in the schema), so the description should compensate but largely does not. It conveys that 'column' must be numeric but omits that 'column' is required, the meaning of 'limit', and the 1-50 bound, adding little beyond the schema text.

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 (return the highest/lowest rows by a numeric column) against a named resource (the Excurvo dataset), with the gloss "which is the most/least X" making the intent concrete. It does not, however, distinguish itself from siblings like dataset_stats or dataset_row, which could also surface extremes or single rows.

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 phrasing "which is the most/least X" implies the use case (finding extremes) but never states when to prefer this over dataset_stats, dataset_search, or dataset_row, nor any prerequisites. Usage is implied rather than guided.

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