site

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

With no annotations, the description carries the full burden and does substantial work: it discloses that the tool returns recipient details, consent wording, and the confirmation step, and clarifies the enquiry flow is free with no purchase or guaranteed quote. It never explicitly states it is a side-effect-free read, which a no-annotation tool ideally would.

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 two-word opener "Read first." front-loads the key directive, and the remaining sentences each add distinct content (purpose, non-transactional nature, return contents). Slightly dense but no filler sentences.

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 and no annotations, the description compensates well by enumerating what is returned (recipients, consent wording, confirmation). It stops short of describing the format or length of the returned text, which is a minor remaining 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 takes zero parameters, so per the rubric the baseline is 4. There is no parameter information the description could add, and none is needed.

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 function: it documents what submit_enquiry does (starts an enquiry with human providers who quote directly) and enumerates the content it returns. It names the sibling submit_enquiry explicitly, but says nothing about enquiry_fields, so sibling differentiation is only partial.

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?

"Read first" gives explicit sequencing guidance relative to submit_enquiry, telling the agent when in the workflow to call this. It does not name a when-not-to-use case or point to enquiry_fields as the alternative, so guidance is clear but incomplete.

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 and no output schema, the description carries the full burden and largely meets it by listing the exact fields returned and hinting at the key/value linkage with submit_enquiry. It omits any statement about side effects or error behavior, but for a zero-parameter read-only lookup that is a minor 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?

Two sentences, no filler, and the payload description is front-loaded before the integration hint. Every clause 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?

Because there is no output schema, the description must convey the return shape, and it does so item by item while linking the result to submit_enquiry. The only omission is routing the agent away from enquiry_describe when field metadata is what is actually wanted.

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 zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. No misleading parameter claims are made.

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 enumerates exactly what this tool returns for the Cost SEO enquiry: key, label, type, required flag, help text and allowed options. That is a clear resource-level statement, though the verb is implied rather than stated and it does not distinguish itself from the sibling 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?

It gives explicit forward guidance: use the returned field keys when calling submit_enquiry. It does not explain when to prefer this over enquiry_describe, so the sibling boundary is left to inference.

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 well: it discloses that this is not a purchase or guaranteed quote, that step 1 only validates, that step 2 triggers submission and a double opt-in email requiring a click before providers see anything, and the exact consent text. It leaves a few gaps – auth requirements, whether the confirmation token expires, and what happens on a failed validation or a repeated step-2 call.

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 most decision-relevant fact (enquiry, not purchase) is front-loaded, and every sentence carries information about the protocol. It is dense and slightly run-on, packing both steps and the consent wording into one paragraph, but nothing is wasted.

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 correctly compensates by stating what step 1 returns (summary, consent line, confirmation token) and what happens after step 2 (email with a verification link). For a nested-object, two-step mutation this is complete enough for an agent to execute 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot: it explains the two-phase sequencing of the confirmation token (only sent after step 1 and only used in step 2), and ties answers to the field keys from enquiry_fields. That is genuine added semantics beyond the parameter descriptions.

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 gives a specific verb and resource ('Submits an enquiry to Cost SEO') and immediately carves out what it is not ('NOT a purchase, NOT a guaranteed quote'). It is clearly distinguishable from the discovery siblings enquiry_describe and enquiry_fields, which gather information rather than submit 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?

Usage is spelled out as an explicit two-step protocol with the condition that gates step 2 ('only if the person agrees'), plus the requirement to show the summary and consent line to the person. It also points to enquiry_fields as the source of the field keys used in answers.

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