site

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 key behavior—returning either the next question or a final verdict—but it does not mention whether the flow state is mutated, what happens for invalid choices, or any session/state 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?

A single, information-dense sentence. The title and description work together without repetition or filler, and the key input/output behavior is front-loaded.

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?

Adequate for a two-parameter tool: it names both inputs and describes the possible return. However, with no output schema and no annotations, it falls short of fully describing the response shape, error behavior, or what the caller should do with the returned next question/final verdict.

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

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

The schema has 0% description coverage, so the description's clarification that `question` is a question id and `choice` is the chosen option's index is essential. It adds meaning beyond the raw property names and types, though it omits details like how to obtain valid question ids or bounds beyond minimum 0.

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 operation: given a question id and a choice index, return the next question or final verdict. This clearly differentiates it from sibling tools like checker_start or checker_tree, which have different roles in the flow.

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: use this when a user has answered a question and the flow should advance. However, it does not explicitly state when not to use it, what prerequisites exist (e.g., starting with checker_start), or how it relates to alternatives.

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 this is the first question; it does not say whether calling it initializes a session, returns a question, or has any other effects.

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 concise sentence with no filler, and it front-loads the essential information about being the first question. It is under-specified in behavior, but structurally it is efficient.

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

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

For a zero-parameter starter tool, the description minimally conveys the entry-point role. However, with no annotations or output schema, it would benefit from saying what the caller should expect in the response and how to continue the guide using sibling tools.

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 description does not need to explain parameter meaning. The baseline of 4 applies because there is nothing to document and the description does not interfere with that.

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 ('Indicative steel beam checker decision guide') and its role as the entry point ('first question'). It is clear but does not explicitly differentiate itself from siblings like checker_answer 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?

The word 'first' implies this tool should be used to start the decision guide, before checker_answer or checker_tree. However, there is no explicit guidance on when to use it versus alternatives, leaving the usage context mostly implied.

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. It states what content is included—every question, option, and verdict—but does not describe the response format, whether this is a static read-only snapshot, or how the tree is structured. For a zero-parameter tool 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 a single compact sentence with no wasted words. The core scope—'every question, option and verdict'—is front-loaded, and the purpose qualifier 'for reasoning end to end' is useful. It is appropriately sized for the tool's simplicity.

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 that the tool has no parameters and no output schema, the description gives enough context for an agent to understand that this is the full decision tree resource. It does not explain how the tree relates to checker_start or checker_answer, but for a simple content-retrieval tool it is substantially complete.

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

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

The tool accepts no parameters, so the empty schema fully documents the call signature. The description does not need to explain parameter behavior, and the schema coverage is 100%. The baseline of 4 for a zero-parameter tool applies 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 clearly identifies the tool as containing the full set of questions, options, and verdicts for the Indicative steel beam checker guide. It distinguishes itself from the step-by-step siblings by emphasizing 'the whole decision tree' and 'reasoning end to end.' However, it lacks an explicit action verb like 'returns' or 'provides,' so it is clear but slightly under-specified.

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 this tool is meant for situations where the agent needs the complete decision tree rather than incremental checker steps. It does not explicitly name alternatives like checker_start or checker_answer or state when not to use them. Usage guidance is therefore present but only implied.

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 explicitly states that nothing is bought, ordered, or paid, that no quote is guaranteed, that the process is free, and that the returned content covers recipients, consent wording, and confirmation. This makes the tool's non-transactional, informational nature 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 short, front-loads the actionable instruction 'Read first,' and packs specific output details into two concise sentences. Every clause adds value: the process, the key disclaimers, and exactly what the returned explanation covers.

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 and no annotations, the description is complete. It tells the agent what the tool returns, why that information matters, and how it relates to the submit_enquiry flow, so no further documentation is needed to use it correctly.

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

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

The schema has zero parameters with 100% coverage, so the baseline of 4 applies; there is no parameter semantics for the description to add. The description appropriately focuses on return content and behavior rather than 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 a verb ('states') and a specific resource ('what submit_enquiry does on Steel Beam Checker'), and the title reinforces that this tool is informational rather than transactional. It is easily distinguished from submit_enquiry because it explicitly positions itself as describing that action rather than performing it.

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 opens with 'Read first,' which clearly signals to the agent that this tool should be invoked before taking submission-related actions. It references submit_enquiry and explains what the user gets, so the primary use case is clear, though it does not explicitly list when-not-to-use or alternative tools.

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

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

No annotations are provided, so the description carries the behavioral burden. It is explicit that the tool returns a catalog of fields and their attributes, and the language implies a read-only metadata lookup. It does not discuss authentication or side effects, but those are less relevant for a zero-parameter query tool.

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

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

The description is two compact sentences with no filler. The first sentence lists the returned content clearly; the second sentence explains how the result should be used with submit_enquiry.

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 zero-parameter metadata lookup, the description covers what the tool returns and how it relates to submission. It could more explicitly state that it is the pre-submission source of field keys, but no critical information 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 and the schema has no properties, so there is nothing for the description to clarify about arguments. The baseline of 4 for zero-parameter tools applies 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 clearly states the tool exposes every field of the Steel Beam Checker enquiry and enumerates the metadata included: key, label, type, required, help text, and options. It also connects the result to submit_enquiry, which helps differentiate it from submission. It does not explicitly contrast with enquiry_describe, so it stops 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?

The usage guidance is implied: 'Pass answers to submit_enquiry keyed by field key' suggests this tool should be consulted before submitting answers. There is no explicit when-to-use vs. alternatives such as enquiry_describe, checker_start, or checker_tree, and no when-not-to-use instruction.

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: it discloses validation behavior, what gets returned (summary, consent line, confirmation token), the exact consent semantics quoted in full, and the downstream email-confirmation gate before any provider sees the data. This is unusual depth 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-loaded with the constraint and the two steps, and every sentence earns its place — except the consent text, which is reproduced verbatim and already lives in the schema's consent property description. Slight redundancy, but structure and ordering are strong.

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 must explain returns — and it names all three (summary, consent line, confirmation token) plus the downstream email link. Given the nested answers object and the multi-step flow, this is complete enough to invoke 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 must be keyed by field keys sourced from enquiry_fields, and it spells out which parameter set each step requires. The confirmation token's role is already covered in the schema, so this is additive rather than essential.

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 Steel Beam Checker') and immediately bounds what it is not ('NOT a purchase, NOT a guaranteed quote'). An agent can distinguish this from checker_* siblings purely from the description.

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 procedure with the condition that selects each call ('Step 1: call with...' vs 'Step 2: only if the person agrees...'). The gating condition for the second call is unambiguous, so nothing 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.