site

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

With no annotations, the description carries the transparency burden. It discloses one important behavior: 'Missing inputs fall back to their documented defaults.' It also lists what the calculator inputs and output are, implying a pure computation. It does not explicitly state that no data is submitted or persisted, but for a calculator this is a moderate gap, not a severe one.

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 short and front-loads the action, but the phrase 'calculator calculator' is redundant and detracts from clarity. The semicolon-separated list is easy to scan, yet the typo and slightly awkward wording keep it from being polished.

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 calculator with four numeric params and no required fields, the description covers the main inputs, the fallback behavior, and the high-level output. However, with no output schema, it leaves the exact return format and units (e.g., currency, breakdown vs total) unspecified. An agent could call it correctly but might be unsure what response to expect.

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 100%, so the baseline is 3. The description adds some semantic grouping by naming '409A valuations to budget for' (events), 'Appraisal fees' (price), 'Expedite premium' (rush), and 'Total 409A spend' (output), but it does not clarify the 'years' parameter by name. Overall it provides marginal value beyond 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 uses a specific verb ('Run') and a specific resource ('the 409A valuation budget calculator'), and it enumerates the calculator's inputs and output. The 'calculator calculator' repetition is a typo but does not obscure the purpose. It does not explicitly distinguish from sibling calculator_describe, but 'run' vs 'describe' is a usable contrast.

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 used to execute the 409A valuation budget calculation, and the sibling names (calculator_describe, enquiry_describe, submit_enquiry) provide loose context for when to use it. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named.

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?

There are no annotations, so the description carries the behavioral transparency burden. It does convey that this is an informational, read-only tool by describing what it covers: inputs, outputs, assumptions, and tables. It does not explicitly say 'it does not perform calculations' or describe the response format, but for a zero-parameter describe tool the behavior is reasonably 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 a single sentence that front-loads the key content categories: inputs, outputs, assumptions, and tables. There is no filler, repetition, or unnecessary detail. Every phrase adds value.

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 describe tool, this description covers the essential information: the resource and the categories of information the agent will get. It does not explain how the returned documentation should be used with the 'calculate' sibling, but that is more of a usage-guideline gap than a completeness gap.

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 is trivially complete, and the baseline for 0 params is 4. The description's mention of inputs with units/ranges/defaults refers to the target calculator's inputs, not to this tool's own invocation parameters, which is appropriate for a describe 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 states what the tool communicates: the calculator's inputs (with units, ranges, defaults), outputs, and underlying assumptions/tables. It is distinct from the sibling 'calculate' tool, which presumably performs the calculation. It lacks an explicit verb like 'describes' or 'returns a reference for', so it is clear but not maximally directive.

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 does not explicitly say when to use this tool versus alternatives such as 'calculate' or 'enquiry_describe'. The intent is implied: this is a reference/discovery tool to understand the calculator before invoking it. However, no explicit conditions, exclusions, or alternative pointers are provided.

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 burden. It transparently states that nothing is bought, ordered, or paid, that no quote is guaranteed, that it is free, and that it returns consent wording and confirmation details. It could go further by explicitly stating whether the tool itself is read-only or has side effects, but the non-purchase framing gives strong practical clarity.

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 concise and front-loaded with the most important guidance: 'Read first.' The two sentences are dense and useful, though there is slight overlap with the title's framing of 'an ENQUIRY with a human' and 'not a purchase, not a guaranteed quote.'

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 covers purpose, key behavioral constraints, and what it returns. It does not explicitly name sibling alternatives or describe their relationships, but it gives enough context for an agent to use this tool safely and effectively.

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 properties, so there are no parameter semantics the description needs to explain. The baseline of 4 for a parameterless tool applies; no additional parameter documentation is required.

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 what the tool does: it explains what submit_enquiry does on 409A Cost, explicitly framing it as an enquiry with human providers, not a purchase or guaranteed quote. It is concrete and references a specific sibling, but it does not explicitly contrast itself with other sibling tools like calculator_describe or enquiry_fields.

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' is a clear ordering cue to use this before taking action, and the title/description explicitly rule out using it to purchase or obtain a guaranteed quote. However, it does not systematically explain when to choose this over calculate, calculator_describe, or enquiry_fields.

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 burden, and it does so by enumerating every piece of metadata returned and noting that options are included only where applicable. It implies a read-only metadata lookup with no parameters, though it does not state the response's exact structure.

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, no filler. The content inventory is front-loaded and the cross-tool usage note is a single short second sentence.

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 metadata tool with no output schema, this description covers the tool's purpose, returned data categories, and relationship to submit_enquiry. Nothing else is needed for correct selection and 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, so the input schema is complete and there is nothing meaningful to document. The description still adds the semantic distinction that field keys are the values to use when submitting answers.

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 (409A Cost enquiry fields) and the exact contents (key, label, type, required, help text, allowed options), so an agent knows precisely what this tool exposes. The title reinforces the purpose and it is clearly distinct from submit_enquiry and enquiry_describe.

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 tells the agent how to use the result: pass answers to submit_enquiry keyed by field key. This provides practical usage context, though it does not explicitly list exclusion conditions or compare against enquiry_describe/calculator tools.

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 burden, and it does so thoroughly. It discloses validation, the Step 1 summary/consent line/token, the email side effect, and the critical condition that no provider sees anything until the person clicks the emailed link. It even includes the exact consent wording.

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 the key 'not a purchase' warning and then organized into Step 1 and Step 2. It is dense but every sentence carries necessary behavioral, sequencing, or consent-related information, 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 multi-step mutation with side effects and no output schema, the description covers the full lifecycle: prerequisites, call arguments, intermediate return values, consent handling, email delivery, and the gating link click. Nothing an agent needs to invoke this correctly 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 input schema already describes all three parameters with 100% coverage, including the consent wording and the confirmation token origin. The description adds useful cross-parameter context: answers come from enquiry_fields, the second call must reuse the same answers, and the token must come from an approved Step 1 summary. However, the schema still handles most of the parameter-level 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 opens with a specific verb and resource: 'Submits an enquiry to 409A Cost', and immediately disambiguates it from related actions with 'NOT a purchase, NOT a guaranteed quote'. It also spells out the two-step nature, so an agent can distinguish submit_enquiry from siblings like calculate or enquiry_fields.

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 invocation rules: Step 1 with answers and consent to obtain a token, then Step 2 only if the person agrees and only with the same answers plus the confirmation token. It also states when not to use the tool ('not a purchase') and references enquiry_fields for the answer keys.

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