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

Goes well beyond the annotations: it discloses the cost model ('Every started minute of the session costs credits'), the session lifetime ('ends when closed or 3 minutes after the last call'), and that the user observes everything live. These are non-obvious operational constraints an agent must know before calling, and nothing here conflicts with readOnlyHint=true or openWorldHint=true.

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?

Five short sentences, front-loaded with what the tool is, then alternatives, return values, and cost. Every sentence carries information an agent needs; there is no filler or repetition of the title.

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?

Despite having no output schema, the description states what comes back ('returns the page's URL and title'), what triggers the session to end, and what it costs. Combined with 100% schema coverage, an agent has everything needed to call it correctly and know when to stop.

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?

Schema coverage is 100% and the schema already explains the URI format and the app-browser case, so 'Opens `url` when given' adds only the small fact that the parameter is optional. That matches the baseline for a well-documented single parameter.

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 names a specific verb and resource ('Wakes the user's Substack Cloud Browser, a real Chrome hosted on Cotlet') and explicitly scopes it against the rest of the toolset. The distinction from cotlet_browser_navigate/click is implicit but the framing as the session-start tool is clear, and an agent can tell it apart from the plain Substack API tools without opening any schema.

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?

'Use it for what the Substack tools do not cover' gives a clear routing rule to the agent and names the category of alternatives. It stops short of naming the follow-on browser siblings (navigate, click, read) that this call enables, so the handoff sequence is left to inference.

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