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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description is consistent with them, adding the non-obvious behavior that the tool 'opens nothing by itself' and instead returns screen-by-screen instructions. It also discloses the external API limitation (read-only, not self-service), which the agent could not infer from the schema. The only missing detail is the shape of the returned instructions (how many steps, per-screen granularity) in a tool with no output schema.

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 core behavior and the follow-up tooling are front-loaded in the first two sentences, and there is no filler. The closing note on the External API is slightly tangential but earns its place by explaining why a browser path exists.

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, read-only guidance tool with no output schema, the definition covers what is returned, what is not done, and the handoff to the cotlet_browser_* tools. The remaining ambiguity is how the specific quote is identified with no input parameters, which an agent may need resolved.

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. There is nothing for the description to disambiguate, though it could usefully have noted how the target quote/project is determined given that no inputs are accepted.

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 opening sentence names a specific verb and resource ('Submit quote in the user's own EstimateOne account'), and the second sentence clarifies the distinctive nature of the tool: it returns step-by-step instructions rather than performing the submission. That distinguishes it cleanly from sibling mutators like estimateone_revise_quote or estimateone_set_quote_response.

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 tells the agent exactly what to do next: take the returned steps and execute them with the cotlet_browser_* tools. It also preempts the obvious alternative ('EstimateOne has an External API, but it is not self-service and it is read-only'), explaining why the browser route is required. It does not explicitly contrast with revise_quote or set_quote_response, which is a minor gap.

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