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 only states that this is the first question, with no information about whether starting creates state, returns a question, or has 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?

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying what the tool represents.

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 and a simple purpose, the description is largely complete: it identifies the resource and the tool's role as the entry point. It could add a bit more behavioral context, but the low complexity limits the need.

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 no parameter details to add. The baseline of 4 applies because there is nothing to document.

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 Drone licence checker decision guide—and its position as the first question, which distinguishes it from siblings like checker_answer and checker_tree. However, it lacks a direct action verb such as "displays" or "starts," so it does not fully meet the 5-level bar.

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 implies usage at the beginning of the decision guide by calling this the first question. It does not explicitly state when to use it versus the sibling tools or mention any exclusions.

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 explains what content is included (questions, options, verdicts), but says nothing about return format, whether the tool is read-only/static, output size, or how the data is structured. This leaves operational behavior largely inferred.

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, dense sentence with no filler. It front-loads the resource and content, and every phrase ('every question, option and verdict', 'for reasoning end to end') earns its place by clarifying what the tool provides and why.

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 no-argument tool, this is close to adequate: the agent knows the tool returns the complete decision tree and that it is meant for end-to-end reasoning. However, with no annotations and no output schema, the lack of any mention of return structure or relationship to step-wise siblings leaves some context 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?

The tool has zero parameters and an empty input schema, so there is no parameter documentation gap. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description does not need to add parameter-level 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 names the exact resource (the Drone licence checker guide's decision tree) and specifies its content: 'every question, option and verdict'. 'Whole' and 'end to end' clearly distinguish it from the step-wise sibling tools checker_start and checker_answer, making selection 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?

The phrase 'for reasoning end to end' gives a clear use case, but it does not explicitly state when to prefer this tool over checker_start/checker_answer or mention exclusions. The guidance is implied rather than directly 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 fully carries the burden of disclosure, and it does so well: it states that nothing is bought or paid for, no quote is guaranteed, the service is free, and it details what information is returned including recipient, consent wording, and confirmation method.

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 short, front-loaded with the 'Read first' directive, and every sentence adds meaningful information. It avoids filler while covering purpose, exclusions, cost, and return content in just three sentences.

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 no output schema, the description adequately explains what the tool returns: who receives the details, consent wording, and how confirmation happens. It fully covers expectations for this simple zero-parameter tool, leaving no significant gap for an agent to call it 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?

The tool has zero parameters and the schema description coverage is 100%, so there are no parameter semantics for the description to clarify. The description adds useful context about the returned content, which is appropriate for a parameterless informational 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 states that this tool describes what submit_enquiry does, explicitly differentiating it from a purchase, order, payment, or guaranteed quote. It names the related submit_enquiry tool and positions itself as the read-first informational counterpart, making its purpose unmistakable.

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' provides an explicit usage signal that this tool should be consulted before engaging with the enquiry process. It sets expectations about what the enquiry is and is not, though it does not discuss alternatives like the checker_* tools or specify when to skip this tool.

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 behavioral disclosure burden. It does disclose what data the tool exposes and implies a read-only metadata lookup, but it never explicitly states that there are no side effects or how the field list is returned. For a low-risk metadata tool this is acceptable, but the absence of an explicit behavioral statement keeps it at a 3.

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 enumerates the returned field metadata, and the second links those field keys to submit_enquiry. The most important content is front-loaded and every sentence 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 metadata tool, the description sufficiently explains what is returned and how the output relates to submit_enquiry. It does not explicitly differentiate from enquiry_describe, which could cause ambiguity among sibling tools, but the core usage is complete enough for an agent to invoke the tool 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?

The tool has zero parameters and an empty schema, so there is nothing for the description to clarify about parameter syntax or meaning. The mention of keying answers to submit_enquiry by field key adds useful domain context even though it is not a parameter. A zero-parameter tool gets a baseline 4, and the description meets that bar.

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 field structure of the Drone Licence Checker enquiry and enumerates the exact metadata exposed (key, label, type, required, help text, options). It also connects the tool to submit_enquiry, giving the agent a concrete purpose. It loses one point because it lacks an explicit verb such as 'lists' or 'returns', and the title is noun-like.

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 gives one useful routing hint: 'Pass answers to submit_enquiry keyed by field key,' which tells the agent how to use the returned field keys. However, it does not explicitly state when to use enquiry_fields over sibling tools like enquiry_describe or checker_tree, and there are no exclusions. Usage guidance is implied rather than explicit.

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 a two-phase state machine, a returned confirmation token, a human consent requirement with verbatim consent text, and the downstream effect (email link that must be clicked before any provider sees it; details go to up to three chosen training providers). This is far beyond what the schema reveals.

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 'not a purchase' disambiguation and organized around Step 1 / Step 2. It is dense and delivered as a single long block, and the verbatim consent text is repeated from the schema, which costs a little economy.

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?

There is no output schema, and the description compensates by naming what step 1 returns (summary, consent line, confirmation token) and what the end state is. For a nested-object, multi-step submission tool with zero annotations, nothing an agent needs to call it 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 the baseline is 3, but the description adds genuine meaning: answers are keyed by 'field key from enquiry_fields' (linking to a sibling tool), consent must be true only after agreement, and confirmation is the token returned by step 1. That sequencing 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?

States a specific verb (submits) and resource (an enquiry to human providers), and immediately scopes it with the negatives 'NOT a purchase, NOT a guaranteed quote', which is exactly the ambiguity an agent would otherwise have. It is clearly distinguishable from the enquiry_fields/enquiry_describe siblings, which supply data rather than submit.

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 the when: Step 1 call with answers and consent=true, Step 2 'only if the person agrees' with the token from step 1. The gating condition for each call is stated, and the alternatives (do not call step 2 without approval) are implied by 'only if'.

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