Calculate a stablecoin's deviation from its target peg using a single mid price or a stored quote series, with threshold checks for out-of-peg conditions.
Stablecoin deviation from its peg, from one mid price or from the lake.
| Name | Required | Description | Default |
|---|---|---|---|
| ask | No | ||
| bid | No | ||
| price | No | ||
| symbol | No | ||
| target | No | ||
| threshold | No | ||
| asset_class | No | Which market answers. Inferred from the symbol's source when omitted. |
Changes observed during successful MCP inspections.
v0.3.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden, and it says nothing about what is returned (deviation value? flag against threshold?), whether it errors on unknown symbols, or how threshold changes output. The 'neither is an error' nuance appears only in the schema description, not here.
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?
A single short sentence, front-loaded with the purpose — efficient, but so terse that it omits the mode logic that makes the tool usable. Brevity comes at the cost of specification here.
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?
7 optional parameters, no annotations, no output schema, and low schema coverage: the description would need to explain mode selection, default target/threshold semantics, and expected output for the agent to call it reliably. It does not.
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 only 14% (just asset_class), so the description should compensate for 7 parameters, yet it mentions neither target nor threshold, and only gestures at price/bid/ask and symbol. The valuable mode arithmetic is buried in $defs rather than the tool description.
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?
States a specific resource (stablecoin deviation from peg) and sketches two input modes ('one mid price' vs 'from the lake'). It is distinguishable from sibling tools like basis or spot-future-basis, though 'the lake' is internal jargon an agent may not decode.
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?
No guidance on when to pick this over alternatives (e.g. basis, onchain-price) or which mode to choose; the mode-selection logic lives only inside the schema's $defs text, not the description. The agent must open the schema to learn that a derivable mid means pure mode, a symbol means lake mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.