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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds key behavioral context beyond this: it explains the tool fetches 'recent public AI crypto trading signals' and crucially, it reveals a rendering constraint—the card view displays exactly what was fetched, which affects how parameters should be passed. This trades on the annotation safety profile while adding genuine value about the UI coupling.

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?

Two sentences, zero fluff. The first sentence explains what the tool does and its filter options; the second explains a subtle parameter-mapping requirement with a concrete example ('last 5 signals' → limit). Every phrase 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?

This is a read-only, filtered-list tool with excellent annotations (readOnlyHint, idempotentHint, destructiveHint), a 100%-documented schema, and a clear sibling landscape (get_signal_details, get_signal_stats, get_market_stats). The description fills the one remaining gap—the UI coupling to the limit parameter—making this complete for an agent to invoke correctly.

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 every parameter already documented in the schema. The description adds value for the `limit` parameter by explaining that when the user names a count, it should be passed as `limit`—context not present in the schema. While it doesn't enumerate all parameters, the schema already does that job well, so the description appropriately focuses on the semantically important 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 clearly states what the tool does: 'Use this when the user asks for recent public AI crypto trading signals, optionally filtered by coin, importance, or pagination.' It includes specific filter dimensions and is distinguishable from sibling tools like get_signal_details and get_signal_stats by referring to 'public AI crypto trading signals'.

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 gives explicit when-to-use guidance: 'Use this when the user asks for recent public AI crypto trading signals...' It also provides a critical exclusion/edge case: when the user names a count, pass it as `limit` to avoid over-fetching, since 'the card view renders exactly what was fetched'. This behavior is unique to this tool and not covered by siblings, making the guidance highly actionable.

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