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

Despite the annotations already declaring readOnlyHint and idempotentHint, the description provides extensive behavioral context that surpasses what annotations convey. It details the baseline snapshot, the incremental update behavior ('market_update carries only the items that changed'), content exclusions (fuel, contraband, private Company Store orders), the shared nature of the feed, and the automatic subscription drop on undock or disconnect. No contradiction with annotations exists.

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 information-dense and every sentence contributes meaningful behavioral or usage detail. However, it is somewhat long and contains a formatting typo ('(Best over a persistent connection') and awkward nested parentheses that slightly impair readability. It is front-loaded with the purpose and alternatives, and the length is justified by the richness of the behavior, but it could be tightened.

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 description fully covers what an agent needs to know to invoke this correctly: what the subscription returns (full snapshot), how updates are delivered (market_update messages with changed items), what is excluded (fuel, contraband, private orders), and the subscription lifecycle (auto-drop on undock/disconnect). There is no output schema, but the description compensates by describing the return behavior comprehensively. Even with the sibling subscribe_observation present, no additional context is missing.

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 schema covers the single parameter (session_id) with a clear description, and the schema description coverage is 100%, so the description does not need to add parameter-level detail. The description adds no specific parameter semantics beyond the schema, which is acceptable given the full coverage. Baseline 3 applies because the schema handles the explanatory burden.

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's function: 'Subscribe to live market updates at the current station.' It specifies the resource (market at the current station), the mechanism (persistent WebSocket connection), and the delivery format (snapshot baseline plus 'market_update' messages). It explicitly differentiates from view_market by framing this as an alternative to polling, making it easy to distinguish from siblings.

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 this is used 'instead of polling view_market repeatedly,' which directly guides when to choose it over a close sibling. It also states a clear exclusion: private Company Store orders are not in the feed and instructs users to use 'view_market company_store:true' for that purpose. This gives the agent both a positive use case and an explicit alternative, leaving no ambiguity about selection.

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