site

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

With no annotations provided, the description carries the full burden of describing behavior. It discloses the specific output components—columns, numeric indicators, row count, and provenance banner—and positions the tool as a schema-learning step. It does not explicitly state that it is read-only, but this is strongly implied and low-risk for a zero-parameter metadata 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?

The description is two sentences with no wasted words. The core content is front-loaded, and the actionable guidance 'Call this first' is placed at the end, making the description compact and scannable.

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 schema-discovery tool with no output schema, the description is complete: it lists the key result types and tells the agent the intended invocation order. The sibling tool list provides enough surrounding context that nothing essential 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 the schema already fully covers parameter semantics and the description has no parameter burden. The baseline of 4 for a zero-parameter tool is appropriate; no additional parameter explanation is needed.

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

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

The description clearly states what the tool provides: column names, numeric flags, row count, and the provenance banner, and explicitly frames it as the first call to learn the schema. It does not use an explicit verb like 'returns', and it does not directly contrast itself with siblings such as dataset_provenance, so it stops just short of full differentiation.

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

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

The description gives a clear situational directive: 'Call this first to learn the schema.' This tells the agent when to use the tool, but it does not mention when not to use it or name alternative tools for more specific metadata needs.

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 transparency burden, and it does disclose the core behavior: matching by column membership and preserving the given value order. It does not mention return shape or whether it is strictly read-only, but the title's 'compare rows side by side' plus the selection semantics make the main behavior clear.

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

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

One compact sentence packs the resource, selection rule, ordering behavior, and intended use case with no filler. 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?

For a simple two-parameter read-style tool with no output schema, the description plus schema covers what an agent needs to invoke it correctly: target column, allowed values, and output row order. It does not explicitly explain the 'side by side' display format, which is a minor gap given the title.

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 illuminate the parameters. It does: 'column' is the field being matched, and 'values' are the allowed values whose order drives the result order. It does not repeat min/max constraints, but those are already 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 filter-and-order behavior: select rows of the dataset whose given column matches any supplied value and preserve the supplied order. It distinguishes the tool from generic dataset_row/dataset_search by emphasizing 'X vs Y' comparison, though it does not explicitly name 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 'for "X vs Y" questions' gives a clear use-case context: the tool is for comparing the rows corresponding to two or more specific values in a column. It does not explicitly state when not to use it or name alternatives, but the intended scenario is apparent.

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 of behavioral disclosure. It states what the tool returns: source, computation date, licence, and citation, which is the tool's core behavior. It does not explicitly state that it is read-only, but the wording and nature of provenance metadata strongly imply a safe read operation with no side effects.

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

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

The description is two short sentences with no filler. It front-loads the specific content returned and follows with a practical use instruction. Every word 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?

For a zero-parameter metadata-retrieval tool, the description is complete. It names the dataset, the exact fields returned, and the intended purpose. The absence of an output schema is adequately compensated by the enumeration of return contents.

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

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

The tool has zero parameters, and the schema is an empty object, so there is nothing meaningful to document. The baseline for 0-parameter tools is 4, and the description appropriately does not attempt to invent parameter guidance.

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

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

The description clearly identifies the tool's resource, the FindAgency HQ dataset, and the exact provenance fields it exposes: source, computed date, licence, and citation. It lacks an explicit action verb like 'returns' or 'lists', but the title and phrasing make the purpose unmistakable. It is distinct enough from sibling tools like dataset_stats or dataset_columns, though it does not explicitly name a sibling for comparison.

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

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

The description provides a clear usage context: 'Read this to attribute a figure correctly.' This tells an agent when to consult the tool. It does not mention alternatives or explicitly say when not to use it, but the narrow provenance scope makes that omission minor.

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 present, so the description carries the full behavioral disclosure burden. It does state the exact and case-insensitive matching behavior, but it leaves ambiguity between the singular title ('a row') and plural description ('The rows'), and does not clarify whether all matches are returned, the output format, or no-match behavior.

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

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

The description is a single, efficient sentence that packs in the dataset name, the matching condition, and the case-insensitivity modifier with no wasted words. It is appropriately sized and 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?

For a read tool with no output schema and no annotations, the description should explain what is returned when matches exist or not. It only says 'the rows... where a column equals a value exactly,' leaving output shape, result cardinality, and edge cases unspecified. This is minimal but incomplete.

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%, and the description partially compensates by defining the relationship: `column` is the field to compare against and `value` is the exact value to match. However, it does not list valid column names, value formatting expectations, or other parameter constraints, so the enrichment over the schema is basic.

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

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

The title and description clearly express a lookup operation for rows where a column exactly equals a value, with a specific verb ('look up') and a concrete resource. It does not explicitly differentiate from sibling tools like dataset_search, so it falls short of a 5, but the exact-match condition gives it a distinct identity.

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

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

The description implies the tool is for exact, case-insensitive value lookups, which suggests a natural use case. However, there is no explicit guidance about when to use this tool versus alternatives such as dataset_search, nor any mention of when not to use it.

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

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

With no annotations provided, the description carries the full burden and does disclose key behaviors: substring cell matching, case-insensitivity, and the 50-row upper bound. It does not mention ordering, default limit behavior, or empty-result handling, but these are minor for correct invocation.

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

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

The description is a single sentence with no filler, front-loading the result type and core matching behavior before the limit. Every part 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?

For a simple query-and-limit tool, the description plus schema provides enough to invoke it correctly: query is required, limit is optional with min/max, and matching behavior is clear. It does not specify row structure or ordering, but those are not essential for selecting and calling this 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 schema describes only the query parameter, while limit lacks description. The tool description adds useful semantics for query ('cells contain', case-insensitive), but its 'up to 50' largely repeats the schema's maximum constraint and does not clarify the default limit or behavior when omitted.

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 specifies the exact behavior: it returns rows of the FindAgency HQ dataset whose cells contain the query, with case-insensitive matching and a 50-row cap. This clearly differentiates it from siblings like dataset_columns, dataset_stats, and dataset_row as the free-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?

The description implies usage when an agent needs rows matching a substring in any cell, but it does not explicitly state when to use or avoid this tool, nor does it mention any alternatives. Usage is inferable but not clearly guided.

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 of behavioral disclosure and does a good job by explaining that grouping commas and currency are handled and that non-numeric rows are excluded and counted. This provides meaningful edge-case behavior beyond the basic stat computation. It could go further by specifying behavior for an empty dataset or a missing column, but the disclosed handling is valuable.

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

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

The description is a single focused sentence that front-loads the computed statistics and then adds edge-case behavior. Every part contributes useful information with no redundancy or 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 single-parameter tool, the description covers what is computed and how problematic values are handled. Since there is no output schema, explicitly listing the six output statistics helps fill that gap. It leaves minor unknowns like exact response structure and error handling, but overall the tool is adequately described for an agent to invoke it.

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 only defines 'column' as a non-empty string, so the description adds important context by stating it is a numeric column of the FindAgency HQ dataset and that formatted numbers are supported. However, it does not specify the expected column identifier format, such as exact header name or case sensitivity, leaving some ambiguity for a parameter with 0% schema description coverage.

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

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

The description clearly states the operation: computing count, min, max, mean, median, and sum for a numeric column. This specific scope distinguishes it from sibling tools like dataset_row, dataset_search, and dataset_top, which serve different purposes. The title reinforces the resource and operation clearly.

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 intended use is implied by the description: call this tool when summary statistics for a numeric column are needed. However, there is no explicit guidance about when not to use it or which sibling might be preferred for other needs, such as retrieving raw rows or comparing datasets.

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 correctly conveys the core read behavior and the two ordering modes, but it does not disclose default limit behavior, handling of ties, or behavior when a non-numeric column is supplied.

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

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

The description is a single, front-loaded sentence that immediately names the core behavior and then adds a clarifying example. There is no filler or redundant restating of the tool name.

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 clarify what is returned, which it does ('rows'). Yet it omits details such as the default result count and edge-case behavior, leaving the agent to infer some important execution semantics from parameter constraints alone.

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 low at 33%, with only 'ascending' documented. The description adds useful meaning by clarifying that 'column' should be numeric and that the tool returns highest or lowest rows, which maps to 'ascending'. However, 'limit' is left without semantic explanation in either the schema or the description.

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

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

The description states a specific operation: return the highest or lowest rows of the FindAgency HQ dataset by a numeric column. The natural-language phrasing "which is the most/least X" makes the intent unmistakable and distinguishes it from sibling tools like dataset_row, dataset_search, and dataset_stats.

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 use case is implied through "which is the most/least X," which tells an agent roughly when to invoke it. However, it does not explicitly compare against siblings such as dataset_stats or dataset_row, nor does it state when not to use this tool.

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

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

With no annotations provided, the description carries the transparency burden and does useful work: it states that this tool 'states plainly what submit_enquiry does' rather than performing a submission, and it discloses key behavioral facts—nothing is bought/paid, no quote is guaranteed, it is free. It also describes what the tool returns, though it does not explicitly say the tool itself has no side effects.

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?

Four tight sentences, front-loaded with the most important directive ('Read first'), and every sentence adds a distinct fact. There is no filler or redundant explanation beyond what is needed for the tool to stand alone.

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?

Given zero parameters, no output schema, and no annotations, the description supplies the essential context: what the underlying submit_enquiry does, what the enquiry is not, and what information the tool returns. An agent has enough to invoke it correctly without missing critical context.

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 zero properties, so the baseline 4 applies; there are no parameter semantics for the description to add. The description does not claim or imply parameters, so there is no 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 immediately identifies the tool as the plain-language explanation of submit_enquiry, naming the action ('starts an enquiry with human providers who quote directly'), the platform (FindAgency HQ), and what it is not ('nothing is bought, ordered or paid'). This clearly separates it from the sibling submit_enquiry tool while being specific about its own role.

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

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

The opening 'Read first' explicitly instructs the agent to consult this description before acting, and the framing makes it clear this is the prerequisite for understanding what submit_enquiry does. It does not explicitly mention alternatives or exclusions, but the relationship to submit_enquiry is unambiguous.

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?

Annotations are absent, so the description carries the full burden. It discloses the output content (field attributes) but does not explicitly state that the operation is read-only or side-effect-free. While the nature of returning field definitions strongly implies a safe getter, the description does not explicitly address behavioral traits such as authentication, rate limits, or error conditions.

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

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

Two sentences with no redundancy. The first sentence front-loads the core purpose (what the tool returns), and the second sentence adds a practical usage hint. Every word 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?

For a zero-parameter, read-only getter with no output schema, the description is sufficiently complete. It specifies the exact data points returned and how the results relate to submit_enquiry. Minor omissions like pagination or response format are not critical given the tool's simplicity.

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 is empty (0 parameters), so the baseline is 4 per the rubric. The description adds value by explaining that the returned field keys are used for submit_enquiry, which clarifies the relationship between tools but does not need to explain parameters since none 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 clearly states that the tool returns every field of the FindAgency HQ enquiry, enumerating the attributes (key, label, type, required, help text, allowed options). This is a specific, noun-phrase purpose that distinguishes it from siblings like submit_enquiry (which submits) and enquiry_describe (which likely describes the overall 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 includes a direct usage hint: 'Pass answers to submit_enquiry keyed by field key.' This implies the tool is meant to be called before submitting, providing the field keys needed for submission. It does not explicitly contrast with enquiry_describe or state when not to use it, but the usage context is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that step 1 only validates and returns a summary/token, that step 2 triggers actual submission, and that a person must click an emailed link before providers see the enquiry. It does not cover failure modes or what happens if consent=false, but the core side effects are well disclosed.

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

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

The description is detailed but every sentence earns its place: disambiguation, step 1, step 2, and the exact consent wording. It is front-loaded with the most important caveat ('NOT a purchase') and remains tightly structured despite covering a complex flow.

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, consent-gated submission flow with no output schema, the description is unusually complete. It tells the agent what step 1 returns (summary, consent line, token), what to show the person, when to proceed to step 2, and the post-submission email-link requirement. Nothing essential 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. The description adds workflow-level meaning beyond the schema: answers must be keyed by enquiry_fields keys, consent=true is required in both steps, and confirmation is the token obtained only after the person approves the step-1 summary. This clarifies how the parameters relate to the two-step process.

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 verb and resource ('Submits an enquiry to FindAgency HQ') and immediately disambiguates with 'NOT a purchase, NOT a guaranteed quote.' It also names the two-step flow, which clearly distinguishes it from sibling tools like enquiry_describe and enquiry_fields.

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 explicit step-by-step usage: step 1 with answers and consent, then step 2 only if the person agrees, with the confirmation token. It also references enquiry_fields for answer keys and warns against using this for purchases or guaranteed quotes, giving clear 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.