site

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

With no annotations provided, the description carries the behavioral burden. It does disclose that missing inputs fall back to documented defaults and lists the calculation stages the tool will produce. It does not specify the return format, whether the operation is purely computational, or how results are structured, leaving some behavioral ambiguity.

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, front-loads the action ('Run the Section 877A exit tax calculator'), and uses a clean list for the output stages. The 'calculator calculator' typo is a minor flaw but does not materially hurt 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 calculation tool with five fully documented optional parameters and no output schema, the description names the main computed outputs and the default-fallback behavior, which supports a basic invocation. It does not describe the output container, labeling, or return value shape, so an agent still has to infer part of the response contract.

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 100% description coverage, documenting all five parameters with defaults, ranges, and descriptions. The description adds no new parameter semantics beyond noting that missing inputs fall back to documented defaults, which largely restates what the schema already expresses. The baseline of 3 applies.

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 'Run the Section 877A exit tax calculator' and enumerates the specific computed outcomes: covered expatriate status, applicable test, exclusion applied, and gain subject to the exit tax. This separates it from the sibling describe/enquiry tools by making its calculation role explicit, though it does not name those alternatives.

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 this tool is for running the exit tax calculation and that missing inputs will use defaults, which gives some sense of when to call it. However, it gives no explicit guidance about when not to use it or when to prefer siblings like calculator_describe or enquiry_describe.

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 disclosure. It does inform the agent that the tool returns information about inputs, outputs, assumptions, and tables, which gives some behavioral transparency. However, it does not explicitly state that the tool performs no calculation or side effects, or describe how the output is presented.

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 that efficiently enumerates the full scope of the tool's output: inputs, outputs, assumptions, and tables. There is no wasted wording or redundant 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 parameterless describe tool with no output schema, the description adequately captures what an agent will receive. It names the major content categories without promising excessive detail. It could be slightly stronger by noting when to call it relative to calculate, but overall it is sufficiently complete for the tool's simple nature.

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 confirms an empty properties object, so there is nothing for the description to clarify. The description does promise to explain inputs with units, ranges, and defaults, which is accurate and helpful context for the tool's overall purpose.

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 (Section 877A exit tax calculator) and specifies what the tool covers: inputs, outputs, assumptions, and tables. It is distinguishable from sibling tools like calculate and enquiry_describe because it focuses on describing the calculator's behavior rather than performing a calculation. It lacks an explicit verb like 'returns' or 'describes,' but the intent is 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 description gives no guidance on when to use this tool versus alternatives such as calculate or enquiry_describe. An agent must infer that this tool is useful before invoking calculate or for understanding calculator internals, but the description does not state this explicitly.

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 burden of behavioral disclosure. It provides useful transparency about what submit_enquiry does (not a purchase, no guaranteed quote, free) and what the response contains (recipient details, consent wording, confirmation method), but it does not explicitly state that this tool itself is read-only or has no side effects, though the 'describe' verb strongly implies it.

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 and front-loads the most important guidance ('Read first') while covering purpose, scope, and output contents. It is efficient, though the phrase 'States plainly' is slightly redundant and the title is longer than necessary.

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 does a good job explaining what the tool returns and clarifying the enquiry context (no purchase, no guaranteed quote, free, confirmation process). It could be more explicit about when not to use it or what it does not cover, but for a descriptive companion tool it is adequately 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 empty schema properties, so the schema provides no parameter information. The description compensates by explaining what the returned information will cover, which is sufficient for a parameterless informational tool; per the baseline for zero-parameter tools, this is a solid 4.

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 the tool's function: it 'States plainly what submit_enquiry does' and returns key information about the enquiry process. It differentiates itself from siblings like calculate and enquiry_fields by explicitly being the descriptive companion to submit_enquiry, with no calculation or field-listing focus.

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' gives a clear instruction to consult this tool before proceeding, implying it should be used before submit_enquiry. It does not explicitly name alternatives or exclusions, but the intended ordering and informational role are evident from the description.

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 behavioral disclosure burden. It does a good job by specifying exactly what data is exposed and the expected relationship with submit_enquiry. It does not explicitly state that the operation is read-only, but for a zero-parameter metadata listing this is a minor omission rather than a significant 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 sentence that front-loads the core purpose, enumerates the included attributes, and ends with an actionable pointer to submit_enquiry. Every clause earns its place with no 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 tool, the description gives a solid picture of what the agent receives and how to apply it. It lacks an explicit statement of the output structure (e.g., array of objects), but the enumeration of field attributes sufficiently conveys the shape of the data for most use cases.

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 no parameters, so the baseline is 4. The description adds relevant context by explaining that the returned field keys are meaningful for submit_enquiry, even though there are no input 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 clearly identifies the resource—the field definitions of the Expatriation Tax Calculator enquiry—and enumerates the exact attributes exposed (key, label, type, required, help text, options). It is distinguishable from siblings like calculator_describe and enquiry_describe, though it stops short of using an explicit verb such as 'returns' or 'lists'.

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 a clear downstream usage instruction: 'Pass answers to submit_enquiry keyed by field key.' This implies when the tool is useful, but it does not explicitly contrast it with sibling tools like enquiry_describe or calculator_describe, nor does it state 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 behavioral burden and does so: it discloses validation behavior, that step 1 returns a summary/consent line/token rather than submitting, that the person must approve before submission, and that an email link must be clicked before any provider sees the data. It also spells out the exact consent semantics, which is essential side-effect context.

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 text is long and runs on, but every sentence is load-bearing for a two-step consent-gated workflow, and the critical 'NOT a purchase' constraint is front-loaded. Slightly denser than ideal, but not padded.

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?

Despite having no output schema, the description explains what each call returns (summary, consent line, confirmation token) and the downstream consequences (email with a click-through link before providers see details). For a complex nested-object tool with a two-phase protocol, nothing an agent needs 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 schema already documents all three parameters, but the description still adds workflow meaning: answers are keyed by field key from enquiry_fields, consent must be true, and confirmation is the step-1 token passed in a second call after approval. That temporal/role guidance goes beyond the schema field text.

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 and resource (submits an enquiry to human providers) and immediately scopes what it is NOT (not a purchase, not a guaranteed quote), which cleanly separates it from the calculate/calculator_describe siblings. An agent can identify the operation without opening the 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?

Gives explicit two-step usage: step 1 call with answers + consent=true to validate and get a token, step 2 only if the person agrees, calling again with the same answers plus the confirmation token. It also names the source of answer keys (enquiry_fields), so the conditions selecting each call are unambiguous.

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