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

The description implies the tool is read-only (computes and returns values without side effects), but annotations specify readOnlyHint=false, creating a contradiction. The description does not disclose any other behavioral traits beyond pricing and routing, which are already indicated elsewhere. The contradiction overrides any positive disclosure, resulting in a score of 1.

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 split into two parts: a concise tool-specific sentence and a lengthy block of generic SAP MCP execution guidance. The guidance is necessary for paid tool usage but is not concise and repeats boilerplate found in other SAP tools. The tool-specific part is efficient, but the overall structure includes redundant information.

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?

Given that an output schema exists (not shown), the description does not need to detail return values. It mentions data source (DexScreener) and efficiency gains. It lacks mention of data freshness or any prerequisites, but for a compute tool with good annotations and output schema, it is reasonably 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 coverage is 100% with descriptions for all three parameters (mint, indicators, resolution). The description adds the list of indicator names but does not provide additional meaning beyond the schema (e.g., default behavior for missing indicators or resolution). Given full schema coverage, 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 computes specific technical indicators (RSI, EMA-20, EMA-50, MACD, Bollinger Bands, ATR) from DexScreener price data, with a specific verb ('Compute') and resource ('technical indicators from DexScreener price data'). It also mentions returning pre-calculated values with signals, distinguishing it from sibling tools that likely return raw OHLC data (e.g., sap_chart_ohlc).

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 lacks explicit guidance on when to use this tool versus alternatives (e.g., sap_chart_ohlc or coingecko_getOHLCV). It does not mention use cases, prerequisites, or when not to use it. The only guidance provided is about SAP MCP execution routing, which is generic and not specific to tool selection. This leaves the agent without clear direction on tool choice.

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