mv_get_calibration

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

No annotations are provided, so the description carries the full burden. It discloses the return structure (normal range, current status, anomaly threshold, peer comparison, assertion hints) and the auto-detection logic for target_type. However, it does not explicitly state whether the tool is read-only or describe potential side effects, though read-only is implied. This is a minor gap, but overall transparent.

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 well-structured, starting with a clear purpose, then explaining return values, supported protocols, and usage guidance. Every sentence is informative, and it avoids redundancy. The length is appropriate for the tool's complexity, and it front-loads the most important 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 the tool has no output schema, the description comprehensively explains the return structure. It covers all five parameters, includes auto-detection logic, lists supported protocols, and distinguishes from sibling tools. For a tool with this complexity, the description is complete and anticipates user needs.

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%, so baseline is 3. The description adds value by explaining the auto-detection of target_type from address format and describing the return structure, which helps in understanding how parameters map to results. This goes beyond the schema's enum descriptions and justifies a 4.

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's purpose as a 'calibration oracle' that produces statistical baselines from historical data. It specifies what it does (returns percentiles, anomaly thresholds, peer comparison, assertion hints) and distinguishes it from siblings like morpho_get_history and mv_check_ibt_health.

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 explicitly tells when to use the tool ('when you need to CALIBRATE — set thresholds, compare to peers, or export knowledge') and when not to use it (for raw time-series use morpho_get_history/pendle_get_market_history, for single-point health snapshots use mv_check_ibt_health). This provides clear guidance on alternatives.

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