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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered externally. The description adds real value by disclosing that the call is purely informational and performs no navigation or mutation on its own, and by noting API limitations. But the trailing 'Okendo's official API... but with limits (checked 23 Oct 2026)' is too vague to convey what those limits are or why they matter here.

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 key operational fact (returns steps, opens nothing, use browser tools) is present but preceded by filler about ChatGPT/Claude/any AI agent that adds no decision value. The final sentence about the official API is dangling and underspecified. The content earns its place only partially.

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 no output schema, the description must convey the return shape, and it only gestures at it ('step by step (screens, buttons, fields)') without indicating format or granularity. For a zero-parameter, read-only guidance tool this is adequate but leaves genuine ambiguity about whether any actual performance metrics are returned. The API-limits remark raises a question it never answers.

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 nothing for the description to disambiguate; baseline is 4. The absence of parameters is consistent with a pure instruction-lookup call, and no misleading parameter language is present.

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 promise 'get product performance', but the description reveals the tool actually returns procedural instructions ('how to do it in Okendo step by step (screens, buttons, fields)') rather than the performance data itself. That distinction is stated, but it is buried after generic framing ('from ChatGPT, Claude or any AI agent'), so an agent scanning quickly could mistake this for a data-retrieval tool. The purpose is decipherable but muddled between name and behavior.

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 explicitly routes the agent to the cotlet_browser_* tools after obtaining the steps and clarifies it 'opens nothing by itself', which is genuine usage guidance. However, it never says when to choose this over siblings like okendo_answer_product_question or cotlet_app_guide, nor what conditions make this the right first call. Usage is implied rather than delineated.

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