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

Annotations already establish readOnly=true, idempotent=true, destructive=false and openWorld=false, and the description is consistent with all of them ('opens nothing by itself'). It adds genuinely non-redundant context: the return is instructional content with screens, buttons and fields, and execution requires the user's Cloud Browser session via a separate tool family, so the agent knows a single call accomplishes nothing on its own.

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 operational core (returns a step-by-step guide; execute with cotlet_browser_*; opens nothing) is front-loaded and useful. However, the closing sentence about ConnectWise PSA's REST API and the absence of a vendor-hosted MCP server as of 5 Nov 2026 is justification trivia that does not change how an agent invokes the tool, and the second sentence crams three ideas behind a semicolon.

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?

The tool is conceptually unusual (guidance that delegates execution), and the description covers the two things an agent most needs: what comes back (screens, buttons, fields) and what to do next (cotlet_browser_*). With no output schema, that return-shape sentence does real work. It omits whether a pre-existing browser session or account context is required, which is the main residual gap.

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?

With zero parameters there is nothing for the description to disambiguate, so the baseline of 4 applies. It additionally makes clear that no account, ticket list, or browser handle is supplied at call time, which helps an agent understand why the signature is empty.

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 headline 'List tickets in the user's own ConnectWise account' asserts a listing action, but the very next sentence reverses it: the tool 'Returns how to do it in ConnectWise step by step (screens, buttons, fields) and opens nothing by itself.' The true purpose (produce a guided how-to that hands off to browser tools) is eventually clear, but an agent skimming the first clause is actively misled about what the call returns.

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 states the workflow explicitly: call this, then 'do it with the cotlet_browser_* tools in the user's ConnectWise Cloud Browser.' That is a concrete sequencing rule rather than an implied one. It stops short of naming when NOT to call it (e.g., versus the other connectwise_* siblings), so it lands at 4 rather than 5.

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