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

Annotations already establish that this is read-only and idempotent, and the description adds useful context about auth (none needed) and a query cap (max 20 queries/session). However, the wording is internally muddled: it mentions a price of 0.01 USDC/query while also promising 'FREE preview — no key, no payment', which creates confusion about whether invoking the tool costs money.

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 overlong and repetitive: it emphasizes 'no key, no payment' and 'FREE' multiple times, includes emojis and promotional calls to action, and buries the actual operational details. The useful facts could be stated in roughly half the length, so the structure is padded rather than efficient.

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 simple read-only preview tool, the description covers the listing, free access, auth requirements, sample questions, and a query cap, while the schema covers the parameters. However, it does not explicitly explain what the response contains and is further weakened by the price-versus-free ambiguity, so it is adequate but not 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%, so the parameters slug and question are already documented adequately. The description adds example questions for the question parameter, which is helpful, but it does not meaningfully clarify parameter semantics beyond what the schema already provides. 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 communicates that this is a free preview of a data listing and even names a concrete listing (marinewatch) with sample questions, but it never clearly states what the tool returns or that it exposes only public metadata. It reads more like a promotional listing ad than a precise tool-purpose statement, and it does not differentiate itself from sibling tools like data_session_query.

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 a clear usage condition: no API key or payment is needed, so this is usable immediately by a guest. However, it does not explain when to prefer data_preview over the paid session/query tools, nor does it specify when not to use it. The guidance is implied rather than explicit.

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