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

There are no annotations, so the description must carry the whole burden. It discloses the proposal-then-confirm flow and that Delegated Access / agent keys can execute server-side when policy permits, which is genuinely useful. It leaves out the non-delegated path (returned proposal awaiting user signature), whether cosigner approval applies, and failure behavior when policy denies the deposit.

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 short sentences, front-loaded with the action and the required follow-up call. Every sentence carries information the agent needs: the workflow, the execution model, and the parameter source. Nothing is padded.

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 fund-moving mutation with no annotations and no output schema, the description covers the happy path and the vault-address prerequisite. It remains thin on the non-delegated flow, policy-denial outcomes, and what the call returns. Those gaps are significant for an agent deciding whether to invoke it unattended.

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 already 80%, so the description only needs to fill gaps. It does add real value: it tells the agent that vaultAddress must come from list_yield_markets, which the schema itself does not say. The assetSymbol enum and the wallet-selection parameters are already described in the schema.

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 states a specific verb and resource: "Propose Morpho vault deposit." That is enough to separate it from the sibling propose_yield_withdraw and from propose_transfer. It never explicitly contrasts with those siblings, so a 4 is right rather than a 5.

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?

It gives concrete usage guidance: call confirm_proposal afterwards, and use list_yield_markets to obtain vaultAddress. It does not say when to prefer a direct swap, a transfer, or a withdraw instead, and it does not state what to do if the caller has no Delegated Access key.

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