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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'opens nothing by itself', which is consistent and removes the main risk of a tool named 'create'. It also discloses the return artifact (screens, buttons, fields) and the prerequisite that Jobber's GraphQL API cannot be used without registering an app. It stops short of saying whether a Jobber browser session must already be open.

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 browser follow-up are front-loaded and well ordered. The trailing sentence about Jobber's official GraphQL API and app registration is a tangent to invoking this specific tool and is verbose. The 'from ChatGPT, Claude or any AI agent' phrasing is marketing padding that does not help selection.

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 zero parameters, no output schema, and rich annotations, the description covers the essentials: what it returns, that it has no side effects, and what to do next. Minor gaps remain around whether the Cloud Browser must be open beforehand and what happens on an unauthenticated Jobber account.

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 schema has nothing to explain and the baseline is 4. The description does not need to add parameter meaning, and it adds none, which is appropriate.

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 verb and resource (create a quote in the user's Jobber account) and then explicitly redefines what the tool actually does: returns step-by-step instructions rather than performing the action. That clarification is essential because the name implies a write operation, and without it an agent would misjudge the tool. Slight deduction because the opening sentence still frames it as 'Create quote', which is only corrected mid-description.

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 tells the agent the follow-up path explicitly: 'then do it with the cotlet_browser_* tools in the user's Jobber Cloud Browser.' That is a concrete alternative to invoking a creation API. It does not distinguish this from cotlet_app_guide, which is the nearest sibling for account-specific guidance, so the routing is clear but not complete.

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