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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with an unambiguous statement that no API, RPC, indexer, or network request occurs. It goes further by telling the agent it must supply its own discovery from external sources, which is exactly the behavioral surprise an agent needs flagged.

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 sentences, front-loaded with the core fact (local, bounded, pinned catalog) followed by the no-network constraint and the agent's required follow-up work. Nothing is redundant, though 'official direct-discovery guidance' is somewhat vague phrasing that could be tightened.

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 a single optional filter and an output schema that already describes return values, the description covers the essential behavior: locality, no network access, and the required intersection step. It could say more about how extensive the fixed catalog is or what happens when a requested chain is absent, but the gaps are minor.

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% and the single chain_id parameter is fully documented there as an exact filter on the fixed catalog. The description mentions intersecting with 'fixed chain, vault, and asset addresses' but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 concrete verb-plus-resource: it returns a local, bounded, pinned catalog of listed Morpho Vault V2 deployments. The scope qualifiers ('bounded', 'pinned', 'listed', 'V2') separate it cleanly from sibling tools like prepare_morpho_vault_deposit and from a live-chain query tool.

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 gives a clear usage context: use this for the static catalog, then query Morpho's GraphQL API and onchain state yourself and intersect against the fixed addresses before preparation. It implies the pre-step role before the prepare_morpho_vault_* siblings without naming them explicitly, so the routing signal is strong but not fully explicit.

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