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 explaining behavior. It only states what the tool is ('the first question') rather than what it does or returns, and it does not disclose side effects, session state, or expected response 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 a single sentence with no filler or repetition. It is front-loaded with the key identification of the tool as the first question of the guide, making it 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?

For a zero-parameter tool, the description is minimally adequate but not fully complete. It gives enough to infer the tool's role, but it does not describe the return value, how it connects to checker_answer, or what the agent should expect after calling it.

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% schema description coverage, so there is nothing for the description to clarify about parameters. The baseline for a no-parameter tool is appropriate 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 HMO licence checker decision guide and its first question, which distinguishes it from checker_answer and checker_tree as the entry point. It lacks an explicit verb like 'returns' or 'starts', but the meaning is reasonably clear from the name and title.

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 question' implies this tool should be used at the beginning of the HMO licence checker flow. However, it does not explicitly state when to use this over checker_answer or how to proceed afterward, leaving the usage context mostly inferred.

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. It describes the content ('every question, option and verdict') but does not disclose behavior such as return format, size, whether it's a static snapshot, or any side effects. The agent knows what the tool represents, but not what happens when invoked.

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 compact, front-loaded with the core content, and free of fluff. Every word contributes to describing the tool's purpose.

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 there are no parameters, no annotations, and no output schema, the description sufficiently conveys what the tool offers—the full decision tree for end-to-end reasoning. It could mention response structure, but the complexity is low enough that the missing detail is not critical.

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, so the description has nothing to add about parameter meaning. With 0 params, a baseline of 4 is appropriate; the description correctly avoids inventing parameter details.

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 resource ('the HMO licence checker guide') and its scope ('Every question, option and verdict'), which clearly conveys this is the complete decision tree. It distinguishes itself from siblings like checker_answer or checker_start by emphasizing the whole tree for end-to-end reasoning, though it lacks a direct verb like 'get' or 'list'.

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 full-traversal reasoning rather than isolated lookups. However, it does not explicitly state when to prefer this over checker_answer or checker_start, nor does it mention any exclusions. Usage is implied rather than specified.

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 burden of behavioral disclosure. It states that the tool explains what submit_enquiry does, returns details about who receives the enquiry, consent wording, and confirmation method, and clarifies that nothing is bought or guaranteed. It does not explicitly say the tool itself has no side effects, but the describe/return framing makes this sufficiently clear.

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 short sentences with the key directive ('Read first') and core purpose front-loaded. Each sentence contributes distinct information: what it does, what it does not do, and what it returns.

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 fully conveys the outcome and the content of the returned information. It covers the non-transactional nature, the human-provider behavior, and the return contents, leaving no significant gap for an agent deciding whether to call it.

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?

This tool has zero parameters, so the 0-param baseline of 4 applies. The description does not need to explain parameter semantics that do not exist.

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 uses a specific verb ('states plainly') and names the exact resource: what submit_enquiry does on HMO Licence Checker. It also distinguishes itself from submit_enquiry by clarifying it is not the submission itself, and the title reinforces the distinction by emphasizing that no purchase or guaranteed quote is involved.

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?

'Read first' gives a clear temporal instruction to consult this description before acting, and it names submit_enquiry as the operation it explains. It does not explicitly enumerate when not to use this tool or address the checker_* siblings, so it stops short of a 5.

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 so by specifying the output content (key, label, type, required, help text, options) and by indicating that submission belongs to submit_enquiry rather than this tool. It doesn't mention session, auth, or mutability, but those are low-risk for a zero-parameter fields listing.

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 concise sentences: the first front-loads the output scope and content, the second gives a direct usage instruction. No filler or 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?

The tool has no input schema and no output schema, so the description must explain what the agent will receive; it does so by naming every field attribute and noting allowed options where present. It also tells the agent how the result feeds into submit_enquiry, completing the relevant context.

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 no parameters, so the baseline is 4; there is nothing the description needs to add 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 clearly identifies the tool as exposing every field of the HMO Licence Checker enquiry, enumerating the attributes each field carries. It lacks an explicit verb like 'returns' and does not differentiate itself from sibling enquiry_describe, so it isn't a 5.

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 explicitly tells the agent to key submit_enquiry answers by the field keys returned here, which defines a clear usage path. It doesn't state alternatives or exclusions among siblings, so it stops short of full 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, the description carries the full burden and does so: it discloses the non-purchase/non-quote nature, that a token gates the real submission, that an email confirmation link must be clicked before any provider sees the data, the cap of three providers, and the opt-out right. This is exactly the context an agent needs before mutating anything on a person's behalf.

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 and logically ordered by Step 1/Step 2, but the consent paragraph is reproduced verbatim from the schema's `consent` description, which is pure duplication. The step framing earns its place; the repeated consent text does not.

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 two-phase mutation with a nested free-form object and no output schema, the description supplies both return shapes (summary, consent line, token) and the terminal outcome (email link). Nothing an agent needs to sequence the calls 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%, so baseline is 3; the description goes further by explaining the workflow semantics of `confirmation` (it is the token returned by step 1, and must only be supplied after approval) and that `answers` must be keyed by field keys from enquiry_fields. It does not add validation rules or error behavior beyond 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?

States a specific verb and resource ('Submits an enquiry') and immediately delimits it against common misreadings ('NOT a purchase, NOT a guaranteed quote'). It also implicitly separates itself from the sibling flow tools (enquiry_fields, enquiry_describe) by naming the field-key source for `answers`.

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 prescribes a two-call sequence: Step 1 with answers+consent, Step 2 only after the person approves, with the confirmation token. The critical gating condition ('only if the person agrees'), the human-facing display obligation, and the downstream verification step are all stated.

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