site

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

No annotations and no output schema, so the description carries the full burden; it partly discharges that by enumerating the returned fields. It does not state that the operation is read-only/side-effect free, nor any cost or caching behavior, so the safety profile is left to inference.

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: the payload is front-loaded and the call-order directive follows. Every clause adds information (fields returned plus sequencing) and nothing is repeated.

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 read tool with no output schema, the description covers the essential return surface and the call ordering, which is sufficient to invoke it. It could be slightly richer by clarifying how its provenance output differs from the dedicated dataset_provenance sibling.

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, which is the baseline-4 case by rule. The description correctly implies the tool is argument-free via the directive to call it first, with nothing to misconfigure.

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 concretely what the tool returns: columns, which are numeric, the row count, and the provenance banner, scoped to a named dataset. That is enough for an agent to distinguish it from dataset_stats or dataset_row, though the 'provenance banner' element overlaps with the sibling dataset_provenance and the overlap is not disambiguated.

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 sequencing guidance, which is exactly the routing information an agent needs. It stops short of naming alternatives (e.g., when to prefer dataset_provenance or dataset_stats instead), so no exclusions are stated.

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 at all, the description carries the full behavioral burden, and it discloses only one trait: output row order follows the order of the given values. It says nothing about exact vs partial matching, deduplication, empty results, error behavior, or permissions for a 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?

It is a single sentence with no padding, which is good, but the clause 'whose column is any of the given values, in the order given' is convoluted and buries the actual purpose behind the dataset name and a dangling 'X vs Y' aside.

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 tool with no annotations, no output schema, and zero schema description coverage, this description is too thin. The agent still lacks legal column names, matching semantics, response shape, and routing versus sibling dataset tools.

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

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

Schema description coverage is 0%, so the description must document both parameters; it only partially does. It clarifies that 'values' is matched against 'column', that any match qualifies, and that order matters, but it never says what column names are legal (dataset_columns exists but is not referenced) or that up to 10 values are allowed.

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 which rows are returned and that output order follows the input values, but the operative verb 'Compare' is never explained — behaviorally this looks like a filtered retrieval, not any actual comparison, so the agent must infer the tool's effect. It also never distinguishes itself from siblings like dataset_row or dataset_search.

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 clause 'for "X vs Y" questions' gives a concrete trigger case, which is real usage guidance. However, no alternatives are named or excluded, so the agent cannot tell when dataset_search, dataset_top, or dataset_row would be the better pick.

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, but this is a zero-parameter metadata read, so the behavioral surface is inherently small. The description discloses the fields the tool surfaces, which is useful, but says nothing about response shape, freshness guarantees, or any access constraints.

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, front-loaded with a list of the returned metadata followed by the use case. No filler, though the first sentence is a bare list rather than an action-oriented 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?

With no output schema, the description carries the burden of describing the return values, and it does enumerate them clearly for a zero-param tool. It is close to complete; only the response format and freshness/versioning behavior are unaddressed.

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 baseline there is no parameter semantics to explain. The description correctly avoids inventing arguments and instead spends its words on the returned content.

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 and enumerates exactly what it returns (source, computation date, licence, citation) for a named dataset, which is far more concrete than its siblings' names alone. It does not explicitly contrast itself against siblings like dataset_columns or dataset_stats, but the resource is distinctive enough to be separable.

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 implied usage trigger, so an agent can infer it should be called when provenance/attribution metadata is needed. However, there are no exclusions and no named alternatives, so the guidance is contextual rather than explicit.

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 that matching is case-insensitive, which is real behavioral detail beyond the schema, but it says nothing about result cardinality, limits, or whether all matching rows are 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 compact sentence with no filler; the dataset name and matching rule are front-loaded. The noun-phrase phrasing ('The rows of...') is slightly less direct 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?

With no output schema and no annotations, the description should cover what is returned and any limits. It omits return shape, cardinality, and error behavior, leaving the agent under-informed for a lookup 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 description coverage is 0%, so the description must compensate. It clarifies the relationship between the two parameters (column equals value, case-insensitive), which is the essential semantic, but adds no format, constraint, or column-name guidance beyond that.

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 dataset and the exact-match filtering operation it performs, which is a clear verb+resource statement. It doesn't explicitly contrast itself with siblings like dataset_search, so it stops short of a 5.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no named alternative (e.g., dataset_search for non-exact lookups). The 'exactly' phrasing faintly implies this is for precise lookups, but the agent must infer that on its own.

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 real behavior: case-insensitive substring matching across any cell, capped at 50. However, it omits what happens when more than 50 rows match, whether results are ranked or ordered, and the shape of each returned row.

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, front-loading the resource and the matching rule before the cap. 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?

With no output schema and no annotations, the description is the sole source of truth, yet it leaves the return shape undefined beyond the word 'rows' and does not say whether the 50 cap truncates silently or signals more matches. Adequate but with a real gap 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 description coverage is 50%: 'query' is documented as 'text to look for in any cell' while 'limit' has no schema description. The description's 'up to 50' partially restores the limit semantics and reinforces the matching behavior, but adds nothing beyond that.

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 ('rows of the SIM Only Deals Compare dataset whose cells contain the query'), so an agent knows exactly what it retrieves. It differentiates implicitly from point-lookup siblings like dataset_row, but never names an alternative, so it stops short of a 5.

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

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

There is no guidance on when to choose this tool over dataset_row, dataset_top, or dataset_compare. The 50-row cap hints at a scoping rule but is framed as an output fact, not as a selection condition between 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 full behavioral burden and does disclose meaningful traits: locale formatting is normalized ('grouping commas and currency are handled') and dirty data is handled deterministically ('non-numeric rows are excluded and counted'). It stops short of describing error behavior for missing columns or how the exclusion 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?

A single sentence that front-loads the metrics list and appends the parsing/cleaning caveats. Dense but every clause earns its place; no filler.

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

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

For a simple one-parameter aggregation tool with no output schema, the description effectively documents the return payload by listing exactly which metrics come back. The main omission is what happens on an invalid or non-numeric column name.

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% for the single 'column' parameter, but its name and the description's 'numeric column' phrasing convey that a numeric column reference is expected. It does not clarify the accepted format (exact header string vs. index) or casing, so it only partially compensates for the coverage 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?

States a specific operation (summary statistics) on a specific resource (a numeric column of the SIM Only Deals Compare dataset) and enumerates the exact metrics returned. It is clearly distinguishable from siblings like dataset_columns or dataset_row, though it does not 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?

The phrase 'of a numeric column' implies the column must be numeric, but there is no explicit guidance on when to reach for this tool versus dataset_columns or dataset_top, and no mention of prerequisites such as resolving a valid column name first.

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 and no output schema, so the description carries the full behavioral burden, yet it discloses little: no default for 'limit', no indication of what the returned rows look like, and no tie-breaking or numeric-type handling. It only restates the ascending/descending behavior already covered by the schema.

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 extremum framing is stated first. The em-dash aside is slightly redundant with the opening clause but not wasteful.

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 tool with no annotations and no output schema, key details are missing: default limit, cap behavior at 50, and the shape of the returned rows. The description is adequate for a first call but not 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 low (33%), so the description must compensate, and it does add one meaningful constraint — the column must be numeric — plus the highest/lowest mapping. It still says nothing about 'limit' (no default, no max-of-50 note) or the accepted column-name format.

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 ('highest (or lowest) rows ... by a numeric column') on a named dataset, which an agent can distinguish from siblings like dataset_stats or dataset_row. It does not, however, explicitly name or contrast with those siblings, so the differentiation is implicit.

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 parenthetical 'which is the most/least X' gives an implied use case (extremum questions) but offers no explicit when-to-use vs. dataset_stats/dataset_search guidance and no exclusions. Usage is inferable rather than stated.

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 disclosure burden, and it does meaningfully characterize the user-facing behavior: nothing is bought, ordered or paid, no quote is guaranteed, and it is free. It also previews the returned content (who receives details, consent wording, and how the person confirms), which is exactly the trust-relevant context a consent flow needs. It still omits whether the tool itself has side effects, but the read-only intent is strongly implied.

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 usage cue ('Read first') is front-loaded, followed by the purpose and the guarantee caveats in a single compact block. The only mild redundancy is the trio 'bought, ordered or paid,' but it reinforces the key reassurance, so nothing genuinely wastes 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?

There is no output schema, no annotations, and no parameters, so the description must stand alone, and it sufficiently covers purpose, guarantees, and the shape of what is returned. For a simple 0-arg descriptive tool this is close to complete, with only minor room to be more explicit about the exact return structure.

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 nothing for the description to disambiguate. Per the baseline for 0-param tools, a 4 is appropriate; no syntactic or semantic gaps exist.

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 pairs a clear resource (the enquiry flow on SIM Only Deals Compare) with specific verbs (states, returns) and explicitly contrasts itself with the sibling submit_enquiry, which it says actually starts the enquiry. An agent can distinguish this documentation/read tool from the action tool without opening either schema. The framing is slightly indirect ('States plainly what submit_enquiry does') rather than a crisp 'describes X', which keeps it just below the top mark.

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.' gives an explicit ordering cue that this should be consulted before submit_enquiry, which is real usage guidance rather than a vague hint. It does not, however, spell out when-not-to-use it or name other alternatives, so it stops short of full when/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?

No annotations are provided, so the description carries the full burden. It does disclose the shape of the returned data (field key, label, type, required flag, help text, allowed options), which substitutes for the missing output schema, but it says nothing about read-only safety, auth needs, or that it takes no input.

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 no filler; the enumeration of returned attributes is front-loaded and the actionable instruction follows. Slightly dense but 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 discovery tool, the description essentially specifies the return payload and its purpose in the submit_enquiry workflow, which is what the agent needs. Only the absence of any safety/behavioral note keeps it from being fully 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 baseline rule a 4 applies. The description also helpfully notes that field 'key' is the identifier to use when submitting answers, giving the empty schema context it lacks on its own.

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 SIM Only Deals Compare enquiry) and enumerates the attributes returned: key, label, type, required, help text, and allowed options. It is clearly a discovery/schema tool, but it never explicitly contrasts itself with the similarly-named sibling enquiry_describe.

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 second sentence gives concrete downstream usage: 'Pass answers to submit_enquiry keyed by field key,' which tells the agent this is the step to call before submitting. There is no explicit when-not condition or statement of why one would prefer this over enquiry_describe.

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 exist, so the description carries the full burden and does so: it discloses validation behavior, that a summary/consent line/token are returned, that submission is a two-phase confirm-before-commit flow, and that the person must click an email link before any provider sees the data. Consent semantics are spelled out verbatim rather than left to the schema.

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?

Long but front-loaded with the disambiguation ('NOT a purchase') and then ordered by step, so every clause is operational. The consent sentence is duplicated from the schema description, which is the one piece of redundancy in an otherwise economical block.

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 the description compensates by stating what each step returns (summary, consent line, confirmation token) and what the person ultimately receives (an email with a required click-through). For a nested-object, two-phase tool this is enough to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine sequencing meaning: confirmation is only supplied on the second call and only after approval, and consent must be true in both steps. It doesn't explain answer key formats beyond pointing at enquiry_fields, but the procedural semantics are the valuable addition.

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?

Opens with a specific verb and resource ('Submits an enquiry to SIM Only Deals Compare') and immediately bounds it with what it is not ('NOT a purchase, NOT a guaranteed quote'). It also names the related tool enquiry_fields as the source of field keys, so an agent can separate it from the dataset_* siblings at a glance.

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?

Gives explicit preconditions and a condition for each call: step 1 with answers + consent, show the summary, step 2 'only if the person agrees' with the token. The gating condition for the second, irreversible call is stated, not inferred.

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