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

Annotations already flag destructiveHint=true and readOnlyHint=false (a value-moving builder), and the description adds meaningful context beyond that: it returns transactionBase64 only after builder-side RPC simulation passes, gates finalization on safeToApprove=true/approvalBlocked=false, and states the signer boundary where hosted builders never receive keypair bytes. This materially informs the agent about safety behavior. No contradiction with annotations.

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 essential content — purpose, behavioral gating, and SAP routing — is front-loaded in the first paragraph and clearly separated from the boilerplate SAP MCP execution guidance. The structure is reasonable, though the SAP guidance paragraph is somewhat verbose and is duplicated verbatim inside the input-schema description field, which is minor padding against an otherwise tight definition.

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 an output schema exists (covering return values) and the input schema is fully documented, the description covers the remaining agent-critical concerns: the payment/estimation flow, the simulation gate before returning, the approval-flag conditions for finalization, and the local-finalization signer boundary. It is complete for a paid unsigned-transaction builder; only explicit alternative-tool routing is absent.

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% — every parameter (owner, poolName, lpAmountIn, minAmountOut, collateralToken) has a description with formats and enum options. The description adds no parameter-specific detail beyond what the schema already documents, so with complete schema coverage the baseline of 3 applies. The description's mention of 'raw, 6 decimals' merely restates the schema.

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 specific verb+resource: 'Build an unsigned transaction to remove liquidity from an Adrena pool. Burns LP tokens and receives collateral.' This clearly distinguishes it from the many sap_adrena_build_* siblings (add_liquidity, close_long, open_short, etc.) and from the non-build adrena_removeCollateral tool. An agent can identify exactly what this tool does without inspecting the schema.

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 SAP MCP execution guidance block is explicit about the workflow: estimate first via sap_estimate_tool_cost, then pay/build (or use sap_payments_call_paid_tool for non-x402 runtimes), and finalize unsigned transactions locally. It also states the signer boundary clearly. However, it never names alternative tools or states when NOT to use this one relative to related liquidity tools (e.g., adrena_removeCollateral, meteora_removeDLMMLiquidity), so the when-not-to-use dimension is missing.

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