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

No annotations exist, so the description carries the full burden and it does substantial work: it declares read-only, discloses the three-way verdict (ALLOW/CAUTION/BLOCK), states what is evaluated separately (collateral vs loan oracle integrity), and explicitly disclaims signing, broadcasting, or authorizing. Remaining gaps (stale-oracle handling, rate limits, failure behavior) keep it at 4.

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?

Three dense sentences with the read-only scope front-loaded and no filler. The middle sentence is long but every clause adds a distinct capability; the final sentence delivers the critical safety disclaimer.

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 no output schema and no annotations, the description does explain the return verdict values and the non-signing contract, which is the most important missing piece. However, for a 7-parameter gate with zero parameter documentation, it leaves an agent guessing at how to populate the USD value fields and when the optional marketId is required.

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 0% across 7 parameters, so the description must compensate and largely does not. It only obliquely hints at protocolId (Aave V3 / Morpho Blue) and marketId ('an exact Morpho Blue market') and mentions caller-declared LTV, but never explains collateralSymbol, loanSymbol, collateralValueUsd/debtValueUsd, or the supply/borrow action semantics.

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+resource: a read-only pre-signing gate for Monad lending against Aave V3 or an exact Morpho Blue market, with named checks (oracle integrity, LTV vs live params) and a verdict output. An agent can distinguish this from the sibling monad_lending_guard_exact_call and the generic pre_trade_safety_check without opening 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 description makes the usage context clear ('pre-signing gate', 'direct Aave V3 or an exact Morpho Blue market') and adds a binding instruction: bind a successful decision to an exact user-authorized transaction separately. It never names an alternative tool or an explicit when-not-to-use case, so it stops short of a 5.

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