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 burden of behavioral disclosure. It only states that this is the first question; it does not say whether calling it presents a question, returns options, changes state, or expects any follow-up. This is thin operational detail for a tool with no annotation-backed safety or side-effect information.

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 redundant wording. The key identifier 'first question' is front-loaded, and the sentence is appropriately concise for a zero-parameter entry-point 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?

With no output schema, the description should explain what the caller receives or what to do next, but it only says the tool is the first question. It does not describe the returned question format, available answers, or how the agent should proceed to checker_answer, leaving important context to 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?

The input schema is empty with 100% schema coverage, so there are no parameter semantics for the description to clarify. The description adds no parameter-level meaning, but none is required when the tool takes no parameters.

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 first question in the CASP authorisation checker decision guide, which communicates its entry-point role and distinguishes it from siblings like checker_answer and checker_tree. However, it lacks an explicit action verb such as 'starts' or 'returns', so it describes what the tool is more than what it does.

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 use this tool instead of alternatives like checker_answer, checker_tree, or the enquiry_* tools. The entry-point usage is only implied by the phrase 'first question', with no mention of prerequisites, next steps, or 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 behavioral disclosure burden. It conveys that the tool returns the entire decision tree with no parameters or modification, implying a read-only retrieval. It does not disclose the output format, potential size, or whether the response is best consumed in parts, but the core behavior is reasonably 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 a single, front-loaded sentence with no filler. It names the domain, the scope ('every question, option and verdict'), and the intended reasoning flow, earning its place entirely.

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-parameter static reference tool, this is nearly complete: it identifies what content is included and why an agent would use it. The only missing piece is a brief note on the response format or how it relates to checker_answer and checker_start, since there is no output schema or annotations to supply that 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 input schema has zero parameters, so parameter semantics are not applicable. Per the rubric, a zero-parameter tool gets a baseline of 4; the description does not need to explain parameters that do not exist.

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 the tool provides every question, option, and verdict of the CASP authorisation checker guide, making its purpose as a complete decision-tree reference apparent. It does not use an explicit verb like 'retrieve', but the content and intended use ('for reasoning end to end') are specific enough to distinguish it from the step-by-step 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 phrase 'for reasoning end to end' implies when to use the tool: when the full decision tree is needed rather than a single answer or starting point. However, it does not explicitly state when not to use it or directly contrast it with checker_answer and 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 exist, so the description carries the full burden—and it delivers. It discloses key behavioral traits: nothing is bought, ordered, or paid; no quote is guaranteed; it is free. It also lists what the tool returns (who receives details, consent wording, and confirmation method). This goes well beyond what structured metadata could provide.

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 'Read first,' then delivers purpose, constraints, and return content in three tight sentences. Every clause adds value, with no repetition 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-param, no-output-schema tool, the description is nearly complete: it tells the agent what the tool does, important safety-related constraints, and what content is returned. The only minor gap is that it doesn't explicitly state that enquiry_describe itself is non-mutating and side-effect free, though the wording strongly implies this.

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 the baseline of 4 applies. The description correctly doesn't attempt to document parameters that don't exist, and no additional param semantics are necessary.

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 exactly what the tool does: 'States plainly what submit_enquiry does on CASP Checklist.' It clearly identifies the resource (submit_enquiry) and the action (describing/explaining), and the title 'What you get' reinforces the informational nature, distinguishing it from the actual submit_enquiry tool.

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 instruction 'Read first' tells the agent to consult this tool before acting, which is a clear usage signal. It establishes context for understanding submit_enquiry, but it does not explicitly name sibling alternatives or state when not to use it. Still, the context is clear enough for an agent to decide.

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 implies a read-only metadata lookup by describing the fields and their attributes, and it gives useful integration context with submit_enquiry. However, it does not explicitly state side effects, response shape, or whether any state changes occur; for an introspection tool this is acceptable 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?

The description is two compact sentences with no filler. The first sentence defines exactly what the tool returns, and the second explains how the returned keys should be used. 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 no-argument introspection tool with no output schema, the description does a good job by listing the key field attributes and connecting the result to submit_enquiry. It still leaves minor ambiguity about the exact return format and whether the data is static, but nothing critical is missing 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 coverage is 100%, so the baseline for parameter semantics is 4. The description adds no parameter requirements and appropriately focuses on the output content, which is sufficient 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—the CASP Checklist enquiry fields—and enumerates exactly what information is exposed (key, label, type, required, help text, allowed options). It lacks an explicit verb like 'list' or 'get', but the meaning is unambiguous and the tie to submit_enquiry aids differentiation.

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 tells the agent when to use the result: 'Pass answers to submit_enquiry keyed by field key.' This provides clear practical context for invocation. It does not explicitly explain when not to use it or compare it with siblings like enquiry_describe or checker_*, but the usage direction is strong.

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 and does so: it discloses that step 1 is non-committal validation returning a summary/consent line/token, that step 2 actually submits, that an email link must be clicked before any provider sees the data, and that contact details go to up to three advisers with a stop mechanism. This is exactly the context an agent needs to avoid an unintended 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?

Front-loaded with the most decision-relevant fact (not a purchase) and structured as Step 1 / Step 2. The one inefficiency is the full consent sentence, which is quoted verbatim here and again in the consent parameter's schema description, so it is mildly redundant.

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, so the description must explain returns, and it does: a summary, the consent line, and a confirmation token from step 1, plus the post-submission email/click gate. Combined with the nested answers object, the description is complete enough 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: 'answers' is keyed by field key from enquiry_fields, consent=true is tied to a specific agreement, and the confirmation token is identified as the artifact returned by step 1. That clarifies how the parameters are sequenced across the two calls, beyond the schema's static types.

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 (submits) and resource (an enquiry to CASP Checklist), and immediately disambiguates with 'NOT a purchase, NOT a guaranteed quote' and 'to human providers'. It also names the sibling enquiry_fields as the source of field keys, so an agent can place it against alternatives without opening schemas.

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: Step 1 with answers+consent=true to validate, Step 2 only 'if the person agrees' with the same answers plus the confirmation token. The gating condition and the pre-requisite (person has read and agreed to the consent text) are both spelled out, leaving nothing to inference.

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