site

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

No annotations are provided, so the description carries the full burden. For a zero-parameter metadata read it does the essential job: it discloses the exact payload (columns, numeric flags, row count, provenance banner) and frames the call as an initial discovery step, implying a side-effect-free read. It omits any note on cost, caching, or error behavior, but there is little else to disclose for this 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?

Two short sentences with no filler. The return-contents list is front-loaded, but the most actionable instruction ('Call this first') sits at the end where it could have led.

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

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

With no annotations and no output schema, the description must stand alone, and it adequately describes the return shape and the recommended call order. An agent has enough to invoke it correctly; only the absence of explicit read-only framing and sibling routing keeps it from the top.

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 and the schema is empty, so there is nothing further to document. Per the rubric, a parameterless tool establishes the baseline of 4.

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

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

The description names the specific resource (columns of the Commercial Refinance Quotes dataset) and enumerates what comes back: column list, numeric flags, row count, and provenance banner. It is clear, though the mention of a 'provenance banner' blurs slightly with the sibling dataset_provenance, and it never explicitly contrasts itself with that 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?

'Call this first to learn the schema' gives explicit sequencing guidance, telling the agent to invoke this before the other dataset_* tools. It stops short of stating exclusions or naming alternatives (e.g., when to use dataset_provenance instead for provenance), so it is clear context without full 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 disclosure burden. It does add one genuine behavioral fact not present in the schema: results come back 'in the order given', which matters for side-by-side comparison. It says nothing about read-only nature, cardinality or limits, behavior when a value has no match, or the shape of the returned rows, leaving real gaps.

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, and the core mechanics are front-loaded before the 'X vs Y' use case. The em-dash clause is slightly clumsier than a separate sentence would be, 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?

The schema is tiny and there is no output schema or annotations, so the description has to stand in for the missing context. It explains matching and ordering but never says what a result row looks like, how many rows can come back, or what happens when column is unknown or a value matches nothing — an agent could still call it, but not predict the response.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: 'whose column is any of the given values' clarifies both the target parameter (column) and the any-of/OR matching semantics of values, which the bare schema does not convey. It also documents the output ordering tied to the values array. What it omits is whether column expects a header name versus an index, leaving one small 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?

Names the operation and the resource precisely: returns the dataset rows whose column matches any of the supplied values, with an intent tag ('X vs Y' questions). The mechanics (an OR-filter over one column) are clear even though the tool is named 'compare' rather than 'filter'. It does not explicitly contrast itself with siblings like dataset_search or dataset_top, 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?

The phrase 'for "X vs Y" questions' implies the usage scenario, giving the agent a rough trigger condition. However, it names no alternative tools and states no exclusions (e.g., how this differs from dataset_search when you want a keyword match rather than exact values), so the guidance remains implied 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 behavioral burden. It discloses the return contents (source, date, licence, citation) and implies a read-only lookup, but does not explicitly state side-effect absence, authentication needs, or output format.

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 what is returned and followed by the use case. Every phrase earns its place with no redundant repetition.

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 lookup with no output schema, the description fully explains the returned fields and the appropriate use. No critical information appears missing for an agent to select and 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?

The tool has zero parameters, so the rubric baseline is 4. The description adds no parameter detail because none exist; schema description coverage is 100% but moot here.

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

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

The description names the exact resource ('Commercial Refinance Quotes dataset') and enumerates the metadata returned: source, computation date, licence, and citation. It is clearly distinct from sibling dataset_* tools that query rows or statistics, though it lacks an explicit verb like 'returns' to reach 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?

It states when to read it: 'to attribute a figure correctly.' That gives clear context, but it does not name alternatives or say when not to use it (for example, use dataset_row or dataset_search for data values).

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

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

With no annotations, the description carries the full burden and does disclose the non-obvious matching semantics (exact equality, case-insensitive), which is genuine behavioral value. However, it says nothing about how many rows can come back, whether no-match yields empty or error, or any access/limit behavior, which is a meaningful gap for an unannotated tool.

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

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

A single front-loaded sentence with no filler; the exact-match qualifier is positioned immediately after the object it qualifies. It is a noun-phrase fragment rather than an imperative, which slightly blunts the action framing but keeps it tightly scoped.

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 lookup with no annotations and no output schema, the description covers the matching contract but omits the return shape (multiple rows vs one), cardinality limits, and empty-result behavior. Those omissions are minor for such a simple tool but leave the agent guessing at edge cases.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains that 'column' identifies the column to test and 'value' is what it is compared against, plus the case-insensitive comparison rule that the schema never states. It stops short of noting that 'column' should be a valid dataset column (cf. dataset_columns) or how nested/null values behave.

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 resource (rows of the Commercial Refinance Quotes dataset) and the precise matching operation (column equals a value exactly, case-insensitive), which tells an agent this is a point lookup rather than a broad query. It does not name the sibling it competes with (e.g., dataset_search), so differentiation is implied by the word 'exactly' rather than stated.

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

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

Usage is only implied: the exact/case-insensitive framing suggests this is for known-value lookups while dataset_search handles looser queries, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer the routing decision from sibling names alone.

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 does add genuine behavioral facts (case-insensitive matching, a hard cap of 50 rows), which is useful. However, it omits return shape, whether results are truncated silently at 50, and any auth or pagination semantics needed for a search tool.

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

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

A single front-loaded sentence that names the resource, the matching rule, and the cap with no wasted words.

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

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

For a two-parameter search with no output schema, the description conveys what matches and the cap, but does not describe the columns returned or result ordering, which matters given there is no output schema to fall back on.

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%: the query parameter is documented as 'text to look for in any cell', but limit is undocumented in the schema. The description partially compensates by clarifying case-insensitivity and the 50-row maximum, though it never explains the limit parameter's meaning or default, leaving a real 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 states a concrete operation on a concrete resource: returning rows of the Commercial Refinance Quotes dataset whose cells contain the query. It is clear what the tool returns, but it does not distinguish itself from siblings like dataset_row, dataset_top, or dataset_stats, so the agent must infer the boundary.

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 and no named alternatives among the sibling tools. The agent is left to infer that this is the free-text lookup vs. dataset_top or dataset_row, but nothing in the text says so.

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 behavioral burden. It usefully discloses that grouping commas and currency are handled and that non-numeric rows are excluded and counted, which is real behavioral detail. However, it does not describe return format, precision, missing-column behavior, or whether the operation is read-only.

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 lists the computed metrics first and then adds handling details. It is efficient and avoids filler, though the parenthetical detail slightly interrupts the 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 simple one-parameter statistics tool with no output schema and no annotations, the description covers the computed metrics and key data-handling behavior. It still omits return-value structure, precision, and empty/all-non-numeric edge-case behavior, leaving some gaps an agent may need to infer.

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% and the single parameter is not named in the description. The text implies that the column must be numeric and belong to the named dataset, which adds some semantic constraint, but it gives no valid column names, naming conventions, or format examples to compensate for the undocumented schema.

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

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

The description names exactly what the tool computes (count, min, max, mean, median, sum) for a numeric column of a specifically named dataset. This is a concrete verb+resource statement that an agent can easily distinguish from sibling tools like dataset_columns or dataset_top.

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 says what the tool does but gives no guidance on when to choose it over alternatives such as dataset_compare or dataset_top. There are no stated prerequisites, exclusions, or contexts for use.

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 does disclose the ranking direction and that both ascending and descending orders are supported, which is genuinely useful, but it says nothing about permissions, default limit behavior, or the shape of returned rows.

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

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

A single compact sentence that front-loads the core operation and appends the guiding phrase. Efficient with minimal waste, though the nested quotation marks read slightly awkwardly.

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?

A read-only ranking tool with no output schema and no annotations needs the description to cover return behavior and the limit parameter. The description omits limit entirely and gives no hint about the returned row set, leaving key operational details to be inferred.

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

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

Schema description coverage is only 33% (only 'ascending' is documented). The description adds the idea that the column must be numeric, but never mentions the 'limit' parameter, its default, or its 1-50 bound, so the low-coverage gap is not compensated.

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 (return highest/lowest rows) against a named resource (Commercial Refinance Quotes dataset), keyed by a numeric column. This distinguishes it from siblings like dataset_row and dataset_search, though it doesn't explicitly name any sibling it must not be confused with.

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 gloss 'which is the most/least X' implies the natural trigger condition (extremum/max-min questions), but there is no explicit when-to-use versus dataset_stats or dataset_compare, and no 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, the description carries the full behavioral burden and does disclose meaningful traits: nothing is bought, ordered or paid, no quote is guaranteed, it is free, and it returns consent wording and recipient information. This is solid disclosure about the downstream flow, though it says less about the tool's own read semantics (idempotence, freshness, scoping).

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?

Front-loaded with 'Read first', then two compact sentences covering behavior and return content. Efficient overall, though the middle clause about submit_enquiry is slightly circuitous given the tool's own 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?

There is no output schema, so the description rightly enumerates what comes back (recipients of details, consent wording, confirmation method). For a zero-parameter, no-annotation informational tool this is nearly complete; only the tool's own read semantics go unstated.

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

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

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Baseline 4 applies for a no-argument 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 frames the tool as a static explainer ('States plainly what submit_enquiry does'), and the final sentence reveals its own payload (who receives details, consent wording, confirmation step). The verb/resource are inferable but blurred: it reads as a description OF submit_enquiry rather than a tool named enquiry_describe, so an agent must work to see it as a standalone read-only informational resource.

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

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

'Read first' is an explicit sequencing cue relative to submit_enquiry, implying it should be consulted before submitting. However, no sibling alternatives are named and no conditions for when-not to use it are given; usage is implied rather than spelled out.

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 behavioral burden. It clearly describes the return content (key, label, type, required, help text, allowed options) but does not explicitly state that the operation is read-only, whether authentication is required, or any side-effect profile.

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 waste: the first front-loads the purpose and returned fields, the second gives a practical usage note. Every sentence 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?

No output schema or annotations exist, so the description must explain return values. It does so by enumerating the field attributes, but it omits the overall return shape (e.g., array of objects) and any ordering or pagination 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?

The tool has zero parameters, so the baseline of 4 applies. The description does not need to explain parameter semantics, and the absent schema properties are consistent with a no-argument metadata query.

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 verb (enumerate) and resource (fields of the Commercial Refinance Quotes enquiry) and lists the returned attributes. It does not explicitly contrast with the sibling enquiry_describe, so it falls 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?

The phrase 'Pass answers to submit_enquiry keyed by field key' gives a clear downstream use case, implying this tool should be called before submit_enquiry to discover field keys. No explicit when-not or alternative sibling comparison is provided.

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

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

With no annotations, the description carries the full burden and does so: it discloses validation behavior, what step 1 returns (summary, consent line, confirmation token), the human-agreement gate before step 2, the double-opt-in email with a link that must be clicked before any provider sees the data, and the exact text consent refers to. This is unusually complete for a mutation 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?

Front-loads the 'not a purchase' disclaimer, then structures the rest as Step 1 / Step 2. It is dense and runs long, but every clause conveys an operational constraint (gating, token, consent text) rather than 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?

No output schema exists, yet the description explains what step 1 returns and what happens downstream (email link, provider visibility), covering the return-value gap. Combined with the 100%-covered schema, an agent has everything needed to drive both calls 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 real meaning: answers are keyed by field key from the sibling enquiry_fields tool, consent=true maps to the quoted consent sentence, and 'confirmation' is the step-1 token to be supplied only after the person approves the summary. Minor gain over schema, hence 4 rather than 3.

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

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

States a specific verb and resource ('Submits an enquiry to Commercial Refinance Quotes') and immediately distinguishes itself with 'NOT a purchase, NOT a guaranteed quote', which matters given the sibling enquiry_* tools. An agent can identify the tool without opening the schema.

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

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

Gives an explicit two-step protocol: step 1 with answers and consent=true, step 2 only 'if the person agrees' with the confirmation token. It also names the intermediate action (show the summary and consent line to the person) that gates the second call. Nothing about when to invoke each step is left to inference.

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