site

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 what is returned (including the unusual "provenance banner"), which implies a safe read-only operation, but says nothing about cost, permissions, or pagination. Adequate for a zero-parameter read but not rich.

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 enumerates the return payload, followed by a short directive on when to call it. No filler, nothing to trim.

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

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

With no output schema, the description usefully enumerates the returned fields, compensating for the missing return contract. It is nearly complete for a zero-param read tool, though the phrase "provenance banner" is unexplained and the output format is not characterized.

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 no parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly adds no parameter noise.

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 specifically what it returns: columns, which are numeric, row count, and provenance banner of a named dataset. That verb+resource framing lets an agent know exactly what it gets. It doesn't explicitly contrast itself with dataset_provenance or dataset_stats, which invites some overlap confusion.

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 a clear ordering directive that tells the agent when to reach for this tool relative to the other dataset_* tools. It stops short of naming alternatives or exclusions, so it is clear context rather than full routing guidance.

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

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

With no annotations, the description carries the full burden. It describes a read-style retrieval and preserves the order of supplied values, but omits side-effect/read-only disclosure, permissions, return shape, and pagination—notable gaps for a tool with no annotations or 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?

A single sentence with no filler, and the core retrieval rule is front-loaded. Its structure is a noun phrase rather than a direct action statement, which slightly weakens immediate scanability.

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 retrieval tool, the description covers the basic return concept (rows from the dataset) and use case. But with no output schema and 0% schema description coverage, it should do more to describe the response shape or invocation constraints.

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 names both parameters and adds the key semantic that values are matched against a column and that the order of values is preserved, but it does not clarify equality syntax, column format, or the array min/max 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?

States a specific resource (rows of the EntitySearch HQ dataset) and the filtering rule (column values), and gives a use-case cue ("X vs Y" questions). It distinguishes the tool from generic search or row retrieval only implicitly, without naming alternatives.

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 implied usage context ("for 'X vs Y' questions") but does not state when to prefer this over siblings like dataset_search, dataset_row, or dataset_top. No exclusions or prerequisites are given.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It does implicitly signal a safe read-only operation by describing static metadata, but says nothing about caching, freshness guarantees, permissions, or the response shape. For a zero-parameter read, the residual risk is low, so this is adequate rather than poor.

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

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

Two sentences, no filler. The returned fields are front-loaded and the actionable instruction comes second, which is the right ordering for an agent scanning for a purpose.

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

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

With no output schema, the description must convey what comes back, and it does by listing the four data points (source, date, licence, citation). Anything further, such as exact field names or citation formatting, would be a nice-to-have rather than a gap that would cause a mis-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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The schema is empty and consistent with a no-argument metadata lookup.

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

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

The description names a specific resource (the EntitySearch HQ dataset) and enumerates exactly what it returns: source, computation date, licence, and citation. That scope is unambiguous against siblings like dataset_columns, dataset_stats, or dataset_row, none of which expose attribution metadata.

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

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

"Read this to attribute a figure correctly" gives a clear triggering condition for using the tool. It stops short of naming alternatives or stating when-not-to-use it, but for a single-purpose metadata endpoint no realistic confusion exists.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose a genuine behavioral trait beyond the schema: matching is exact and case-insensitive. However it says nothing about multiplicity (how many rows can come back), no-match behavior, or result limits, which are the traits an agent needs most for a lookup tool.

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

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

A single sentence with no filler, and the resource and matching rule are front-loaded. It is efficient, though the brevity edges toward under-specification rather than tightness.

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 read tool with no output schema and no annotations, the description is close to complete on inputs but thin on outputs. It implies plural rows via 'the rows', but does not state whether the result is bounded, paginated, or empty on no match, which the missing output schema leaves entirely unspecified.

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 schema alone tells an agent nothing about 'column' or 'value'. The description partially compensates by establishing that a column is compared against a value with exact, case-insensitive semantics, which is meaningful added meaning over the bare string types.

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 (rows of the EntitySearch HQ dataset) and the precise selection rule (a column equals a value exactly, case-insensitive), so the operation is understandable. It does not explicitly contrast with the sibling dataset_search, which likely serves the fuzzy/full-text lookup case, leaving the boundary to be inferred.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of an alternative. With dataset_search in the sibling list, a sentence like 'use when you know the exact value; use dataset_search for free text' would have been the natural guidance, and its absence is a real gap.

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

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

With no annotations, the description carries the full burden, and it does disclose two real behavioral traits: matching is case-insensitive and results are capped at 50 rows. It omits result ordering, the default when limit is absent, whether matching spans multiple columns or requires all terms, and any performance/rate-limit context.

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

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

A single sentence that front-loads the resource and match rule and ends with the result bound. No filler, nothing redundant or buried.

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 tool with no output schema and no annotations, the description gives the essential result shape and size, but leaves the default limit and result ordering unspecified. An agent can call it, but cannot predict the response ordering or what happens without limit.

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' is described in the schema and restated in prose ('cells contain the query'), while 'limit' is only documented via its maximum. 'Up to 50' in the description mirrors the schema's maximum:50 rather than adding new meaning about defaults or ordering.

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+resource: rows of the EntitySearch HQ dataset matching a query, with the case-insensitive any-cell match called out. It is distinguishable from dataset_columns/dataset_stats by the 'rows ... contain the query' phrasing, though it never explicitly contrasts with dataset_row 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?

There is no statement of when to use this tool rather than its many siblings (dataset_top, dataset_row, dataset_compare) and no exclusions or prerequisites. The agent must infer usage from the name 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, and it does disclose real behavior: grouping commas and currency symbols are parsed, and non-numeric rows are excluded and counted. However, it omits what happens if the column contains no numeric rows, whether errors are raised for wholly non-numeric columns, and nothing about output ordering or response shape.

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 dense sentence, front-loaded with the returned metrics and followed by a parenthetical for edge-case handling. Every clause earns its place; only the absence of a leading verb phrase ('Compute…') keeps it from being ideal.

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 single-parameter tool with no output schema, the description usefully enumerates the return values and the data-cleaning rules, which is the key information an agent needs. The remaining gap is failure behavior for non-numeric or empty columns.

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% — the single 'column' parameter has only a minLength constraint and no description. The description compensates partially by specifying that the column must be numeric and belong to the EntitySearch HQ dataset, which is meaningful guidance, but it does not explain accepted column-name forms or matching rules.

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 enumerates the exact operation — computing count, min, max, mean, median and sum for one numeric column of the EntitySearch HQ dataset. This clearly separates it from siblings like dataset_columns or dataset_row. It never explicitly names an alternative tool, so it falls short of full sibling 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?

No when-to-use or when-not-to-use guidance is given. An agent must infer that this is for single-column numeric summarization versus dataset_compare (multi-column comparison) or dataset_top (leaderboards) from the wording alone. The constraint that the column must be numeric is stated, but no routing advice accompanies 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 behavioral burden. It conveys the sort direction toggle and that results are a ranked subset (a read operation), but says nothing about permissions, the 50-row cap on results, pagination, or the return shape—significant gaps for a tool with zero annotation coverage.

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

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

A single front-loaded sentence that leads with the operation and scopes it to the dataset. Efficient, though the em-dash aside is slightly informal and could be tightened.

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 low-complexity read tool with no output schema, the description covers the core operation but omits the result cap (limit ≤ 50), default ordering behavior details, and how the returned rows are shaped. Adequate but with clear gaps for an agent selecting and invoking 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?

Schema coverage is only 33% (only `ascending` is documented in-schema). The description adds one crucial constraint not present elsewhere: the `column` must be numeric. That partially compensates, but `limit` behavior and the column-identification format remain undocumented in both description and 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?

States a specific verb+resource: returns the highest/lowest rows of the EntitySearch HQ dataset ranked by a numeric column, with the query intent ('which is the most/least X') made concrete. It is clearly distinguishable from list/search siblings by the ranking semantics, though it never names an alternative 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 'which is the most/least X' framing implies the use case (extremal questions), but there is no explicit when-to-use guidance, no mention of when to prefer dataset_search or dataset_stats, and no stated prerequisites. Usage is inferred rather than directed.

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 and does so well: it discloses that nothing is bought, ordered or paid, that no quote is guaranteed, that it is free, and what supplementary content is returned (recipient details, consent wording, confirmation flow). It stops short of confirming the tool itself has no side effects or noting any auth requirements.

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, front-loaded with the imperative 'Read first.' and then a compact enumeration of what the tool discloses. Efficient, though the second sentence packs several ideas together and could be marginally tighter.

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, so the description is the only source of return-value information, and it enumerates the key returns (who receives the details, consent wording, confirmation flow). For a zero-parameter read tool this is nearly complete, missing only explicit confirmation that it is side-effect-free.

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

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

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The description appropriately focuses on output content rather than inventing parameter semantics.

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 role: it explains what submit_enquiry does (starts an enquiry with human providers who quote directly) and returns consent/recipient details, which clearly distinguishes it from the sibling submit_enquiry (action) and the dataset_* tools (data access). The phrasing is slightly meta ('states plainly what X does') rather than a direct verb+resource for the tool itself, which keeps it from 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?

'Read first.' is a front-loaded directive that implies calling this before submit_enquiry, but it never names submit_enquiry explicitly as the alternative or states when this tool would be inappropriate. The ordering intent 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, and it does disclose the shape of the returned data (the per-field attributes). It omits explicit statements that the call is read-only, side-effect free, or how options are populated, which would round out the 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 tight sentences: the return contents are front-loaded and the actionable follow-up (key your answers by field key for submit_enquiry) comes second. 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?

With no output schema and no annotations, the description needs to describe the payload, and it does list the field attributes returned. It stops short of confirming read-only semantics or explaining how the results are ordered, but it is sufficient 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 takes zero parameters, so the baseline is 4. The description still adds useful framing by defining the 'field key' concept that downstream calls depend on, which the empty schema cannot convey.

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 resource and enumerates the exact payload (key, label, type, required, help text, options), so an agent knows it returns enquiry field metadata. It does not, however, distinguish itself from the sibling enquiry_describe, leaving some ambiguity about which enquiry-metadata tool to pick.

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 implies usage by instructing 'Pass answers to submit_enquiry keyed by field key', which tells the agent this feeds the submission flow. But there is no explicit when-to-use statement or routing against enquiry_describe, so the guidance is inferred rather than stated.

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

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

With no annotations provided, the description carries the full burden and does: it discloses validation behavior, the exact return contents of step 1 (summary, consent line, confirmation token), that submission triggers an email requiring a click before providers see anything, and the literal consent statement. Mutation semantics, side effects and the double-opt-in are all explicit.

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 the key differentiator ('NOT a purchase') and organized as Step 1/Step 2, which is the right structure for a two-call tool. It is dense but every clause is load-bearing; the verbatim consent quote adds length, though it is arguably necessary for the agent to display it.

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 nested-parameter, no-output-schema mutation tool, the description compensates fully: it names the return payload of each call, the downstream email/click flow, and the consent text. Nothing an agent needs to invoke either step correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: answers are keyed by field key obtained from enquiry_fields, consent must be true only after agreement, and confirmation is the step-1 token used on the second call. That maps each parameter to the two-step workflow rather than just restating it.

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 (submit) and resource (enquiry to human providers) and immediately fences off the wrong mental model with 'NOT a purchase, NOT a guaranteed quote'. An agent can distinguish this from the dataset_* siblings and the enquiry_describe/enquiry_fields helpers without opening any 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 explicit when-to-call guidance for both steps: step 1 with answers+consent, step 2 only when the person has agreed and with the confirmation token. It also states what must be shown to the person between steps, so the agent knows the precondition for the second call.

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