site

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

With no annotations and no output schema, the description carries the full burden of behavioral disclosure, but it only describes the happy path (return next question or final verdict). For a tool named checker_answer in a verification flow, it says nothing about whether the answer is validated, what happens on an incorrect or unknown question, whether repeated submissions are idempotent, or what the final verdict path looks like. Scoring is low because this is a verification-class tool with no verification semantics disclosed.

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, no fluff, and the input contract is front-loaded before the output. The structure is easily scannable and the sentence earns its place. It loses a point only because the brevity leaves the behavioral gaps noted above, making the description feel slightly under-specified rather than efficiently complete.

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 verification step with no annotations, no output schema, and 0% parameter coverage, the description is incomplete. It covers the normal calling convention but omits failure modes, verification/retry semantics, state prerequisites, and the meaning of the returned verdict — exactly the details an agent needs when invoking a state-machine step 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 description coverage is 0%, so the description is the only source of parameter meaning. It does map both parameters clearly: question is a question id and choice is the index of the chosen option. However, it omits index base (schema's minimum 0 implies zero-based), ID format, and acceptable value ranges beyond the schema's minimum.

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 a specific verb (return) and resource (next question or final verdict), and the phrase 'next' and 'final verdict' position this as the step-advancing tool within the checker_ family, distinguishing it from checker_start (which begins the flow) and checker_tree (which views it). It earns a 4 rather than 5 because it never explicitly names the sibling tools or their relationship, leaving the differentiation to inference.

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 no guidance on when to call this tool versus checker_start or checker_tree. It neither states a prerequisite (e.g., must call checker_start first) nor excludes cases (e.g., use checker_tree to view the whole flow). A capable agent can infer the mid-flow usage from the title, but the description itself provides no directive.

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 full behavioral burden, and it delivers: it reveals that the first call is non-final and returns a summary, consent line, and token; the second call actually submits and triggers an email; and providers see nothing until the person clicks the emailed link. The exact consent wording is included, so the agent knows the required condition precisely.

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 dense but every sentence earns its place: the not-a-purchase warning is front-loaded, the two steps are clearly sequenced, the consent text is quoted exactly, and the email/provider-visibility consequence is included. No filler or repeated schema 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?

For a two-step, high-stakes submission tool with no output schema and no annotations, the description covers the full flow, the required consent text, the follow-up token, and the post-submission effect. The agent can execute both steps correctly and knows what to show the user and when to proceed.

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 goes beyond the schema by explaining the life cycle of each parameter: answers must use keys from enquiry_fields, consent must reflect agreement to the quoted statement, and confirmation is the token returned in step 1. This adds meaningful operational meaning to the raw schema fields.

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 a specific verb and resource ('submits an enquiry to Right to Work Wizard') and immediately differentiates it from a purchase or quote. The title reinforces the two-step nature, and the description clearly distinguishes this submission tool from the sibling checker and enquiry-inspection tools.

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 explicitly spelled out as a two-step sequence: call first with answers and consent=true to validate and obtain a confirmation token, then call again only if the person agrees. It also states what the tool is NOT for (not a purchase, not a guaranteed quote) and implies using enquiry_fields to key the answers, giving clear routing guidance.

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