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 says the tool is 'the first question' but does not explain whether calling it starts a session, returns a prompt, resets previous progress, or has any side effects. This is a notable gap for a tool that initiates a decision guide.

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, focused sentence with no filler or redundant detail. It immediately conveys the tool's role in the checker flow and earns its place.

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 starting tool, the description is mostly sufficient: an agent can infer that calling this tool begins the checker and presents the first question. It does not describe the return payload or state behavior, but the simplicity of the tool reduces the impact of those omissions.

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 100% description coverage, so there is nothing for the description to add about parameters. The baseline of 4 applies because with no parameters, parameter semantics are effectively complete by definition.

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 the starting point of the Landlord registration and licensing checker decision guide, giving the resource and its position in the flow. It distinguishes itself from siblings like checker_answer and checker_tree by signaling that this is the first question, though it lacks a strong action verb like 'starts' or 'displays'.

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 'first question' implies this tool should be used at the beginning of the checker flow, which gives some usage context. However, it does not explicitly state when not to use it or mention alternatives such as checker_answer for subsequent questions, leaving the routing partly to inference.

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 does communicate that the tool exposes every question, option, and verdict, implying a read-oriented, complete-data response. However, it does not state side effects, output structure, potential size, or any caveats about how the tree is delivered.

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 that front-loads the full scope ('Every question, option and verdict') and then states the purpose. There is no filler or redundancy; every phrase contributes to agent understanding.

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 adequately tells an agent that the full decision tree is available for end-to-end reasoning. It is slightly incomplete in that it does not describe how the tree is represented or how this tool relates to checker_start and checker_answer, but these gaps are minor given the absence of required inputs.

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 there is nothing for the description to document. The schema coverage is vacuously 100%, and the description correctly avoids inventing parameter details. This matches the baseline expected for a parameterless tool.

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 as the complete decision tree for the Landlord registration and licensing checker and states its purpose: end-to-end reasoning. It is distinguishable from sibling tools like checker_answer or checker_start by the explicit scope of the entire tree. However, it lacks an action verb such as 'returns' or 'retrieves', so it reads as a content statement rather than a clear tool operation.

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 full decision tree is needed, and sibling names suggest interactive step-by-step alternatives. There is no explicit guidance on when to prefer this tool over checker_start or checker_answer, and no exclusion or alternative conditions are stated.

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 and does well: it states the tool returns who receives the details, the consent wording, and how confirmation happens. It also clarifies that the enquiry is free and non-binding. It does not explicitly say the describe tool itself has zero side effects, but its informational framing makes this 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 front-loaded with "Read first" and each sentence earns its place: purpose, key exclusions, and return contents. It is appropriately sized for a zero-parameter informational tool, 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?

Given zero parameters, no output schema, and low complexity, the description is largely complete: it names the subject tool, the outcome, the exclusions, and the return contents. It could go slightly further by describing the exact format of the returned explanation, but that is not critical for correct invocation.

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 is trivially complete, so the baseline is 4. The description does not need to explain parameters and instead uses the space for behavioral and output context.

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 an explainer: it "States plainly what submit_enquiry does" on Landlord Database Check. It distinguishes itself from submit_enquiry by clarifying that nothing is bought, ordered, or paid and that no quote is guaranteed, so an agent can tell this is informational rather than transactional.

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" explicitly signals that this tool should be used before submit_enquiry, providing clear temporal guidance. It references submit_enquiry directly so the agent understands this is the pre-submission explainer, though it does not explicitly list when-not-to-use conditions or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool exposes every field of the enquiry and lists the specific metadata included, which is meaningful for an agent. It does not describe the exact response envelope or side-effect profile, but for a zero-input metadata-listing tool this level of disclosure is adequate.

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 filler. The first sentence front-loads what the tool returns, and the second sentence adds the practical relationship to submit_enquiry. Every clause earns its place, and phrasing like 'where there are any' adds useful precision about optional options.

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 tool with no parameters and no output schema, the description clearly communicates the return contents and the downstream use of the data. It is complete enough for an agent to know why to call it and what to expect. It could be slightly stronger by explicitly contrasting with enquiry_describe, but that is not essential given the simplicity of the tool.

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 is no parameter meaning for the description to add. The relevant semantic context—that the returned field keys are intended for use with submit_enquiry—is present, which is helpful.

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: every field of the Landlord Database Check enquiry, and enumerates the attributes returned (key, label, type, required, help text, allowed options). It lacks an explicit verb such as 'returns' or 'lists', and it does not directly distinguish itself from sibling tool enquiry_describe, so it is clear but not perfectly differentiated.

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 through the instruction to pass answers to submit_enquiry keyed by field key, which suggests this tool is meant to supply the keys needed for submission. However, there is no explicit statement of when to use this tool versus sibling tools like enquiry_describe or checker_tree, and no 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.

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

With no annotations provided, the description carries the full burden and does so richly: it discloses validation, the returned summary/consent line/token, that the enquirer gets an email link that must be clicked before any provider sees the data, and the exact consent meaning. This is far beyond what the schema conveys.

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 purpose and the two-step flow, and every sentence earns its place. The lengthy verbatim consent quote is somewhat redundant with the identical text already in the schema's consent description, which is the only notable bloat.

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 mutation tool with no annotations and no output schema, it covers the return values (summary, consent line, token), the downstream side effect (email link gating provider visibility), and the consent contract. An agent has everything needed to drive both steps 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 are "keyed by field key from enquiry_fields," consent must be true in both steps, and confirmation is the token returned from step 1 and only supplied after approval. This cross-step usage is not derivable from the schema alone.

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?

Opens with a specific verb+resource ("Submits an enquiry to Landlord Database Check") and immediately bounds scope with "NOT a purchase, NOT a guaranteed quote." An agent can tell exactly what this tool does and what it does not do without checking 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?

Explicitly spells out a two-step protocol: Step 1 with answers+consent=true, then Step 2 only "if the person agrees" adding the confirmation token. It states the condition that advances each step and the human-approval gate, leaving no ambiguity about when to call.

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