site

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

With no annotations, the description carries the full burden. It discloses the output contents (columns, numeric flags, row count, provenance banner) and implies a read-only nature via 'learn the schema'. It does not state side effects or performance, but for a schema-introspection tool this is adequate.

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, dense sentence that front-loads the output contents and usage guidance. Every element earns its place with no fluff.

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 parameters and no output schema, the description fully specifies what the agent will receive. It is complete for its intended role as a schema-discovery 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 tool has zero parameters, so the baseline of 4 applies. No parameter descriptions are needed or provided; the description adds no parameter-specific meaning because there are none.

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 (call) and resource (Fax Line Index dataset), and enumerates exactly what it returns: columns, numeric flags, row count, and provenance banner. This clearly distinguishes it from siblings like dataset_provenance, which focuses solely on provenance, and dataset_row, which returns data rows.

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?

Explicitly instructs to 'call this first to learn the schema', establishing it as the entry point for understanding the dataset structure. This provides clear precedence over sibling tools, though it does not enumerate 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 full burden. It discloses the ordering behavior (rows returned in the order of the given values) and the matching logic (any of the values). However, it does not describe the output format, what happens when a value has no matches, or whether multiple rows per value are returned. This is a moderate disclosure.

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 (what rows are returned and in what order) and appends a concise usage hint. There is no wasted verbiage.

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 tool, the description covers the essential behavior: which dataset, which column, which values, and the ordering. It does not detail the return format or edge cases, but given the sibling tool suite and lack of an output schema, this is adequate for an agent to invoke it correctly.

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

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

Schema coverage is 0%, so the description must explain the parameters. It clarifies that 'column' is the field to match against, 'values' are the specific values to filter by, and the order of values dictates the output order. This adds semantic meaning beyond the raw schema 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 clearly states the tool returns rows from the Fax Line Index dataset filtered by a column matching any of the given values, in the order given. It also adds the use-case hint 'for X vs Y questions', which distinguishes it from siblings like dataset_row (single row) or dataset_search (broad search).

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

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

The description provides a clear usage context: comparing specific values (X vs Y). It does not explicitly name alternatives or state when not to use it, but the use-case hint and the explicit filtering logic imply when this tool is appropriate compared to siblings.

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

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

With no annotations, the description carries the full burden. It discloses exactly what information the tool returns (source, date, licence, citation) and implies a read-only nature via 'Read this.' It doesn't mention side effects, but for a static provenance lookup, this is sufficient and does not contradict any structured data.

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 key content (what it provides) is front-loaded, followed by a clear usage 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 simple, parameterless tool with no output schema, the description fully explains what will be returned and when to use it. Nothing an agent needs to call it 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?

The tool has zero parameters, so the baseline is 4 per the rubric. The description adds context about the purpose, but there are no parameter details to explain, so the baseline holds without penalty.

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 tool provides provenance details (source, computed date, licence, citation) for the Fax Line Index dataset. It uses a specific resource and distinguishes from sibling data-access tools by focusing on metadata rather than data operations.

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 gives an explicit use case ('Read this to attribute a figure correctly'), making clear when an agent should invoke it. However, it doesn't name alternatives or state when not to use it, though no direct sibling appears to offer the same provenance functionality.

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 must carry the behavioral disclosure. It does disclose the case-insensitive matching and the exact equality condition, which are useful behavioral traits. However, it does not mention what happens with multiple matches, whether the result set is ordered, or any potential errors or limitations, leaving gaps in transparency.

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 conveys the essential operation without wasted words. The key matching condition is front-loaded, and there is no redundancy or unnecessary detail.

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 but the description is thin. It does not explain the output format, whether multiple rows can be returned, error handling, or any constraints on the column parameter. Given the presence of sibling tools, the absence of usage guidance also weakens completeness. For an agent to correctly invoke this tool, more context is needed.

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. The sentence 'a column equals a value' implies that 'column' is the field name and 'value' is the comparison value, giving basic semantics. However, it does not clarify valid column names, case-sensitivity of column names, or any format constraints, leaving 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 clearly states the tool's function: it retrieves rows from a specific dataset where a column equals a given value exactly, with case-insensitivity. This is specific, uses a clear verb-resource structure, and distinguishes itself from dataset_search by emphasizing exact matching.

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 no guidance on when to use this tool versus alternatives like dataset_search, dataset_top, or dataset_stats. It does not mention when exact matching is preferred over fuzzy or pattern-based search, nor any exclusions or conditions.

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. It discloses case-insensitive matching and a maximum result count (50), but it does not state whether the operation is read-only, what the exact return format is (full rows vs. identifiers), or how results are ordered. These are meaningful gaps for a tool with no annotation safety hints.

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, no fluff, front-loads the key action and constraints. Every word adds information: 'Rows', 'cells contain the query', 'case-insensitive', 'up to 50'. This is an exemplary concise definition.

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 search tool with two parameters and no output schema, the description is largely sufficient. An agent knows what to pass and what to expect in general terms. It could improve by noting whether all columns are returned or if there is any ordering, but these are minor given the tool's simplicity and the presence of sibling tools that handle other use 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?

The schema covers the query parameter with 'text to look for in any cell', and the description adds case-insensitivity. The limit parameter has no schema description, but the description clarifies its meaning as 'up to 50', directly compensating for that gap. The description thus adds value beyond the schema for both parameters.

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 verb 'search' and the specific resource 'Fax Line Index dataset', and it distinguishes itself from siblings like dataset_row (retrieve by index) and dataset_top (top rows) by specifying that it returns rows whose cells contain the query. It also adds useful modifiers (case-insensitive, up to 50) that sharpen the 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 clear context: it is used to find rows matching a text query across all cells. It does not explicitly name alternatives or state when not to use it, but the purpose is unambiguous enough that an agent can infer it is the go-to tool for content-based search, not for retrieving specific rows or statistics.

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. It discloses useful behavior: formatted numbers are parsed and non-numeric rows are excluded/counted. It does not specify the output format or how missing/blank values are classified, which leaves part of the behavior undisclosed.

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 front-loads the returned statistics, then adds parsing and exclusion behavior. No wasted or repeated content beyond the title.

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 read-only statistics tool, the description supplies the dataset, the target column type, the computed values, and edge-case handling. It would benefit from stating the return shape, but it is enough for an agent to invoke it correctly.

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

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

Schema coverage is 0%, so the description is the only semantic source for the single column parameter. It communicates that column must refer to a numeric column of the Fax Line Index dataset and that formatted values are handled; this is adequate, though valid column names are not enumerated.

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 operation—compute count, min, max, mean, median, and sum—over a numeric column of a specific dataset. This is specific enough to distinguish dataset_stats from the search/row/top/columns 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 context of use is implied: use it when summary statistics for a numeric column are needed. However, it never states when not to use it or contrasts it with sibling tools such as dataset_top or dataset_search.

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 discloses that the tool returns top or bottom rows, but says nothing about the default sort direction, limit handling, behavior with non-numeric columns, ties, 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?

The description is short and front-loads the main action. The explanatory 'which is the most/least X' adds a bit of redundancy but keeps the intent readable; no significant wasted text.

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 annotations, no output schema, and sparse parameter documentation, the description leaves important operational details unstated, such as the limit default and maximum, default ordering, and expected return shape. An agent would need to inspect the schema further and still may not know the output semantics.

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%, and the description does not explain the 'column', 'limit', or 'ascending' parameters. The phrase 'by a numeric column' hints at the column parameter, but it does not compensate for the low schema 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 identifies the tool's job: returning the highest or lowest rows of the dataset by a numeric column, phrased as 'which is the most/least X'. This is distinct from sibling tools like dataset_row or dataset_stats, 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?

There is no guidance on when to use this tool versus alternatives such as dataset_stats or dataset_search. The 'most/least X' phrasing implies a ranking use case, but no explicit conditions, exclusions, or alternatives are 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 provided, the description carries the full burden of behavioral disclosure, and it succeeds. It explains that the tool returns a plain-language description, explicitly states that no purchase or payment occurs, clarifies that no quote is guaranteed, and lists the return contents: recipients, consent wording, and confirmation method.

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 three sentences with no filler. The imperative 'Read first' is front-loaded, the core purpose appears immediately, and the remaining sentences efficiently add scope, expectations, and return-value details without 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 documentation tool with no output schema and no annotations, the description is complete. It tells the agent what the tool does, what it does not do, and what information it returns, leaving no important gap for invoking or interpreting the 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 tool has zero parameters and 100% schema coverage by vacuity, so there is no parameter meaning for the description to add. The description instead focuses on what the tool returns, which is the only semantic information an agent needs for a parameterless documentation 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 states clearly that this tool explains what submit_enquiry does, using the specific verb 'States plainly' and naming the resource it documents. It also distinguishes itself from submit_enquiry by emphasizing that nothing is bought, ordered, or paid, and that it returns information rather than performing the 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 opening 'Read first' clearly signals that this tool should be used before submit_enquiry, and the description provides helpful context about what to expect. It does not explicitly name alternative tools or provide when-not-to-use conditions, but the usage context is clear enough for an agent to recognize this as the pre-submission explainer.

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?

There are no annotations, so the description carries the burden of explaining behavior. It does describe the output content well and implies this is a read-only introspection tool, but it does not explicitly state side-effect-free behavior, authentication needs, or response shape. For a simple field-list tool this is adequate but not richly transparent.

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 filler. The first sentence front-loads what the tool returns, and the second sentence provides an actionable connection to a sibling tool. 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?

There is no output schema, so the description must explain return values, and it does: it lists the fields and qualifiers (required, options, help text). It also gives a usage hook with submit_enquiry. Nothing essential for an agent to invoke and use this 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?

The tool has zero parameters, so there is nothing for the description to explain about inputs. The baseline for 0 parameters is 4, and the description adds useful context by noting that returned field keys are used as keys for submit_enquiry, which clarifies the meaning of one of the returned fields.

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 as returning all fields of the Fax Line Index enquiry and enumerates exactly what information is provided for each field: key, label, type, required status, help text, and allowed options. It also distinguishes itself from submit_enquiry by explaining that answers should be passed there keyed by field key. This makes the tool's 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 description conveys that this tool should be used to retrieve the enquiry structure before submitting answers, and explicitly directs the agent to submit_enquiry afterward. It does not explicitly mention when to use it over enquiry_describe or dataset_* siblings, but the context makes the intended workflow 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, and it succeeds. It reveals that the tool is stateful (requires a confirmation token from step 1), that submission triggers an email with a click link, that providers see the enquiry only after that click, and that consent has a specific definition. Side effects and consent implications are clearly 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 appropriately sized for a two-step, high-stakes submission tool, and it front-loads the most important caveat ('NOT a purchase, NOT a guaranteed quote'). The workflow is logically ordered into Step 1 and Step 2, and every sentence carries necessary operational or consent-related information without padding.

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 the tool's complexity and the absence of an output schema, the description provides complete operational context: prerequisites, return values of step 1, conditions for proceeding to step 2, and the post-submission outcome. An agent can correctly execute both steps and understand expected behavior without additional information.

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 already documents all three parameters at 100% coverage, so the baseline is 3. The description adds meaningful workflow semantics: answers are keys from enquiry_fields, consent must reflect the quoted agreement, and confirmation is the step-1 token used in the second call. This goes beyond the schema by explaining how the parameters interact across the two-step flow.

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 opens with a specific verb and resource: 'Submits an enquiry to Fax Line Index.' It explicitly disambiguates the action as 'NOT a purchase, NOT a guaranteed quote' and clearly separates the tool from the dataset_* siblings and the enquiry_describe/enquiry_fields tools. The two-step workflow reinforces exactly what operation this tool performs.

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 when-to-use instructions: call first with answers and consent=true, show the summary to the person, and only call again if the person agrees, passing the confirmation token. It also tells the agent where answers come from ('keyed by field key from enquiry_fields'), connecting this tool to a sibling prerequisite. The 'NOT a purchase' statement helps the agent avoid selecting this tool for purchase-like actions.

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