Price at which a position breaks even after entry/exit fees and slippage, long or short. 0.001 USDC per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | long or short | long |
| entry | Yes | Entry price | |
| feePct | No | Fee percent per side | |
| slippagePct | No | Slippage percent per side | |
| paymentProof | No | Payment proof: USDC tx hash on Polygon or Base (0x...) or Solana tx signature. Omit on the first call to receive the 402 payment instructions, pay, then call again with the proof. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It usefully states the cost (0.001 USDC per call) and x402 payment model, but does not describe read-only behavior, output format, or other operational traits such as determinism or rounding.
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 two tightly written sentences with the core calculation front-loaded and the payment cost appended without clutter. Every phrase contributes useful 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?
For a calculation tool with a fully described schema and no output schema, the description adequately conveys that the result is a break-even price. It could mention return denomination or rounding, but the essential behavior is clear.
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 description coverage is 100%, so all five parameters are already documented in the schema. The description reinforces that side, entry, fees, and slippage are relevant, but adds no parameter syntax or meaning beyond what the schema provides.
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 that the tool computes the break-even price after entry/exit fees and slippage for long or short positions. The purpose is specific and immediately understandable, though it does not explicitly differentiate itself from related calculation siblings such as position_pnl or liquidation_price.
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 provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites beyond the payment note. Usage is only implied by the tool name and the calculation it describes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.