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?

No annotations are provided, so the description carries the full behavioral burden, and it does substantial work: it discloses that step 1 only validates and returns a summary/consent line/token, that submission happens on step 2, and that the person must click an emailed link before any provider sees the enquiry. It does not describe failure/validation-error behavior or what happens if the token is stale, but the core side-effect chain is well covered.

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 critical disambiguation, then the two-step flow in order, then the consent text. It is long, and the consent wording is duplicated verbatim from the schema's consent description, but for a legally significant consent the repetition is defensible and every sentence carries 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?

No output schema exists, and the description compensates by stating exactly what step 1 returns (summary, consent line, confirmation token) and what the person receives after step 2 (an email link they must click). Nothing an agent needs to drive the two-call flow 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, but the description adds sequencing meaning the schema cannot: 'answers' are keyed by field key from enquiry_fields, 'consent' must be true only after the person has read and agreed, and 'confirmation' is the token returned by step 1. That context makes the otherwise flat parameters actionable.

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 (submits) and resource (an enquiry to HMO Licence Checker), and immediately disambiguates by negating the two things an agent might confuse it with ('NOT a purchase, NOT a guaranteed quote'). The two-step framing further distinguishes it from the checker_* and enquiry_* siblings.

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 explicit when-to-call instructions for both steps: step 1 with answers and consent=true, step 2 only if the person agrees, with the same answers plus the confirmation token. It also names the prerequisite source for the answers (field keys from enquiry_fields).

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