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

Annotations already mark this read-only, idempotent, non-destructive and closed-world, and the description reinforces rather than contradicts them: 'opens nothing by itself' and 'returns how to do it step by step'. It also explains the non-obvious rationale for browser automation — EstimateOne's External API is not self-service and is read-only — which is context no annotation or schema could convey.

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?

Purpose and workflow are front-loaded in the first sentence, and the API note is short and relevant as justification for the browser-based approach. The middle sentence is a bit crowded ('Returns how to do it ... and opens nothing by itself; then do it with ...'), but no sentence is expendable.

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 schema and no output schema, the description carries the burden of describing what comes back, and it does so ('step by step, screens, buttons, fields'). It stops short of saying what the agent must already know or gather (e.g., which quote/tender) before the returned steps are actionable.

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 and there is nothing for the description to disambiguate. The description does not need to explain parameter meaning and correctly stays silent on that front.

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 resource (a quote response in the user's EstimateOne account) and, crucially, clarifies that the tool does not perform the action itself but returns step-by-step guidance for doing it in EstimateOne. That resolves the mismatch implied by the name 'set_quote_response'. It does not, however, differentiate itself from siblings like estimateone_revise_quote or estimateone_submit_quote, which likely do perform mutations.

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 a clear workflow: call this first to get screens/buttons/fields, then execute the steps with the cotlet_browser_* tools in the user's EstimateOne Cloud Browser. What is missing is an explicit exclusion — when an agent should prefer estimateone_revise_quote or estimateone_submit_quote instead of this guidance tool.

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