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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true, so the description's 'Free read' aligns with annotations. The description adds the SAP MCP execution guidance about pricing, routing, and signer boundary, which is useful context beyond the annotations. However, it doesn't disclose specifics like pagination behavior, rate limits, or what exactly 'free read' means in terms of data freshness or coverage. It doesn't contradict annotations, but doesn't add substantial behavioral detail beyond the guidance block.

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: two sentences for the core purpose, followed by a structured SAP MCP execution guidance block. The first sentence is front-loaded and immediately clear. The execution guidance is somewhat repetitive with the input-schema description (both contain the same SAP MCP guidance text), which is redundant. But the core description is efficient and the guidance is organized into labeled segments (Intent, Pricing, Routing, Signer boundary).

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 is complete for a read-only, idempotent, open-world tool. It covers intent, pricing, routing, and signer boundary. The output schema exists, so return values are documented. The only gap is that it doesn't explain when to prefer this over coingecko_getOHLCV or other candle-related siblings, but the 'Phoenix market' scope is clear enough. Given the tool's simplicity (3 params, no nested objects, read-only), the description is sufficient.

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 coverage is 100% — all three parameters (symbol, timeframe, limit) are described in the schema with types, ranges, and examples. The description adds context by stating the resource is 'Phoenix market' and the data type is 'OHLCV candles', which helps interpret the symbol parameter (should be a Phoenix market symbol). The 'Max candles (default 100)' in the schema is clear. The description doesn't repeat parameter details but the schema does its job well, so the baseline 3 is exceeded slightly by the contextual framing.

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 explicitly states 'Get OHLCV candles for a Phoenix market' — a specific verb, resource, and data type. It clearly differentiates from siblings like sap_phoenix_get_market, sap_phoenix_get_orderbook, and coingecko_getOHLCV by naming the Phoenix market and OHLCV candles. The 'Free read' qualifier adds clarity.

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 states 'Free read' and the SAP MCP execution guidance says 'Intent: read/discovery workflow'. This implies when to use it: for read-only candle data, not for value-moving operations. It doesn't explicitly name alternatives (e.g., coingecko_getOHLCV for non-Phoenix markets), but the context signals and 'Phoenix market' scope effectively communicate the primary use case. No explicit exclusion of alternatives, but the intent classification is clear.

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