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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real operational context on top: $0.04 per call over x402 on Base, a prepaid x-credit-token header for unlimited calls, no free tier, and no API key required. That auth/cost model is exactly the kind of behavior annotations cannot express, though rate limits beyond the pricing note are absent.

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 hook question front-loads the purpose well, but the body is padded with marketing claims ('First lending tooling in the catalog', 'before the market cuts them', 'Not financial advice') that dilute the actionable content. The pricing paragraph is useful, yet the overall length is longer than the two parameters and one return shape warrant.

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?

With an output schema present, the description need not detail return values, and annotations cover safety; the description fills the remaining gaps around cost, auth, and the default market. A minor gap remains: it asserts being 'first lending tooling in the catalog' when siblings like morpho_liquidatable and position_health clearly exist, which could mildly mislead rather than inform.

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 the baseline is 3, but the description adds meaning not present in the schema by disclosing that market defaults to cbBTC/USDC when omitted. It also reinforces that wallet is the required input. This extra default-value semantics lifts it slightly above baseline.

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 verb and resource (reads a Morpho Blue position on Base) and enumerates the returned signals: health factor, current vs liquidation LTV, and the collateral price drop that triggers liquidation. However, it never names its closest siblings (morpho_liquidatable, position_health, near_lending_health), so the agent must infer differentiation from the 'Base/Morpho Blue' scope alone.

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?

Usage is implied rather than stated: 'built for borrowing agents and treasuries that need to know how close they are before the market cuts them' signals the scenario but gives no explicit when-to-use conditions, prerequisites, or when-not-to-use guidance. The only nod to an alternative is the cryptic 'Morpho's own API is deferred', which does not clearly route the agent elsewhere.

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