site

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

With no annotations, the description carries the full burden, but it only describes the input-to-output mapping. It does not disclose whether answering advances or mutates checker state, whether repeated calls are safe, or whether the call 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?

A single sentence packs purpose, key parameter meaning, and the two possible result types with no filler. It is front-loaded and easy to scan.

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 should explain the shape of the returned question or verdict and how to distinguish the two outcomes. It also does not say where the question id comes from, which an agent needs to chain 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 0%, so the description must add meaning. It does clarify that 'question' is actually a question id and that 'choice' is the index of the selected option, which goes beyond the bare schema.

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

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

The description states a clear input (question id + choice index) and an unambiguous output (next question or final verdict). It identifies the tool's role in the checker flow, though it does not explicitly contrast it with siblings like checker_start or checker_tree.

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 implied: call it when the user has answered a checker question and the next step is needed. It offers no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as checker_start or checker_tree.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool is the first question; it does not disclose whether invoking it initializes or resets state, whether it has side effects, or what the returned question looks like.

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 is immediately clear and contains no filler. It front-loads the core purpose in minimal space.

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 no-parameter start tool this is near-adequate, but because there is no output schema and no annotations, an agent still lacks details on the return format and the expected next step after the first question. The sibling names hint at a flow, but the description itself does not complete the picture.

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

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

The tool has zero parameters and the schema is fully covered, so the description does not need to add parameter meaning. This meets the zero-parameter baseline.

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 identifies the tool as the first question of the Towing capacity checker decision guide, making its role as the entry point clear. It does not explicitly differentiate it from siblings like checker_answer or checker_tree, but 'first question' conveys enough to avoid 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?

Use at the start of the checker is implied by 'first question,' but there is no explicit guidance about when to choose this tool over checker_answer or checker_tree, nor any mention of prerequisites or exclusions. The usage context is implied rather than stated.

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

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

With no annotations provided, the description must carry the behavioral transparency burden. It does convey that the tool exposes the complete set of questions, options, and verdicts, which implies a read-oriented, full-content response. It does not mention output format, potential size, or whether this is a static representation versus an interactive guide.

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, efficiently worded sentence. It front-loads the content scope and immediately adds the end-to-end reasoning purpose. Every phrase earns its place with no redundancy or filler.

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

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

For a zero-parameter tool with no output schema, the description reasonably covers what the tool is and what it returns. It could be more complete by noting how the tree should be used alongside checker_answer and checker_start, or by describing the response format, but it is sufficient for basic selection and 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?

There are zero parameters, so the schema coverage is effectively complete. The description correctly focuses on the returned content rather than parameter details, which are unnecessary here. The baseline for no-parameter tools applies.

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

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

The description clearly states what content the tool provides: every question, option, and verdict of the Towing capacity checker guide. This identifies a specific resource and distinguishes it as the whole tree, though it lacks an explicit verb like 'return' or 'retrieve' and does not name sibling tools.

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 reasoning end to end' implies when this tool should be used: when the agent needs the full decision structure rather than a single step. However, it does not explicitly exclude alternatives like checker_answer or checker_start, nor explain how the tree relates to them.

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 burden of behavioral disclosure. It usefully states that nothing is bought, ordered, or paid, no quote is guaranteed, and the enquiry is free, which prevents costly missteps. It also discloses what the tool returns: recipient details, consent wording, and confirmation behavior. It does not explicitly say 'this tool itself sends nothing', but its informational nature is strongly implied.

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-loaded with 'Read first', which gives immediate usage priority. The caveats are packed efficiently. There is mild redundancy with the title ('not a purchase, not a guaranteed quote' appears in both), but the description remains compact and each clause earns its place.

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

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

For a zero-parameter, informational tool with no output schema, the description is complete: it explains what the tool is for, reassures about cost and commitment, names the sibling that actually submits, and lists the key content returned. An agent has everything needed to decide when to call it and what to expect back.

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

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

The tool has zero parameters, so the schema already trivially covers 100% of inputs. The description adds context about what the returned explanation covers, which is reasonable. There is no parameter burden for the description to carry beyond this.

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 (an ENQUIRY on Towing Capacity Checker) and the tool's job: to state plainly what submit_enquiry does, i.e., describe the outcome before anything is submitted. The title reinforces this by framing it as 'What you get'. It is clearly distinguished from sibling tools like submit_enquiry and checker_answer because it is positioned as the 'read first' explainer.

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

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

The opening imperative 'Read first' explicitly tells the agent to use this before acting on the enquiry flow. It also clarifies that this is not a purchase or guaranteed quote and names submit_enquiry as the actual submission sibling. It could more explicitly say 'use submit_enquiry only after this is read', but the intent is clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It describes the data content of the tool (keys, labels, types, etc.) and implies a read-only lookup, but does not explicitly state that it has no side effects or describe the response format. This is adequate but not fully 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: the first states exactly what the tool provides, and the second gives the follow-up action. It is concise, front-loaded, and every word contributes value.

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

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

For a zero-parameter tool with no output schema, the description adequately communicates what the agent will receive: field definitions including keys, labels, types, required flags, help text, and options. It could explicitly mention the return shape (e.g., an array or object), but the given content is sufficient for correct usage.

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 an empty input schema, so the baseline for parameter semantics is 4. The description adds value by explaining how the output keys relate to submit_enquiry, which indirectly clarifies the output schema's purpose.

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 resource as every field of the Towing Capacity Checker enquiry and enumerates the attributes included (key, label, type, required, help text, allowed options). It lacks an explicit verb like 'lists' or 'returns', and does not directly differentiate from siblings such as enquiry_describe, but the scope is unambiguous.

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 second sentence gives concrete usage context: 'Pass answers to submit_enquiry keyed by field key,' which tells the agent how the output should be consumed. It does not explicitly mention when to avoid this tool or name alternatives, but the connection to submit_enquiry provides clear practical 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 provided, the description fully communicates the tool's behavioral contract: two-step validation, summary and consent-line return, confirmation token reuse, email with a required click-through, and the exact consent wording. It also discloses that providers only see the enquiry after the person clicks the emailed link.

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?

Although lengthy, the description is efficiently structured with numbered steps and front-loaded disclaimers. Every sentence adds necessary operational detail, and the consent line is quoted exactly, reducing ambiguity for the agent.

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 two-step flow, required inputs, returned values, consent semantics, and post-submission email behavior are all fully explained. There is no output schema, so the description's coverage of expected returns and side effects 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 schema already describes all three parameters, so the baseline is 3. The description adds valuable workflow semantics beyond the schema: answers come from enquiry_fields, consent=true is mandatory in both steps, and confirmation is the token returned in step 1. This clarifies how the parameters relate across the two-step call sequence.

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 'Submits an enquiry to Towing Capacity Checker' and explicitly differentiates it from a purchase or guaranteed quote. The two-step nature and human-provider target are immediately evident, distinguishing it from the sibling checker_* tools.

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 clear step-by-step guidance on when and how to call the tool, including requiring consent=true and reusing the confirmation token in step 2. It does not explicitly name sibling alternatives or state when not to use this tool, but the unique submission purpose and detailed flow make usage clear.

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