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?

With no annotations, the description carries the full behavioral burden. It adds that the tool asks or returns the first question, but it does not disclose whether invocation resets prior progress, creates a session, or has other side effects, which is important for a 'start' 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 concise, front-loaded sentence communicates the main behavior without filler. 'Decision guide' is slightly redundant but does not harm clarity.

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 entry-point tool, the description is adequate: it signals that invocation returns the first question of the wizard. However, without an output schema or annotations, it should also clarify whether state is initialized/reset and how this connects to checker_answer; that context 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?

The tool has zero parameters, so the description has no parameter semantics to add; this matches the baseline for parameterless tools.

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 that this tool presents the first question of the Right to work check wizard, so an agent can infer it is the entry point for the wizard. It is not a tautology, but it does not explicitly say 'call this to begin/start' and relies partly on the title for that meaning.

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?

There is no guidance on when to call this tool versus siblings such as checker_answer or checker_tree. The description does not say to start here before answering, nor does it mention any 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?

No annotations are present, so the description carries the full burden. It discloses the content scope ('every question, option and verdict') but does not explain how the data is returned, whether it is read-only, how large the response may be, or any other behavioral 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 focused sentence with no filler. It adds specificity beyond the title by enumerating what the tree contains, and it is appropriately sized for a zero-parameter tool.

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 simple no-parameter tool, the description is mostly adequate, but it leaves the agent to infer when to choose it over checker_answer/checker_start and gives no indication of the output structure or size. Because there is no output schema, a brief note on the returned data shape 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 input schema has zero parameters, so there is nothing for the description to clarify. With no parameters, a baseline of 4 is appropriate; the description does not need to compensate for missing parameter documentation.

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 complete Right to Work check wizard decision tree, including questions, options, and verdicts. It is clearly distinct from focused sibling tools, though it lacks an explicit verb like 'returns' or 'retrieves'.

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' weakly implies this tool is for whole-tree reasoning rather than single-step answers, and sibling names like checker_answer and checker_start suggest alternatives. However, there is no explicit statement of when to use this tool versus those alternatives or when not to use it.

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 of behavioral disclosure. It explains that this tool returns explanatory content, clarifies that no purchase or payment occurs, and lists what information is returned, such as recipient details, consent wording, and confirmation method. It does not explicitly claim to be side-effect-free, but the informational tone makes the behavior 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 compact and front-loaded with the most important instruction, 'Read first.' Every sentence adds distinct value: one frames the tool as a prerequisite, and the other explains both what submit_enquiry does and what this tool returns. There is no redundancy or 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?

For a zero-parameter, no-output-schema informational tool, the description is complete. It tells the agent what the tool is for, what subject matter it covers, and what the returned information will include, so an agent can select and call it appropriately without needing extra 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?

The tool has zero parameters and the schema coverage is effectively complete at 100%, so there is no parameter documentation burden for the description to carry. The description appropriately focuses on behavior rather than 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 states a specific purpose: it describes what submit_enquiry does on the Right to Work Wizard, covering the enquiry flow, the fact that nothing is purchased or paid, and the content of what is returned. This clearly differentiates it from the sibling tool submit_enquiry, which actually performs the submission.

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 'Read first' tells the agent to consult this tool before acting, and the description frames it as an explanatory companion to submit_enquiry. It does not explicitly enumerate when not to use it, but the guidance is clear enough in context.

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 implies a read-only retrieval of field metadata and describes the content in detail, but it does not explicitly state that the operation has no side effects, requires no authentication, or how the result is structured. This is adequate but not fully transparent.

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 sentences with no waste. The first sentence packs in the full scope and content of the response, and the second provides a clear workflow connection to submit_enquiry. Every sentence earns its place and the key information 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?

For a zero-parameter metadata tool with no output schema, the description sufficiently communicates what the agent will receive and how to use it downstream. It could be more explicit about the exact return shape (array vs. object), but the enumerated fields and the submit_enquiry linkage make it largely complete.

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 coverage is 100%, so the baseline is 4. The description adds a useful semantic link by noting that answers should be keyed by the returned field keys, even though there are no parameters 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 names the specific resource (Right to Work Wizard enquiry fields) and enumerates the exact content returned: key, label, type, required flag, help text, and allowed options. It lacks an explicit verb like 'list' or 'retrieve', but the meaning is clear and it differentiates itself from submit_enquiry by pointing to how answers should be keyed.

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 actionable usage guidance by explaining how the returned field keys should be used when calling submit_enquiry. It does not explicitly contrast this tool with sibling tools like enquiry_describe or checker_*, so the 'when to use vs alternatives' guidance is partial rather than complete.

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 that step 1 only validates and returns a summary/consent line/token, that nothing reaches providers until the person clicks an emailed link, and it spells out verbatim what consent authorizes plus the person's right to stop further firms. Side effects, gating and downstream consequences are all 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?

The two-step structure is front-loaded and each procedural sentence earns its place. The one inefficiency is quoting the full consent text verbatim, which is already duplicated in the `consent` parameter description, adding length without new 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?

There is no output schema, but the description compensates by describing what step 1 returns (summary, consent line, confirmation token) and what happens after step 2 (email with a click-through link before providers see the enquiry). An agent has everything needed to call 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 semantics beyond the schema: it explains that `confirmation` is omitted in step 1 and required in step 2, that `consent` must be true in both calls, and that `answers` must be keyed by field keys from enquiry_fields. Only the shape of the answers values is left to 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 states a specific verb and resource ("Submits an enquiry to Right to Work Wizard") and immediately disambiguates from adjacent concepts with "NOT a purchase, NOT a guaranteed quote". It also anchors the tool to the sibling that supplies its inputs ("keyed by field key from enquiry_fields"), so an agent can place it in the flow without opening another schema.

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 with the exact condition that gates step 2 ("only if the person agrees"), the required payload for each call, and the prerequisite that a confirmation token from step 1 must be supplied. It also routes to the sibling tool that produces the field keys.

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