site

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It reveals the two return shapes (next question or final verdict) but stays silent on side effects, whether answers are recorded, prerequisites, error behavior, or whether the check is reset after the verdict. This is a significant gap for an interactive workflow tool.

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 sentence with no filler; the key constraint (given question and choice) is front-loaded and the result is stated compactly. The title reinforces the intent without duplicating the description verbatim.

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 is simple (2 required params, no nested objects), and the description covers the main contract: input and result. But without an output schema and with sibling tools forming a workflow chain, the description lacks crucial context such as how a question id is obtained, what the final verdict looks like, and what happens if the pair is invalid.

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 0%, so the description must compensate. It adds meaning by clarifying that 'question' is an identifier and 'choice' is the index of the chosen option. However, it does not explain where the question id comes from, whether the indices are zero-based, or what valid choices look like.

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 clear verb ('return') and resource ('the next question or the final verdict'), and maps the inputs (question id, choice index) to the schema fields. It distinguishes the step-forward behavior from checker_start (likely initialization) and checker_tree (likely structure), though it does not name those siblings explicitly.

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 context is implied: when a user has answered a question with a question id and an option index, call this to advance. But there are no explicit when-to-use criteria, no exclusions, and no mention of alternatives such as checker_tree or checker_start.

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?

No annotations are provided, so the description carries the full burden. It discloses that the enquiry is not submitted until the second step, that consent requires agreement to the exact quoted line, and that the person receives an email with a link that must be clicked before any provider sees the enquiry. It also reveals what the first call returns: a summary, consent line, and confirmation token.

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 information-dense; every segment earns its place, from disambiguation to step 1, the consent quote, step 2, and the post-submission email behavior. The top-line 'NOT a purchase' prefix and clear Step 1/Step 2 structure make it scannable despite its length.

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-step human-submission tool with no annotations and no output schema, the description is unusually complete: it covers return values, the exact consent requirement, when to proceed, and the email-link precondition. An agent has enough context to execute the workflow correctly and set user expectations.

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 meaningful workflow semantics: answers are keyed by field key from enquiry_fields, consent is tied to the exact consent line, and confirmation is the token returned in step 1 for reuse in step 2. This teaches an agent how the parameters relate to each other rather than just restating 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 opens with a specific action, 'Submits an enquiry to Landlord Database Check', and immediately disambiguates with 'NOT a purchase, NOT a guaranteed quote'. The two-step workflow is stated in the title and elaborated in the body, so an agent can distinguish this 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?

It gives an explicit two-step protocol: first call with answers and consent=true to get a summary and confirmation token, then 'only if the person agrees' call again with the same answers and the token. It also states when the tool is not applicable ('NOT a purchase, NOT a 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.