site

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does well by stating that nothing is bought, ordered, paid for, or guaranteed, that it is free, and that it returns specific information such as consent wording and confirmation mechanics. It could go further by explicitly stating that the tool is read-only and has no side effects, but the content strongly implies that.

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 and front-loads the most important usage signal, "Read first." It packs meaningful distinctions into two sentences without significant fluff. The first sentence is a bit dense, but it still earns its place by explaining what the tool is for.

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 informational tool with no output schema, the description covers the essential context: what it does, what it clarifies, and what information it returns. It could improve by explicitly situating itself among the sibling tools, especially since enquiry_fields and submit_enquiry are natural counterparts, but the core usage context is mostly 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 schema coverage is complete, so there are no parameter semantics for the description to clarify. The baseline of 4 for zero-parameter tools applies here; the description appropriately focuses on behavior rather than inputs.

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 an explanatory resource: it "states plainly what submit_enquiry does" and says it returns details about recipients, consent, and confirmation. It also distinguishes itself from a purchase or guaranteed quote. However, it does not explicitly contrast with the sibling tool enquiry_fields, and the first sentence is slightly ambiguous about whether it is describing the tool or the sibling's behavior.

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" signals that this tool should be used before submit_enquiry, and the description makes clear it is informational rather than transactional. However, it does not explicitly state when to use this tool versus the sibling tools enquiry_fields or submit_enquiry, nor does it provide exclusion criteria or direct routing guidance.

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 behavioral disclosure burden. It discloses that the tool exposes all fields of the enquiry, including constraints like requiredness and allowed options, and it clarifies that actual submission is handled by submit_enquiry, not this tool. This is sufficient for a zero-parameter, read-only field-listing operation.

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 compact sentences with no filler. The first sentence front-loads the essential content of the tool, and the second gives actionable integration guidance. Both sentences earn their 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?

For a zero-parameter tool with no output schema, the description is nearly complete: it names the enquiry, lists every returned field attribute, and explains how to use the output with submit_enquiry. A slightly more explicit statement that the tool returns a field listing or read-only schema would make it 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?

The tool has no parameters and the schema coverage is 100%, so the baseline is 4. The description adds meaningful guidance by explaining that the returned field keys are the keys to use when submitting answers via submit_enquiry, which helps the agent apply the output correctly.

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's resource—the fields of the Private Label Manufacturers enquiry—and enumerates the exact attributes returned (key, label, type, required, help text, allowed options). However, it lacks an explicit operation verb like 'returns' or 'lists', relying on the tool name and phrasing to convey that it is a field-listing tool.

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 clear workflow context by instructing the agent to pass answers to submit_enquiry keyed by the field key. This tells the agent what to do with the output and implicitly distinguishes this tool from the submission tool, though it does not explicitly discuss when not to use it or contrast it with 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?

With no annotations, the description carries the full burden and does so well: it discloses that step 1 only validates, that a confirmation token is required for the actual write, that the person must click an email link before any provider sees the data, and that details go to up to three firms. It stops short of stating idempotency, rate limits, or token expiry, so a 4 rather than 5.

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 negative scope, then the two steps in order, each sentence earning its place. Slightly long because the full consent sentence is reproduced verbatim (already present in the schema's consent description), which is mild redundancy.

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 nested-object, two-step submission tool with no output schema and no annotations, the description supplies everything needed: what is returned (summary, consent line, token), what to show the user, when to make the second call, and what happens after submission.

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 already 100%, so the baseline is 3, but the description adds real cross-parameter semantics: answers must be keyed by the field keys from enquiry_fields, consent must be true, and confirmation is only supplied on the second call after approval. That sequencing meaning is not derivable from the schema alone.

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 Private Label Manufacturers') and immediately scopes it negatively with 'NOT a purchase, NOT a guaranteed quote.' This distinguishes it from the describe/fields siblings, which merely supply input data rather than submitting anything.

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: Step 1 call with answers+consent=true to validate and get a token, Step 2 only after the person agrees, with the token. It also names the dependency on enquiry_fields for the answer keys and states the precondition (person must have read and agreed to the consent text).

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