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 useful work: it declares nothing is bought/ordered/paid, no quote is guaranteed, and the interaction is free. It also discloses what the call returns (recipients, consent wording, confirmation flow). It stops short of stating explicitly that this describe call itself has 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?

Front-loaded with the imperative 'Read first' followed by one dense but purposeful sentence. Slight redundancy between 'Nothing is bought, ordered or paid' and 'it is free', 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?

For a zero-parameter tool with no output schema and no annotations, the description compensates well by enumerating what the response conveys (recipients, consent wording, confirmation). An agent has enough to call it correctly and interpret the return, though the exact output shape remains unstated.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate at the argument level. Schema description coverage is 100% of an empty property set.

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 it is a read-first explainer that 'states plainly what submit_enquiry does' and returns recipients, consent wording, and confirmation mechanics. It distinguishes itself from the sibling submit_enquiry by being the non-transactional explainer, though the framing is slightly oblique since it describes another tool's contract rather than its own output in the first clause.

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' is an explicit when-to-use directive that positions this before the write tool (submit_enquiry). It does not mention the other sibling, enquiry_fields, so the alternative-space is not fully closed out, but the primary sequencing guidance is clear.

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 it does disclose the shape of what is returned (field definitions with options). It does not state that the call is read-only, whether it takes arguments, or anything about permissions or rate limits, so the behavioral picture is only partially filled in.

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 tight sentences with no filler; the enumeration of returned attributes comes first and the submit_enquiry workflow note second. Nothing repeats the name or title unnecessarily.

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 input parameters and no output schema, the description is essentially the only source of return-value information, and it covers the fields an agent would need. The remaining gap is the missing relationship to enquiry_describe and any note that the tool is argument-free.

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 the baseline is 4. The description still adds useful semantics by explaining that the returned field keys are the keys used to build the answers payload for submit_enquiry, linking the output to the sibling's input contract.

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 a concrete resource (the SEO for recruitment agencies enquiry) and enumerates exactly what it returns: key, label, type, required flag, help text, and allowed options. That is specific and distinguishable from submit_enquiry, but it never states a verb and gives no hint of how it differs 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 one concrete downstream instruction — pass answers to submit_enquiry keyed by field key — which implies this is the discovery step before submission. However, it never says when to use this tool versus enquiry_describe, and no prerequisites or exclusions are stated.

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 supplied, so the description carries the full behavioral burden and does so: it discloses the validation pass and its returns (summary, consent line, confirmation token), the double-submit requirement, the post-submit email with a required click-through before any provider sees the enquiry, and the literal consent text. This is unusually complete disclosure of a multi-step, human-in-the-loop side effect.

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 purpose and the negative scope before the mechanics, and the two steps are clearly sequenced. It is somewhat long and repeats consent=true and the consent sentence that the schema already carries verbatim, which costs it the top score, but every sentence still carries operational content.

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 describe returns, and it does: step 1 returns a summary, the consent line and a confirmation token; step 2 triggers submission plus a verification email. Combined with nested-object handling (answers keyed by field key) and the human-facing workflow, an agent has everything needed to call it 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 description coverage is 100%, so the 3 baseline is met by the schema alone. The description nonetheless adds real semantics: answers are keyed by field key from enquiry_fields, consent=true is a mandatory precondition, and confirmation must be the token returned by step 1 after approval — meaning the same tool is called twice with different parameter subsets.

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 bounds it with what it is NOT — 'NOT a purchase, NOT a guaranteed quote'. It also names the sibling dependency (enquiry_fields) for how answers are keyed, so an agent can distinguish it from enquiry_describe/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?

Explicit two-step call protocol: step 1 with answers + consent=true, show the person the summary and consent line, then step 2 only if the person agrees, with the same answers plus the confirmation token. It gives the exact gating condition ('only if the person agrees') that an agent otherwise would have to guess.

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