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

Annotations already declare readOnly/idempotent/non-destructive, and the description meaningfully adds to that: the tool performs no action itself and only emits guidance text, which tells the agent a follow-up browser step is required to accomplish anything. The remaining gap is that it doesn't describe the shape or length of the returned guidance.

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 message (returns instructions, performs nothing, follow up with browser tools) is stated early and clearly. But the opening clause 'from ChatGPT, Claude or any AI agent' is filler, and the closing sentence about Aircall's public REST API and beta MCP server does not help an agent decide or execute the call.

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, no-output-schema guidance tool, the description covers what it returns and the required follow-up path, which is the essential information. It falls short on disambiguating from cotlet_get_call and on setting expectations for what the returned steps actually cover (e.g., only call-summary screens or broader Aircall flows).

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 there is no parameter semantics to explain; the schema is trivially complete. Baseline of 4 applies.

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 name and title say 'Get call summary', but the description reveals the tool actually returns step-by-step instructions ('screens, buttons, fields') rather than the summary itself — a mismatch the reader has to reconcile. It does clarify the real behavior ('opens nothing by itself; then do it with the cotlet_browser_* tools'), but never distinguishes itself from the sibling cotlet_get_call, which an agent would reasonably assume retrieves actual call data.

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?

There is an implied workflow: call this, then execute the steps with cotlet_browser_* in the Aircall Cloud Browser. That is useful sequencing guidance. However, there is no explicit statement of when to prefer this over cotlet_get_call or aircall_list_calls, and no when-not-to-use condition.

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