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 behavioral disclosure burden. It only states that this is the first question of the guide, without clarifying whether calling it initializes state, returns a static question, resets an in-progress session, or has any side effects. For a 'start' action, this is a meaningful transparency gap.

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 with no redundant words. It is front-loaded by naming the tool's position in the guide. It could arguably be more informative without becoming bloated, but as a concise description it performs well.

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 that the tool is simple, has no parameters, and no output schema, the description is minimally viable: an agent can reasonably call it to get the first question. However, it lacks any context about the checker flow, return shape, or relationship to checker_answer and checker_tree, so it is not fully complete for an agent operating without prior domain knowledge.

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 the baseline is 4. There are no parameter semantics to explain, and the description does not need to compensate for undocumented inputs.

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 the resource as the 'first question of the Employment rights checker decision guide,' which makes the tool's purpose reasonably clear: initiating the checker and presenting its first question. It does not explicitly use a verb like 'starts' or 'shows,' but the name and phrasing together convey the intended action. It is somewhat distinguishable from siblings such as checker_answer and checker_tree, though not explicitly contrasted with them.

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 provides no guidance on when to call this tool versus siblings like checker_answer, checker_tree, or submit_enquiry. There is no mention of prerequisites, session state, or typical invocation flow. An agent must infer from the name that this is the entry point to the guide.

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 must carry the behavioral disclosure burden. It transparently states the content coverage (all questions, options and verdicts), but it does not explicitly say the operation is read-only, describe the response format, or note any size/pagination characteristics.

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, and the key content coverage is stated first before the purpose. Every word contributes meaning.

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 that returns the whole decision tree, the description sufficiently indicates what will be returned (questions, options, verdicts) and why it is useful. It could add the response structure or an explicit alternative, but the absence of parameters and schema makes this a near-complete description.

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 coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because no parameters exist 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 the resource (the Employment rights checker guide) and the full scope of the content (every question, option and verdict), distinguishing it from step-by-step sibling tools like checker_answer and checker_start. It lacks an explicit action verb such as 'retrieve' or 'return', but the intended purpose is clear.

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?

'For reasoning end to end' gives an explicit use case: call this tool when you need the complete decision tree at once rather than navigating stepwise. It does not name alternative tools or state when not to use it, but the context from the sibling list makes the usage scenario reasonably clear.

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 disclose outcome-relevant traits: nothing is bought, ordered or paid; no quote is guaranteed; it is free; and it returns who receives details, the consent wording, and confirmation flow. The 'States plainly' phrasing implies a pure read/documentation tool, though it never explicitly states that the tool itself performs no submission.

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 a strong 'Read first' and consists of three sentences, each adding distinct value: purpose, non-transactional nature, and return content. There is minor redundancy with the title ('not a purchase, not a guaranteed quote' vs. 'Nothing is bought, ordered or paid; no quote is guaranteed'), but no wasted sentences overall.

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 informational tool with no output schema, the description is complete: it states the tool's role relative to submit_enquiry, clarifies common misconceptions, and lists what the returned content covers. An agent has everything it needs to invoke this tool correctly and understand what it will get back.

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 shows an empty properties object, so there is nothing for the description to explain. Per the baseline for zero-parameter tools, this receives a 4; no additional parameter semantics are needed.

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 and resource: it 'states plainly what submit_enquiry does', positioning this tool as the informational companion to the submission tool. The title reinforces this with 'What you get: an ENQUIRY with a human', and the description clearly marks it as distinct from submit_enquiry and the other checker 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?

The opening directive 'Read first' gives an explicit ordering cue: this tool should be consulted before submit_enquiry. The description also clarifies the non-purchase, non-guaranteed-quote nature of the enquiry, which helps an agent decide when to surface this information. It stops short of explicitly naming alternatives or saying 'use this instead of X', but the context is clear enough.

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 describes what data is exposed and how it should be used, and there is no implication of side effects. However, it does not explicitly state that the tool is read-only or describe the response format or error behavior. For a low-risk metadata lookup this is adequate but not thorough.

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 the core content, and the second sentence provides actionable usage guidance. Every word contributes to the agent's 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 zero-parameter tool with no output schema and five siblings, the description explains what the tool returns and how that result plugs into submit_enquiry. It does not detail the exact response shape, but that is a minor gap given the simplicity of the tool. A brief mention of how this differs from enquiry_describe would improve completeness.

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 the schema already covers everything by default. The description adds useful semantic information by explaining that the returned field keys are the keys to use when calling submit_enquiry. This exceeds the baseline for an empty parameter set.

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 ('the Employment Rights Checker enquiry') and lists the exact contents returned: key, label, type, required status, help text, and allowed options. It does not use an explicit verb like 'list' or 'return', but the meaning is unambiguous and it differentiates itself from submit_enquiry.

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 second sentence gives direct usage guidance: 'Pass answers to submit_enquiry keyed by field key.' This tells the agent to retrieve field keys before building a submission. It does not explicitly contrast with siblings like checker_answer or enquiry_describe, but the intended workflow is clear.

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 reveals validation, the returned summary/consent line/token, the second submission call, the confirmation email, and the fact that providers only see the enquiry after the person clicks the link. This gives the agent an accurate model of 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 length is justified by the two-step protocol and the legally meaningful consent text. It is front-loaded with the key caveat, then ordered as Step 1 and Step 2, and every clause contributes to preventing a costly misuse.

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?

With no output schema, the description explicitly names what Step 1 returns (summary, consent line, confirmation token) and the final outcome (email with click link before provider visibility). The answer source and consent requirement are covered, making the tool fully callable without additional inference.

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. The description adds meaning by linking answers to 'field key from enquiry_fields' and explaining how consent and the confirmation token are used across the two steps. The exact consent wording is already in the schema, so the incremental value is real but modest.

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 action ('Submits an enquiry to Employment Rights Checker') and clearly distinguishes it from a purchase or guaranteed quote. The two-step nature is front-loaded, so an agent immediately understands what this tool does and what it does not do.

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 explicit step-by-step conditions: call first with answers and consent=true, get a summary/token, then call again only if the person agrees. It also provides a clear exclusion ('NOT a purchase, NOT a guaranteed quote') and explains when the second call is appropriate.

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