site

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

With no annotations, the description carries the full burden but does disclose the payload contents an agent receives (column list, numeric flags, row count, provenance banner), so the return shape is inferable. It never states the operation is a read-only metadata query, which is an implicit but unstated guarantee.

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, no filler, and the action cue ("call this first") is placed after the payload summary so the agent knows both what it gets and when. Nothing is wasted.

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, listing the returned fields is enough for an agent to know it is safe and useful as an entry point. The only missing element is an explicit statement that this is a read-only, side-effect-free call.

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

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

Zero parameters, so the baseline is 4; there is nothing to disambiguate. The description correctly avoids inventing parameters that do not exist in the empty 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 names the concrete resources returned: columns, which are numeric, row count, and the provenance banner, scoped to the Lettza dataset. It is distinguishable from siblings like dataset_row and dataset_search, though the overlap with dataset_provenance and dataset_stats (both banner/row-count adjacent) is not called out.

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" gives explicit ordering guidance, which is a clear when-to-use signal. It stops short of naming alternatives or stating when another sibling (e.g. dataset_stats) should be preferred instead.

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 behavioral burden, and it discloses little beyond the ordering guarantee. It does not say whether the tool is read-only (implied), what happens when a value matches nothing, how rows are shaped, or that at most 10 values are accepted.

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 tight sentence with no filler, and the comparison use case is placed at the end as a clear qualifier. It is efficient, though the leading fragment construction makes it slightly less immediately scannable than a verb-first statement.

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 no annotations, no output schema, and zero schema description coverage, the description is too thin: return shape, no-match behavior, and how 'column' relates to the sibling dataset_columns tool are all left 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?

Schema description coverage is 0%, so the description must compensate. It does explain the matching semantics (column value is any of the given values) and that result order follows the input order, which is real added meaning. It still omits the 2–10 item bounds and what 'column' can accept (e.g. valid column names, or whether dataset_columns should be consulted first).

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 what is returned (rows of the Lettza dataset matching the given column values, in the given order) and hints at the comparison use case, but it is phrased as a noun fragment rather than a clear verb+resource, and it never explicitly says this compares rows. Sibling tools dataset_row and dataset_search also return rows, so the distinction from them is only weakly drawn.

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 trailing phrase 'for "X vs Y" questions' implies the usage context, which is genuinely helpful. However, there is no explicit when-to-use vs when-not, and no named alternative (e.g. dataset_row or dataset_search) for single-row or free-text lookups.

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 the shape of the payload (source, date, licence, citation), which tells the agent this is a static metadata read with no mutation risk, but it never explicitly states that the call is side-effect free or that it requires no arguments. Adequate, with a small gap.

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 with zero filler. The inventory of returned content is front-loaded and the usage instruction follows immediately, so an agent gets both the payload and the trigger in one pass.

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 output schema, the description compensates by listing the fields the caller will receive (source, date, licence, citation). For a zero-argument metadata lookup this is essentially complete, though it stops short of describing the format of those fields (e.g. machine-readable vs. prose).

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 parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool is 4. No parameter information is needed or missing.

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 the specific resource (provenance of the Lettza dataset) and enumerates the returned content: source, computation date, licence, citation. That clearly separates it from siblings like dataset_stats or dataset_row, which deal with values rather than attribution metadata. It is not a tautology of the title, though the verb is implied rather than stated.

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 an explicit trigger condition for using the tool. No competing alternative is named, but the attribution use case is narrow enough that no sibling is a plausible substitute, so the guidance 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?

With no annotations, the description carries the full burden but discloses only one behavioral trait: matching is case-insensitive. It says nothing about result limits, pagination, behavior on an unknown column name, or whether multiple rows can be returned.

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 the subject ('the rows of the Lettza dataset') and the filter condition stated immediately. Slightly fragment-like phrasing, but no wasted words.

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

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

For a two-parameter read lookup with no output schema this is close to adequate, but it omits what the caller gets back (all matching rows? one row?) and what happens when the column does not exist, both of which an agent would want before invoking.

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, and it partly does: it clarifies that 'column' names the column to test and 'value' is the exact comparison target, with case-insensitive matching. It does not say whether 'column' takes a header name versus an index, nor any escaping rules for 'value'.

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 (look up rows of the Lettza dataset) with a precise filter condition: column equals value exactly. The 'exactly (case-insensitive)' qualifier implicitly separates it from dataset_search, though no sibling is named.

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 saying rows match 'exactly,' the description hints that this is the tool for precise lookups while dataset_search covers looser matching. There is no explicit when-to-use, when-not-to-use, or named alternative.

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, so the description carries the full burden. It does disclose useful traits: matching is case-insensitive, the scan covers any cell, and results are capped at 50 (implying truncation), but it says nothing about permissions, ordering, or what happens when more than 50 rows match.

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 tight sentence with zero waste, front-loading the resource and scan scope before the matching rule and cap.

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?

There is no output schema and no annotations, so the description is the only source of behavioral detail. It covers what is returned (rows) and the cap, but omits result ordering, pagination/truncation signaling, and any access requirements, leaving meaningful gaps for a search tool.

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

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

Schema coverage is only 50% (only 'query' is described), so the description must compensate. It adds real meaning the schema lacks: matching is case-insensitive and applies to any cell, and 'up to 50' explains the limit parameter's ceiling, though acceptable values for limit are left to 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?

States a specific verb (search) and resource (rows of the Lettza dataset) plus the matching mechanism (cells containing the query). It is clearly distinguishable from siblings like dataset_row or dataset_stats, though it never names an alternative to disambiguate further.

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 when-to-use guidance and no exclusions. With six siblings (dataset_row, dataset_top, dataset_compare, etc.) the agent gets no help deciding when a free-text cell search is preferable to a row fetch or a top-N query.

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 still discloses key behavior: grouping commas and currency are handled, and non-numeric rows are excluded and counted. That tells the agent how data is cleaned and that exclusions are reported, though it omits error handling and read-only nature (which is implied for stats).

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, dense sentence lists all returned metrics first and then adds two important data-handling clauses. No filler, front-loaded, entirely earned.

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 statistical tool with no output schema or annotations, the description provides the output metrics and key data-cleaning rules. It leaves minor gaps around error behavior and exact column addressing, but the core invocation context is present.

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 for the single `column` parameter. The description compensates by specifying that the column must be numeric and part of the Lettza dataset, but it doesn't explain naming format, case sensitivity, or how to handle non-existent columns.

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 the exact statistics returned (count, min, max, mean, median, sum) and the resource (a numeric column of the Lettza dataset), so the agent knows precisely what the tool computes. It does not explicitly differentiate from sibling tools like dataset_columns or dataset_top, but the specificity of the metrics makes its role clear.

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 statement of when to use this tool versus the sibling dataset_* tools, nor any prerequisites or exclusions. The description is purely functional and offers no 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?

No annotations are provided, so the description carries the full disclosure burden. It does not state tie-breaking behavior, the default and 50-row cap on limit, whether full rows or only the ranked column are returned, or whether the column must be numeric (it hints at this by saying 'numeric column' but does not warn about non-numeric input failing).

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 tight sentence that front-loads the operation and appends a compact use-case gloss after the em dash. Nothing is padded, though the sentence could have absorbed one more clause (limit behavior) at little cost.

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 annotations and no output schema, the description must cover both behavior and return shape. It conveys the core operation but omits the return format, the limit default/cap, and ordering tie behavior, leaving meaningful gaps for a tool an agent must call blind.

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%, so the description needs to compensate. It adds one genuinely useful constraint — that 'column' should be numeric — but says nothing about 'limit' (range 1-50, default) or what happens when 'ascending' is omitted, leaving two of three parameters effectively undocumented.

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 gives a specific verb and resource ('the highest/lowest rows of the Lettza dataset by a numeric column') and even captures the user question it answers ('which is the most/least X'). It does not differentiate itself from siblings like dataset_stats or dataset_search, but the operation is unambiguous on its own.

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 'which is the most/least X' implicitly signals the use case (ranking/extremum queries) rather than filtering or comparison. However, it never says when to prefer this over dataset_search, dataset_stats, or dataset_compare, and gives no prerequisites or exclusions.

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