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 must carry the full behavioral disclosure burden. It only says the tool is the first question; it does not state whether invoking it starts a session, returns a question, or alters any state. This leaves the agent uncertain about the actual effect of the call.

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 with no filler or redundancy. It efficiently communicates the tool's role without repeating the title or adding unnecessary content.

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 0-parameter tool, the description provides enough context to identify it as the starting point, but with no output schema and no annotations, it should say what the agent will get back or what happens when called. The missing return/state details are the main gap.

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 there is no parameter meaning for the description to add. The baseline of 4 for a 0-parameter tool is appropriate.

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 a specific resource, the 'Which model should sell your business?' decision guide, and its position as the first question, which helps distinguish it from checker_answer and checker_tree. It lacks a strong action verb like 'starts' or 'returns,' so it is clear but not maximally explicit.

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?

'First question' implies this is the entry point before the answer and tree siblings, but it never names alternatives directly or states when not to use them. The usage context is implied rather than explicitly instructed.

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 behavioral burden. It clearly discloses the output scope (all questions, options, verdicts) and the purpose (end-to-end reasoning), making it evident this is a read-only content accessor. It does not discuss return formatting, but for a zero-parameter static data tool this is a minor omission.

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 clean sentence with no filler; the core content scope ('Every question, option and verdict') is front-loaded before the purpose clause. The title reinforces it without redundancy.

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 is largely complete: it names the guide, the included elements, and the intended reasoning use case. The only missing piece is an explicit statement of return format, which is not critical given the simple static 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 input schema has zero parameters and 100% coverage, so the baseline is 4. There are no parameters for the description to elaborate, and the tool's no-input nature is consistent with 'the whole decision tree'.

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 exactly what the tool provides: every question, option, and verdict in the named decision-tree guide, for end-to-end reasoning. The 'whole decision tree' scope clearly distinguishes it from sibling tools like checker_answer and checker_start, which cover narrower steps.

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 is implied by 'whole decision tree' and 'for reasoning end to end' — an agent can infer this is for full-tree context rather than a single step. However, no explicit when-to-use or when-not-to-use guidance is given, and alternatives like checker_answer or checker_start are not named.

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 clarifies that the workflow involves no purchase, no payment, and no guaranteed quote, and it states that the tool returns specific explanatory content. This makes the informational/read-only nature evident, though it never explicitly says this tool itself has 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?

Every sentence earns its place: read-first guidance, what the tool does, what it does not do, and what it returns. The description is front-loaded with 'Read first.' and remains compact with no 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, no-output-schema explanatory tool, the description is complete enough. It covers purpose, key caveats, and the nature of the returned information, so an agent can invoke it and understand the outcome.

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 schema description coverage is 100%, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, the description does not need to add parameter detail.

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 action: it 'states plainly what submit_enquiry does' and enumerates the return content ('who receives the details, the consent wording, and how the person confirms'). This clearly separates it from submit_enquiry, though it does not explicitly differentiate it from other sibling tools like enquiry_fields.

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 acting, and the description positions it as the explanatory precursor to submit_enquiry. It provides context (Broker vs Advisor) but does not explicitly state when not to use it or name 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It explains what information the tool exposes and clarifies that actual submission happens through submit_enquiry, not this tool. It does not mention side effects or auth, but for a metadata/field-listing tool that gap is minor.

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 wasted words. The first sentence states the content of the returned fields; the second gives actionable guidance for using them. Information is front-loaded and scannable.

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 introspection tool, the description is complete: it enumerates the output contents and connects them to the related submission tool. The absence of an output schema is compensated by the explicit field list in the description.

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. The description adds useful semantic context about the output fields, even though it does not need to document input 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 identifies a specific resource: 'Every field of the Broker vs Advisor enquiry' and enumerates the field metadata (key, label, type, required, help text, allowed options). It lacks an explicit verb such as 'returns' or 'lists', but the meaning 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?

It provides clear usage context by telling the agent how to use the output: 'Pass answers to submit_enquiry keyed by field key.' It does not explicitly name alternatives or say when not to use this tool, but the integration guidance is strong enough for practical selection.

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 of behavioral disclosure. It thoroughly explains the two-step statefulness, validation, consent requirement, email delivery, and the fact that providers only see the enquiry after the person clicks the link. It also reveals the privacy implication: details are shared with brokers and advisers.

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 densely informative, with clear Step 1/Step 2 structure. Every sentence adds essential workflow detail, and the critical 'not a purchase' warning is front-loaded. No redundant 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?

The tool has meaningful complexity — two-step flow, consent, confirmation token, email verification, and provider visibility. The description covers all of these, plus what step 1 returns, what to show the person, and what happens after step 2. No output schema exists, so this textual coverage is essential and sufficient.

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 already 100%, and the description adds substantial meaning beyond the schema: answers must be keyed by field key from enquiry_fields, the consent parameter requires the exact quoted agreement, and confirmation must be the token from step 1. It also clarifies that step 2 must reuse the same answers, which is not in the 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 clearly states the action ('Submits an enquiry'), the target ('to Broker vs Advisor'), and what it is not ('NOT a purchase, NOT a guaranteed quote'). It distinguishes itself semantically from purchase or quote tools despite the sibling tools being mostly unrelated checkers.

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 explicit step-by-step usage instructions: step 1 validates and returns a token, step 2 is only called after the person agrees. It also states the condition for each call and warns against using it as a purchase or guaranteed quote, giving clear when-to-use and when-not-to-use guidance.

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