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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says the tool is the first question of a decision guide, without revealing whether calling it is read-only, whether it initiates a stateful flow, or what kind of output to expect. This is minimal behavioral 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?

The description is a single short sentence and is easy to scan. It repeats the phrase 'Which valuation approach fits?' from the title, but this redundancy is minor and the sentence still earns its place by specifying 'first question' and 'decision guide.'

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 starter tool, the description gives adequate positioning, but it leaves key context implicit: what the agent should expect upon invoking it, whether it displays a question, and how it relates to the other checker_* tools. Since there is no output schema or annotations, the description is the sole source of this information and could be more explicit.

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 already covers this completely. The description is not expected to add parameter-level detail, and the baseline of 4 for zero parameters 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 states the tool is 'the first question' of the 'Which valuation approach fits?' decision guide, clearly identifying it as the entry point to a specific workflow. It is distinct enough from siblings like checker_answer and checker_tree because 'first question' signals its sequential role, though it lacks an explicit action verb.

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 rather than explicit: being 'the first question' suggests it should be invoked before the other checker tools, but no alternatives are named and no 'when not to use' guidance is given. An agent can infer the intended context but is not directed toward or away from any sibling.

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 explaining behavior. It does disclose the full scope of content—every question, option, and verdict—but it does not describe the output format, whether the tool is static/read-only, or how interactive guidance tools relate to it. This is acceptable for a content-reference tool 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, tightly worded sentence that immediately conveys the tool's scope and purpose. Every word earns its place, and the most important information—'whole decision tree'—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?

For a parameterless tool with no output schema, the description sufficiently explains what the tool provides: the complete set of questions, options, and verdicts for end-to-end reasoning. It could additionally mention the response format or how it relates to the step-by-step checker siblings, but these are minor gaps given the tool's simple nature.

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 confirms this with 100% coverage. The description adds no parameter-specific meaning, but none is needed; the baseline of 4 for a parameterless tool 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 identifies the tool as providing the complete decision tree for the 'Which valuation approach fits?' guide, including every question, option, and verdict. The phrase 'whole decision tree' differentiates it from step-by-step siblings like checker_start and checker_answer, though it lacks an explicit verb.

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 implies the tool is for reasoning through the entire guide end to end, which signals when it is useful. However, it does not explicitly state when to choose this tool over sibling tools such as checker_answer or checker_start, nor does it give exclusions or alternative 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, the description carries the full burden, and it covers the key behavioral caveats: nothing is bought, ordered, paid, or guaranteed, and the tool returns specific information (recipients, consent wording, confirmation method). It stops short of explicitly stating that enquiry_describe itself is read-only and has no side effects, but the informational framing strongly implies this.

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 compact and front-loaded: 'Read first' comes first, followed by the core purpose, the key disclaimers, and the return-value summary. No sentence is redundant; each adds a distinct piece of useful information.

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, this is complete: it says what the tool does, what it returns, and the important domain caveats about purchase and quote guarantees. The sibling context reinforces that this tool is the explainer for submit_enquiry, and the description fully supports that role.

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 and schema description coverage is 100%, so there is no parameter ambiguity for the description to resolve. The baseline of 4 applies because the description does not need to add anything beyond the empty 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 explicitly names the resource (submit_enquiry on Business Value Now) and the verb ('states plainly' / 'describes'), and the title frames it as an informational overview. It is clearly distinguished from the sibling submit_enquiry: one explains the enquiry flow, the other performs 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?

The opening 'Read first' signals this tool is the preliminary step before submit_enquiry, and the rest explains what an agent will learn. It gives clear context for when to call it but does not explicitly enumerate alternatives or state 'use this instead of X,' though the sibling context makes the intent obvious.

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 transparently explains what the tool returns (field metadata) and that 'allowed options' appear only where applicable. It also discloses the relationship to submit_enquiry, which is helpful. It doesn't explicitly state read-only behavior, but the descriptive nature of the content strongly implies a safe lookup with no side 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 two sentences with no wasted words. The first sentence enumerates the exact content returned, and the second provides a practical link to submit_enquiry. It is well-structured and focused.

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?

Despite having no output schema, the description sufficiently specifies the return content and its purpose. It names all field attributes, mentions conditional options, and explains how to use the result (keys for submit_enquiry). Given the tool takes no parameters, the description is complete for an agent to invoke and 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 tool has zero parameters and an empty input schema, so the description need not explain parameter semantics. The baseline for 0 params is 4. The description's mention of 'field key' indirectly clarifies the meaning of a term relevant to the submit_enquiry tool, but no parameter-specific detail is required 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's purpose: it provides every field of the Business Value Now enquiry, including key, label, type, required flag, help text, and allowed options. The title reinforces this as 'the questions the enquiry asks'. However, it does not explicitly differentiate itself from sibling enquiry_describe or other tools, and it lacks a direct verb like 'lists' or 'returns'.

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 actionable context: 'Pass answers to submit_enquiry keyed by field key.' This tells the agent how to use the retrieved field keys, implying the tool is a prerequisite for submission. However, it does not explicitly state when to use this tool versus alternatives like enquiry_describe, nor does it mention 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 behavioral burden and it does so thoroughly. It discloses the two-step stateful nature, the validation return, the consent line to show the user, the email with a click-through link, and the exact consent text. This is far beyond what the empty annotations provide.

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 long but every sentence earns its place: it front-loads the critical 'not a purchase' caveat, then uses a clear Step 1/Step 2 structure. The consent text is included exactly as required, and no redundant filler is present.

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 complex two-step tool with nested objects and no output schema, the description is remarkably complete. It covers the full workflow, what to show the user, when to call again, the email link requirement, and the consent condition. Nothing essential to invoking the 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?

Schema coverage is 100%, but the description enriches the parameters by explaining their role in the workflow: answers are keyed by field key from enquiry_fields, consent must be true in both steps, and the confirmation token is the link between step 1 and step 2. This adds operational meaning beyond the schema's field descriptions.

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 purpose: 'Submits an enquiry to Business Value Now' and immediately disambiguates it with 'NOT a purchase, NOT a guaranteed quote.' This aligns with the title and makes it distinct from the sibling tools, which center on checking or describing enquiries rather than submitting them.

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 step-by-step usage context: call once with answers and consent to get a summary and confirmation token, then call again with the token only after the person agrees. It also references enquiry_fields as the source of answer keys, implying prerequisite knowledge, but it does not explicitly name alternative tools or state when not to use this one.

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