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

The description says the tool 'Reads... accounts and returns' a readiness result, which is a read-only operation. The annotations set readOnlyHint=false, implying the tool may modify state; this is a direct annotation contradiction. In addition, the description calls the tool 'Free... check' while the appended SAP guidance says 'Pricing: paid read-premium,' leaving the cost side-effect ambiguous.

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 tool-specific opening sentences are concise and front-loaded. However, the appended 'SAP MCP execution guidance' paragraph is boilerplate that repeats verbatim in the schema description and introduces a cost statement ('paid read-premium') that conflicts with the opening 'Free ... check', adding unnecessary length and ambiguity.

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 covers the workflow placement, the ready=false decision rule, and generic execution constraints, and the output schema exists. But the free/paid contradiction and the readOnlyHint mismatch leave the agent uncertain about whether the tool has side effects or costs, and the conditions under which to call payment helpers are ambiguous despite being repeated.

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?

Input schema already documents all 4 parameters with 100% coverage: poolName enum, principal/collateral examples and usage rules, requiredSymbols derivation. The description adds a layer above the schema by framing the three route parameters as an 'exact market/pool/collateral route' and tying them to the oracle freshness check, which helps the agent pick the right combination.

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 opens with a concrete verb+object: 'Free Adrena execution readiness check for an exact market/pool/collateral route' and then specifies the mechanism: reads on-chain pool, custody, and oracle accounts and returns whether each required oracle symbol has enough fresh prices for Adrena minAgree. This makes it clearly distinct from the surrounding get_* and build_* siblings, especially since it explicitly positions itself before sap_adrena_build_* open-position tools.

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?

It explicitly states when to use: 'Use this before any sap_adrena_build_* open-position tool,' and provides the conditional rule for not proceeding when ready=false: 'do not show approval and do not call sap_payments_finalize_transaction.' The SAP MCP guidance also tells the agent how to route/pay for the read. No stronger usage guidance is needed.

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