site

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

No annotations are supplied, so the description carries the full burden. It correctly implies a side-effect-free metadata read and discloses the returned fields, but it says nothing about whether the result is cached/static, whether it is expensive, or that it requires no arguments — low risk for a zero-param reader, hence a middle score.

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, no filler, with the call-first directive at the end. The first sentence is slightly list-heavy but every item earns its place by telling the agent what comes back.

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 must convey return values — and it does, enumerating columns, numeric classification, row count, and provenance. For a no-argument, no-output-schema tool that is nearly complete; it could add format hints but nothing an agent needs to call it is absent.

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 description adds nothing that parameter semantics could add, and nothing is 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 exact payload (columns, numeric flags, row count, provenance banner) so an agent knows precisely what this tool returns, which separates it from dataset_row or dataset_stats. It never states an action verb, but for a zero-argument introspection tool the returned content is the purpose, and it is 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?

'Call this first to learn the schema' gives explicit ordering guidance that no sibling provides. It stops short of naming alternatives or when-not-to-use conditions (e.g. use dataset_stats for aggregates), so it falls just short of a 5.

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 disclose one real behavioral trait: results follow the order of the given values. It does not say whether matching is exact or case-sensitive, what happens for unmatched values, whether missing rows are dropped, or that the operation is read-only. Useful but incomplete for an unannotated 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 that front-loads the returned resource and appends the intended question type. No redundant text, though it is terse enough that some key semantics are left out.

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 and no annotations exist, so the description is the only source of behavioral detail. It covers what rows come back and in what order, but says nothing about the return shape (side-by-side layout implied only by the title) or edge cases, which for a two-param tool with zero schema descriptions leaves gaps.

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. Its phrasing 'rows whose column is any of the given values' clarifies the OR-match semantics between the two params and that ordering is significant, which adds real meaning. But it omits match type (exact vs partial), case sensitivity, and says nothing about the 2–10 value 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 concrete verb+resource: it returns rows of the Capital Gains Tax HQ dataset filtered so a given column matches any of the supplied values. That is more specific than the title's vague 'Compare rows side by side'. It doesn't explicitly name how it differs from dataset_search or dataset_row, but the 'X vs Y' framing and the ordered-values behavior make its role inferable.

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 clause 'for "X vs Y" questions' gives a clear usage scenario, which is more than nothing. However, no alternatives are named (e.g., dataset_search for fuzzy lookup, dataset_row for a single row) and no exclusions or preconditions are stated, so the agent must infer when this beats the 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?

With no annotations provided, the description carries the disclosure burden alone. It usefully enumerates the returned fields (source, date computed, licence, citation), which tells the agent what behavior to expect from this read-only metadata call. It says nothing about permissions, caching, or freshness guarantees, but for a zero-parameter lookup of static metadata the risk surface is minimal, so a 3 is appropriate.

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, both earning their place: the first enumerates the returned content, the second states the action the agent should take. The most decision-relevant information 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?

With no output schema, the description must convey the return values, and it does so by listing the four provenance fields an agent will receive. It stops short of describing the response structure or format, but for a simple metadata lookup this is nearly 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 declares zero parameters, so there is nothing for the description to disambiguate. The baseline for a no-parameter tool is 4, and nothing in the description contradicts 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 a specific resource and enumerates exactly what it returns: source, computed date, licence, and citation for the CGT HQ dataset. That is far more informative than a tautology, and the function is plainly distinct from data-oriented siblings like dataset_columns or dataset_stats, though it never explicitly contrasts itself 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?

"Read this to attribute a figure correctly" gives one clear usage condition (attribution/citation), which is a genuine trigger. However, it names no alternatives and offers no exclusions, so an agent must infer when provenance is not needed. This is implied usage rather than 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. It usefully discloses that matching is case-insensitive, a behavior the schema cannot express. But it says nothing about how many rows may come back, result ordering, limits, or permissions for this dataset.

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 matching semantics (exact, case-insensitive) are front-loaded. The phrasing 'The rows of the ... dataset where' is slightly indirect for an action description but wastes no space.

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-required-parameter tool with no annotations, no output schema, and no schema descriptions, the definition omits the return shape (single row vs. multiple matches), any limit behavior, and parameter format guidance. The case-insensitivity note is the only piece of operational detail 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?

Schema description coverage is 0%, so the description must compensate. It only gestures at the parameters via 'a column equals a value'; it never states the expected column-name format, whether column identifiers come from dataset_columns, or how the value string is interpreted.

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 (look up rows) and resource (dataset_row) and pins the matching rule to 'a column equals a value exactly (case-insensitive)'. It does not name any sibling, so the boundary with dataset_search is left implicit, but the purpose itself is 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 word 'exactly' implies this is for precise key matches rather than fuzzy retrieval, which nudges the agent away from dataset_search. However there is no explicit statement of when to use this over dataset_search or dataset_compare, and no prerequisites or exclusions are 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?

No annotations are provided, so the description carries the full burden. It usefully discloses case-insensitive matching and a 'up to 50' result cap, which frames it as a bounded read, but it is silent on the default limit, how truncated results are signaled, error behavior, and whether any permissions are needed.

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 compact sentence that front-loads the resource and operation and packs scope, matching semantics, and result cap with 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?

With no output schema, the description does enough to say rows are returned, but it omits the row/column shape of results, the default limit value, and truncation signaling. For a two-parameter search tool with no annotations, these are meaningful gaps rather than fatal ones.

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 50%: 'query' is already documented in the schema, while 'limit' is not. The description's 'up to 50' loosely reflects the limit maximum but never ties it to the limit parameter, states its default, or explains how the two interact, so it only partially compensates for the gap.

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

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

The description names a specific operation (search) against a specific resource (the Capital Gains Tax HQ dataset) and states what is returned (rows whose cells contain the query, case-insensitive). It does not explicitly distinguish itself from siblings like dataset_row or dataset_top, but the verb+scope are clear enough that an agent can identify it as the full-text search tool.

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

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

There is no when-to-use or when-not-to-use guidance and no alternatives named. The agent must infer that this is the tool for ad-hoc text lookup versus dataset_row (fetch a row) or dataset_stats, with no help from the description.

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 largely meets it: it discloses that grouping commas and currency symbols are parsed before aggregation, and that non-numeric rows are excluded rather than erroring. It does not say what happens if the named column does not exist or is entirely non-numeric, so it falls short of full coverage.

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 that front-loads the returned statistics with edge-case handling relegated to a parenthetical. Efficient, with nothing wasted, though the opening lowercase list reads more like a stub than a polished definition.

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 must convey both behavior and return shape; it enumerates every returned statistic and the data-cleaning rules. The remaining gap is how an agent should obtain valid column names, which the sibling dataset_columns would supply.

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% for the single 'column' parameter, but the name is self-explanatory and the description adds a real constraint the schema lacks: the column must be numeric. However, it gives no format guidance and no way to discover valid column identifiers.

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 statistic set (count, min, max, mean, median, sum) and the resource (a numeric column of the Capital Gains Tax HQ dataset), so the agent knows precisely what is computed. It does not explicitly contrast itself with siblings like dataset_top or dataset_compare, but the operation is 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?

There is no statement of when to reach for this tool versus dataset_top, dataset_compare, or dataset_row, nor any prerequisite such as discovering valid column names via dataset_columns. Usage is only implied by the phrase 'numeric column'.

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 stays silent. It never states that this is a read-only operation, how many rows are returned by default, what happens when the limit is exceeded, or that ranking requires a numeric-typed column (only implied). For a tool with zero structured behavior hints this is a significant 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?

A single tight sentence that front-loads the ranking behavior. The trailing quoted 'most/least X' framing earns its place as a usage cue, though the em-dash construction is slightly informal.

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 and no annotations, the description should describe the returned shape and the default row count, and it does neither. It is adequate for an agent to pick the tool but leaves meaningful gaps for calling 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 description coverage is only 33%, and the description usefully adds the non-obvious constraint that the column must be numeric and that the ascending flag toggles highest-vs-lowest. It says nothing about the limit parameter's bounds (max 50) or default, which the schema only partially conveys, so it compensates for one gap but not both.

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 (returns/ranks) and resource (rows of the Capital Gains Tax HQ dataset) plus the operative constraint (by a numeric column, highest or lowest). It is clearly distinguishable from dataset_row and dataset_search by its ranking semantics, though it never names those siblings.

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' gives a recognizable use-case trigger, which is better than nothing. However, there is no explicit when-not guidance, no mention of how this differs from dataset_stats or dataset_compare, and no note on when to prefer dataset_row for a simple lookup.

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 usefully disclose that nothing is bought, nothing is paid, it is free, and no quote is guaranteed. It also names what it returns (recipient, consent wording, confirmation). It stops short of stating side effects or whether any data is persisted by the describe call itself.

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?

'Read first' front-loads a directive efficiently, but the middle sentence is dense and mixes narration of submit_enquiry's terms with a summary of this tool's return values, which costs clarity. It is not bloated but not cleanly structured either.

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?

Without an output schema or annotations, the description must carry the explanation, and it does name the returned items (recipient, consent wording, confirmation method). For a zero-param informational tool this is adequate, though the ambiguity between describing itself versus submit_enquiry leaves a small 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?

The tool takes zero parameters, so there is no parameter semantics to document; the 4 baseline for a parameterless tool applies. The description correctly implies no input is required.

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 makes clear this is a descriptive/informational tool whose verb is 'states plainly' and whose subject is what submit_enquiry yields, distinguishing it from the actual submission tool. However, it reads partly as a description of submit_enquiry's behavior rather than crisply of enquiry_describe itself, which slightly muddies the resource framing.

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 first' is a clear sequencing hint, implying it should be consulted before submit_enquiry. But it offers no explicit when-not guidance and does not distinguish itself from the sibling enquiry_fields, leaving the choice between the two descriptive tools 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 full disclosure burden. It does well by describing the returned record shape in detail (key, label, type, required, help text, allowed options), which substitutes for a missing output schema, but it never explicitly states that the tool takes no input, has no side effects, or is a pure read operation.

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, no filler. The return-shape description is front-loaded, and the workflow hint is appended last. Every clause 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?

There is no output schema, so the description reasonably documents what the tool returns, and for a zero-parameter discovery tool that covers the essentials. It stops just short of fully specifying behavior (e.g. that it returns all fields unconditionally with no filtering), but nothing critical for correct invocation 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description's mention of 'field key' refers to the sibling tool's keying convention rather than any input to this tool, so there is no parameter meaning to add or clarify.

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 resource (every field of the Capital Gains Tax HQ enquiry) and enumerates exactly what each entry contains: key, label, type, required flag, help text and allowed options. An agent knows this is a schema-discovery read tool, and the final sentence ties it to the downstream consumer, distinguishably separating it from submit_enquiry.

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 context for how the output is consumed ('Pass answers to submit_enquiry keyed by field key'), which effectively routes the agent through the fields->submit workflow. It does not, however, explicitly state when to call this versus the sibling enquiry_describe, nor does it frame it as a prerequisite step, so it falls short of full when/when-not 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 so: it discloses that step 1 is validation-only, what step 1 returns (summary, consent line, token), that step 2 actually submits, that the person must click an email link before any provider sees the enquiry, and the exact consent semantics. This is unusually complete behavioral disclosure for a mutation-style 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?

It is front-loaded with the critical 'not a purchase' framing and organized as Step 1 / Step 2, so it scans well despite being one long paragraph. The repeated consent sentence overlaps with the schema's own consent description, a minor 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-step, nested-object submission tool with no output schema and no annotations, the description covers inputs, both call phases, return content at each phase, and the downstream email-confirmation gate. Nothing an agent needs to invoke either step correctly 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: 'answers' are keyed by field key from enquiry_fields, 'consent' must be true and encodes a specific agreement, and 'confirmation' is the token produced by step 1 after human approval. The token's origin and provenance are explained rather than merely defined.

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 verb and resource ('Submits an enquiry to Capital Gains Tax HQ') and immediately disambiguates with 'NOT a purchase, NOT a guaranteed quote', which is exactly the confusion a sibling like dataset_* or enquiry_fields could cause. An agent can tell what this tool does and does not do without opening the schema.

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 lays out an explicit two-step protocol: Step 1 with answers + consent=true to validate, Step 2 'only if the person agrees' with the token. It also routes the agent to enquiry_fields for the field keys, so both the when and the prerequisite source are stated.

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