site

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

With no annotations provided, the description carries the disclosure burden. It adds one behavioral trait: 'Missing inputs fall back to their documented defaults,' which is useful. However, it does not describe the output format, whether the operation is read-only, or any side effects, leaving significant behavior undisclosed.

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 compact two-part sentence: it names the action and resource, lists the core cost components, and states the fallback behavior. There is no redundant filler, and the most important 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?

The 8 optional parameters are all documented in the schema, but with no output schema the description should clarify what the tool returns. The listed components likely represent output sections, but the absence of an explicit 'returns' or 'output' phrasing leaves room for ambiguity. Overall, it is adequate but not fully 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?

Schema description coverage is 100%, so each of the 8 parameters already has a meaningful description and default value. The tool description adds no new parameter-level insight beyond confirming that missing inputs default, which is already evident from the schema defaults. Baseline 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 uses the specific verb 'Run' with the resource 'AI implementation cost model calculator' and lists the model's cost components (Data preparation; Integration; Change and training; Year one total). The verb 'Run' clearly contrasts with sibling tools like calculator_describe, making the tool's purpose 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 implies this tool is used to execute the cost model calculator, but it does not explicitly state when to use it versus calculator_describe or the enquiry/submit tools. There is no direct comparison or exclusion guidance, though the action-oriented wording offers a mild contextual cue.

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 burden. It transparently states what the tool returns at a high level (inputs, outputs, assumptions, tables) and it is safely implied to be non-mutating, but it does not explicitly say it performs no calculation or expose other behavioral traits such as read-only status or formatting of the description.

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, front-loaded with the subject, and every phrase contributes a distinct category of content. 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 describe tool with no output schema, the description covers the essential content areas (inputs, outputs, assumptions, tables). It is slightly incomplete in not relating itself to calculate or clarifying that it is a read-only explanatory call, but the scope is simple enough that nothing critical 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?

There are zero parameters, so the schema fully documents the input surface and the baseline is 4. The description adds the content semantics of the tool without needing to document 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 identifies a clear verb (describe) and a specific resource (the calculator's inputs, outputs, assumptions, and tables). It is unambiguous that this is the informational companion to calculate, though it does not explicitly name that sibling or contrast itself with it.

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 wording implies this tool should be used to inspect the calculator's model before or instead of running it, and the mention of inputs/outputs/assumptions gives a clear context. However, there is no explicit when-to-use or when-not-to-use statement, nor any named alternative.

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 provided, the description carries the full burden, and it delivers. It explicitly states that nothing is bought, ordered, or paid; no quote is guaranteed; it is free; and it returns details about recipients, consent wording, and confirmation. This gives the agent a clear picture of side effects and output behavior beyond the tool name.

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-loaded with 'Read first,' and each sentence earns its place. It covers behavior, constraints, and return content in three sentences without repetition. This is an efficient, well-structured definition.

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 describe tool with no output schema, the description is largely complete: it references the domain ('AI Implementation Cost'), explains what the tool does, and lists key information it returns. It could slightly improve by explicitly stating 'use this instead of submit_enquiry when you need an explanation before acting,' but this is a minor 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 and the schema covers 100% of that, so the baseline is 4. The description adds useful context about what the tool returns, which compensates for the lack of any input schema detail. No parameter-level clarification is needed because there are 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 states a specific verb and resource: it 'States plainly what submit_enquiry does on AI Implementation Cost.' This clearly differentiates it from action-oriented siblings like submit_enquiry and calculate. The title reinforces the purpose by framing the tool as informational rather than transactional.

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?

Opening with 'Read first' provides clear sequencing guidance: use this tool before taking action with submit_enquiry. It does not explicitly name alternatives or exclusion criteria, but for a describe tool this is sufficient contextual guidance. The sibling list further implies it complements rather than replaces the other 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?

With no annotations, the description carries the burden of explaining behavior. It discloses the full output shape and the relationship to submit_enquiry. It does not explicitly state that the tool is read-only, but the wording strongly implies it is an introspection/retrieval tool with no side effects.

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, both information-dense and non-redundant. The first sentence front-loads exactly what the tool returns, and the second sentence gives actionable guidance for the next step. No wasted words.

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?

This is a simple, zero-parameter introspection tool with no output schema. The description fully covers the return value, including the enumerated field attributes, and explains how to use the result with submit_enquiry. Nothing essential 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 is empty and there are zero parameters, so the baseline is 4. The description adds no parameter documentation because none is needed; instead it explains what the output fields mean, which is the relevant semantic content for this 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 the resource ('every field of the AI Implementation Cost enquiry') and the exact contents returned: key, label, type, required flag, help text, and allowed options. It also distinguishes itself from submit_enquiry by noting that answers should be passed there keyed by field key.

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 communicates its role in the workflow: inspect the enquiry fields first, then pass answers to submit_enquiry keyed by field key. It does not explicitly contrast itself with enquiry_describe or the calculator siblings, but the workflow context is clear enough for correct selection.

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 the two-phase confirmation gate, that an email link must be clicked before any provider sees the data, that up to three agencies will contact the person directly, and the exact consent wording being agreed to. These are real consequences an agent must not misrepresent.

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 critical constraint (NOT a purchase) is front-loaded and the step sequence is ordered clearly. The verbatim consent paragraph is duplicated from the schema's consent description, which is mild redundancy, but it serves the requirement to show the person the exact wording.

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, side-effectful tool with no output schema, the description explains the step-1 return values (summary, consent line, confirmation token), the step-2 effect, and the downstream email-verification and provider-sharing flow. Nothing an agent needs to invoke it 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?

Schema coverage is 100%, so the baseline is 3, but the description adds workflow meaning the schema cannot: answers are keyed by field key from enquiry_fields, consent must be true, and confirmation is only supplied on step 2. That mapping of parameters to phases is genuinely additive.

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 (submits) and resource (an enquiry to AI Implementation Cost), and immediately scopes it as NOT a purchase and NOT a guaranteed quote, which separates it from any transactional sibling. An agent can distinguish this from calculate/enquiry_fields 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 an explicit two-step protocol with the condition that gates each step: step 1 with answers + consent=true, step 2 only if the person agrees and with the confirmation token. It also names the prerequisite data source (.enquiry_fields keys) and the sibling tools that feed it, 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.