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

Annotations already provide readOnlyHint=true, and the description aligns with that by describing a read-only historical query. The description adds value beyond annotations by specifying the ordering ('newest first'), the scope ('one tracked keyword'), and the plan requirement. No destructive behavior is implied, and the description reinforces the read-only nature.

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 description is concise at three sentences, each serving a distinct purpose: function, usage guidance, and prerequisites. The most critical information is front-loaded ('SERP history for one tracked keyword'), and there is no redundancy or fluff. Every sentence earns its place.

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 has only two parameters and no output schema. The description covers the return concept ('which apps ranked in the top results on each measured day') and ordering, but it does not specify the exact output format (e.g., array of objects with date, ranks, app identifiers). For a tool with no output schema, additional detail on the response structure would help agents parse results correctly. It is adequate but not fully complete.

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 description coverage is 100%, with both parameters (keyword_id and days) clearly described in the schema. The tool's description does not add any additional parameter details beyond what the schema already provides. It reinforces that the keyword must be tracked, but that is implicit from the schema's 'keyword_id from sonar_app_keywords' hint. Baseline 3 is appropriate.

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 clearly states the tool returns 'SERP history for one tracked keyword' with 'which apps ranked in the top results on each measured day, newest first.' It uses a specific verb ('get history') and resource ('keyword SERP rankings'), and the context of 'tracked keyword' distinguishes it from sibling tools like sonar_keyword_metrics (aggregate metrics) or sonar_keyword_search (search for keywords).

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 explicitly says 'Use this to see who competes on a keyword and how the top spots shifted over time.' It also provides prerequisites: 'The keyword must be tracked in the caller's Sonar workspace' and 'Requires an Indie plan (trial counts).' This gives clear context for when to use it, though it does not explicitly mention alternatives or when not to use it.

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