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

Annotations already cover read-only, non-destructive and non-idempotent semantics, so the bar is lower; the description adds genuinely new information by disclosing the response shape (identity candidates plus explicit 'unknown' or 'merged' states) and the ambiguity pitfall around shared tickers. It does not explain ordering, ranking of candidates, or what a merged state means operationally, which keeps it below 5.

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?

Two tight sentences leading with the verb and the lookup modes, then the return/ambiguity caveat. Dense and front-loaded, though the phrase 'explicit unknown or merged states' is terser than it needs to be and would benefit from one clarifying clause.

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?

There is no output schema, so the description correctly picks up some of that burden by naming the return categories (candidates, unknown, merged) and the ticker-ambiguity behavior, while pagination and argument discipline live in the schema. It stops short of explaining how candidates are ordered or what to do when multiple candidates come back, which is the main remaining gap for a resolution tool.

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 75% and the schema itself documents limit, query and cursor in detail; the description's value-add is enumerating the query input modes including 'exact namespaced contract', which clarifies the precision expected. The only undocumented parameter is request_id, and the description gives no hint about retrieval semantics, so it is not fully compensating.

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 ('Find') and resource ('stored asset identities') plus the four accepted query forms (name, ticker, canonical key, exact namespaced contract), which is far more informative than the tautological title 'Resolve assets'. Siblings are all research/evidence/list tools, so no direct competitor needs to be ruled out by name, but the description also doesn't explicitly say how it relates to read_price_context or discover_evidence.

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 accepted input forms and the caveat that 'a shared ticker does not prove one intended identity' imply when the tool is appropriate, but there is no explicit when-to-use/when-not-to-use statement and no named alternative. An agent can infer the context from the query forms but must guess the boundary with market/price tooling.

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