site

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

With no annotations, the description carries full responsibility for disclosing behavior. It explains the returned contents (columns, numeric indicators, row count, provenance banner), but doesn't specify whether there are side effects, authentication requirements, or any output format details. It's transparent enough for a no-argument read-oriented tool, but not exhaustive.

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 that front-loads the key output details and ends with a clear call-to-action. It is concise, though the phrasing 'of the The Water Hub dataset' is grammatically awkward.

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-introspection tool with no output schema, the description adequately conveys what the agent will receive and when to call it. It could be more explicit about differentiation from dataset_provenance, but it's sufficient for a first-step discovery call.

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

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

The tool has zero parameters, and the schema fully covers this by declaring an empty properties object. The description doesn't need to explain parameter semantics, so the baseline 4 applies.

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 output: columns, numeric flags, row count, and provenance banner. The directive 'Call this first to learn the schema' gives the tool a clear purpose, though it doesn't explicitly distinguish it from sibling tools like dataset_provenance.

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 'Call this first to learn the schema' provides clear context for when to use it, positioning it as an initial schema-discovery step. It doesn't explicitly state when not to use it or mention alternatives, but the ordering guidance is useful and specific.

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 of behavioral disclosure. It does disclose two meaningful behaviors: rows are filtered by exact value membership and returned in the order supplied by the values array. It does not describe the output layout, pagination, error behavior, or whether the operation is read-only, though the title hints at the side-by-side presentation.

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 that front-loads the core behavior and ends with the concrete use case. There is no filler or repetition of schema details, and every clause contributes meaning.

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

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

For a simple two-parameter compare tool, the description covers the essential filtering and ordering semantics, and the title supplies the output presentation style. With no output schema, a bit more detail about the returned structure would be ideal, but the description is nearly sufficient for an agent to call this tool 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 0%, so the description must compensate. It directly explains the meaning of both parameters: 'column' is the field to match and 'values' are the set of allowed matches, with array order controlling output order. This adds real semantic value beyond the raw schema, even though min/max item constraints remain 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 behavior: returning rows from The Water Hub dataset where a column matches any of the given values, preserving the given order. The title adds 'compare rows side by side,' which signals the comparison intent and helps distinguish it from generic row/search tools, though it does not explicitly name any sibling.

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' provides a clear use case and implies this tool is for comparing a small set of specific values. However, it does not mention when to use dataset_search, dataset_row, or dataset_stats instead, leaving alternative selection partly 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 behavioral disclosure burden. It transparently lists the fields returned and frames the operation as read-only metadata lookup, which is sufficient for a fixed no-parameter provenance 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 a single tight sentence plus a focused usage instruction. Every clause earns its place, and the core content is front-loaded without unnecessary elaboration.

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 tool with no output schema, the description is complete. It tells the agent what information will be returned and why the tool should be used, leaving no critical gap for correct invocation.

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 and is fully covered by the description's lack of parameter requirements. Since the tool takes no parameters, the baseline of 4 applies and the description adds appropriate clarity.

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 exactly what the tool provides: the source, computed date, licence, and citation for The Water Hub dataset. It clearly distinguishes this provenance/metadata tool from sibling tools like dataset_columns, dataset_row, and dataset_stats by specifying its unique informational purpose.

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 use case: 'Read this to attribute a figure correctly.' This tells the agent when to invoke the tool, though it does not explicitly mention alternatives or 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?

No annotations are provided, so the description carries the full disclosure burden. It does disclose the case-insensitive equality behavior and that multiple rows may be returned, but it does not describe behavior for no matches, duplicate matches, or output shape. These are notable gaps for a tool with no output 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?

The description is a single front-loaded sentence with no filler. It earns its place, but the awkward 'The rows of the The Water Hub dataset' phrasing and the singular/plural mismatch between title ('a row') and description ('rows') prevent a perfect structure score.

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

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

For a simple two-parameter lookup, the core predicate is described, but with no annotations and no output schema, the description leaves out return behavior, error conditions, and any guidance on how this relates to sibling tools. It is minimally sufficient but not complete enough for an agent to fully anticipate the tool's behavior.

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 explain the parameters, and it does: 'column' is the dataset column to test and 'value' is the exact value to match. This adds real meaning beyond the raw string types, though it does not enumerate valid column names or edge cases like case sensitivity of column names.

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: retrieve rows from The Water Hub dataset where a specified column equals a given value. The title and description together distinguish this as an exact-match lookup rather than a general search, though the double 'the' typo slightly weakens clarity.

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 this tool is for exact, case-insensitive equality matching, which differentiates it from sibling tools like dataset_search, but it never explicitly states when to use this tool versus alternatives. No exclusions or prerequisite conditions 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?

With no annotations, the description carries the transparency burden. It adds useful behavioral detail: matching is case-insensitive, matches any cell, and results are capped at 50. However, it does not state that the operation is read-only, how results are ordered, or what happens when there are no matches.

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 entire definition is one front-loaded sentence with no filler, and the core operation is stated first. A minor duplication ('the The Water Hub') slightly detracts from polish but does not hurt scannability.

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 text search, the definition covers what is searched, the matching semantics, the cap, and implies row-shaped results. It relies on the schema for requiredness and limit constraints; specifying return shape more explicitly would make it fully complete, but nothing essential is missing for correct invocation.

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 50%: query has a description, limit has min/max but no text. The description adds case-insensitivity for query and restates the 50 cap already present in the schema, but it does little to explain the limit parameter's behavior beyond that, leaving the agent to infer from the parameter name and constraints.

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: it identifies rows of the named 'The Water Hub dataset' that match a query, distinguishing it from sibling row/column/stats tools. The matching semantics (cells contain query, case-insensitive) make the purpose unmistakable.

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 behavior is clear enough that an agent can infer when to use it, but the description never explicitly says when to prefer it over dataset_row, dataset_top, or dataset_compare, and gives no when-not-to-use conditions. Usage guidance is implied 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, the description carries the full burden. It discloses that grouping commas and currency are handled and that non-numeric rows are excluded and counted, which are important edge-case behaviors. It does not mention return format, but the list of statistics implies the result structure.

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, well-structured sentence that front-loads the statistics list and then adds relevant edge-case details. No redundant words; every clause adds value.

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?

The tool is simple with one parameter and no output schema. The description covers the core behavior, the dataset context, and key edge cases. It does not explicitly describe the return structure, but the listed statistics imply it. Overall, adequate for an agent to call 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?

The schema has zero description coverage for the single 'column' parameter. The description adds that the column must be numeric and belongs to The Water Hub dataset, but does not provide examples or specify exact naming conventions. This partially compensates for the schema gap but leaves some ambiguity.

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 action (computing count, min, max, mean, median, sum) on a numeric column of a named dataset, with explicit handling of formatting and non-numeric rows. It clearly distinguishes itself from sibling tools like dataset_columns or dataset_row by focusing on statistical aggregation.

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 clearly indicates this is for summary statistics on a numeric column, implying use when such aggregates are needed. It does not explicitly list alternatives or exclusions, but the purpose is specific enough that an agent can infer when to use it versus other dataset tools.

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

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

With no annotations, the description carries the full burden, but it only restates the ranking behavior and numeric-column requirement. It does not disclose tie handling, missing/null values, error behavior, or what fields 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?

The description is a single front-loaded sentence with the core ranking behavior first and an illustrative use case after. Minor grammatical awkwardness ('the The') does not obscure the meaning.

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

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

For a simple 3-parameter read tool, the basics are inferable, but because there is no output schema and no annotations, the description should say more about the returned rows, default limit, and edge cases. It is minimally viable rather than 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 documents only ascending; the description adds that column must be numeric and that highest/lowest corresponds to ordering. Limit semantics are left to the schema's numeric bounds, so the description only partially compensates for the 33% 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 states a clear operation: returning the highest or lowest rows of the dataset ordered by a numeric column. It is distinct from siblings such as dataset_stats, dataset_search, or dataset_row, though it does not 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 quoted use case ('which is the most/least X') gives an implied context for ranking, but there is no explicit guidance about when to choose this tool over a search, stats, or single-row tool, nor any exclusions.

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 behavioral disclosure burden. It makes the output explicit: an enquiry with human providers, nothing bought or paid, no guaranteed quote, and returns about recipient details, consent wording, and confirmation method. For a pure describe tool this is transparent and sufficient.

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 front-loaded with 'Read first' and every sentence adds relevant information about scope, cost, guarantees, and return content. It is a bit dense but appropriately sized for a no-input tool that needs to set expectations.

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

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

With no parameters and no output schema, the description fully covers what an agent needs: the tool's purpose, the key facts about The Water Hub enquiry flow, and what information it returns. Nothing critical is missing for correct invocation.

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 schema coverage is 100%, so the description does not need to explain parameter meaning. Baseline 4 applies for a parameterless tool.

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 this tool is an explainer: it 'States plainly what submit_enquiry does on The Water Hub.' It distinguishes itself from the action tool submit_enquiry and from sibling tools by specifying the covered content: human providers, direct quoting, no purchase/payment, no guaranteed quote, and the return details.

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 imperative 'Read first' gives explicit usage direction: this should be consulted before using submit_enquiry. It does not name alternative tools or exclusions, but for a zero-input description tool the 'read first' instruction is sufficient context.

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 burden for behavioral disclosure. It implies a read-only metadata lookup by listing returned properties, but it does not explicitly state that no side effects occur, that no submission is made, or describe any other runtime 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 compact and front-loads the core content: what fields are returned and how to use them. It loses a point for the typo 'the The' and for slightly awkward phrasing, but it is otherwise efficient.

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 and no output schema, the description adequately explains the return content and the downstream usage. It is not fully complete because it does not describe the output format or explicitly disambiguate from enquiry_describe, but nothing essential is missing for a simple metadata lookup.

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, so the schema is trivially complete. The description adds value by explaining that the returned field keys are meant to be used as keys when calling submit_enquiry.

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 what the tool returns: every field of the Water Hub enquiry, including key, label, type, required status, help text, and allowed options. It connects to submit_enquiry, but it does not explicitly distinguish itself from the 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 description gives clear usage context: retrieve the field definitions, then pass answers to submit_enquiry keyed by field key. It does not state exclusions or when not to use it, but the intended workflow is obvious.

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 burden. It discloses validation behavior, required consent, the returned summary/token, the email link that must be clicked before any provider sees the enquiry, and the exact consent wording. This is far more transparent than a typical submit action.

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 dense but organized chronologically into Step 1 and Step 2, front-loaded with caveats. The verbatim consent text is included, and every sentence contributes to correct invocation without fluff or 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 tool with no output schema and no annotations, the description fully covers the required sequence, what to show the user, what the confirmation token is for, and the final email-link delivery requirement. No critical detail an agent needs to call the tool 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?

Although schema coverage is 100%, the description adds meaning the schema lacks: answers must be keyed by field key from enquiry_fields, consent is not just a boolean but agreement to a specific quoted statement, and confirmation must be the token from the prior step. This materially changes how parameters are populated.

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?

Description states 'Submits an enquiry to The Water Hub' with a clear verb and resource, and explicitly contrasts with 'NOT a purchase, NOT a guaranteed quote'. This makes the tool's purpose distinct from the sibling enquiry_* tools and from commercial ordering concepts.

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?

Provides an explicit two-step invocation flow: Step 1 validates and returns a summary/token, Step 2 is used 'only if the person agrees' and includes the confirmation token. It also references enquiry_fields for answer keys, giving implicit guidance on the companion tool to use, and clarifies when-not (not a purchase).

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