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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and the description adds real context beyond them: the tool returns procedural instructions and "opens nothing by itself," so an agent knows no navigation or mutation occurs and that a separate call sequence is required. The trailing sentence about ProSolutions hosting API help but offering no self-serve API key is unrelated background that consumes space without informing invocation behavior.

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, useful content is the single clause explaining that it returns step-by-step instructions and opens nothing, and that cotlet_browser_* tools carry out the action. That is padded with audience marketing ("from ChatGPT, Claude or any AI agent") and an off-topic note about Paired Plus's public API documentation that does not help an agent call this tool.

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 and no output schema, the description carries the burden of explaining the return value, and it does: step-by-step screens, buttons, and fields. The critical next-step handoff to cotlet_browser_* is also present, so an agent can act; only edge-case handling (no account, unavailable report) is unaddressed.

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 input schema defines zero parameters with no properties, so there is no parameter meaning left for the description to add; baseline 4 applies. Nothing in the description misrepresents the accepted input.

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 verb+resource ("Get business reports") is stated, but the description immediately reframes the tool as returning "how to do it ... step by step (screens, buttons, fields)" rather than reports themselves, which makes the actual deliverable ambiguous against the name. It also does not distinguish "business reports" from the many report-shaped siblings such as paired_plus_get_campaign_report, paired_plus_get_inventory_report, paired_plus_get_sales_insights, or paired_plus_build_custom_report.

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 does point forward to the follow-up path ("then do it with the cotlet_browser_* tools in the user's Paired Plus Cloud Browser"), which is genuine routing guidance. But there is no statement of when to choose this over the specific report siblings, and no prerequisites such as account/plan requirements or what to do if the user is not signed in.

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