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

Annotations already establish that this is a non-read-only, non-idempotent, non-destructive, closed-world mutation. The description adds genuinely new behavior: the data is user-supplied, the resulting dashboard is access-scoped ('bearer-private'), and artifacts self-delete after one hour. It omits the consent gates implied by rights_confirmed/retention_confirmed, which default to false, and says nothing about duplicate or repeat-import behavior despite idempotentHint=false.

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 sentences, purpose front-loaded, retention behavior second — no filler or repetition. The only cost is that 'bearer-private interactive dashboard' compresses several concepts into an opaque phrase rather than spending a few words to clarify access scope.

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 10-parameter import tool with 0% schema description coverage and mandatory-sounding consent booleans, two sentences are far short of sufficient. An output schema exists so return values need no explanation, but the description leaves an agent unable to know what each input means, which sources are mutually exclusive, or what must be true to legitimately import.

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 10 parameters, so the description carries the full burden and adds almost nothing. It only hints that 'user-supplied option-chain data' maps to source_data/source_text, leaving symbol, expiry, rate, source_format, data_source, dividend_yield, and both consent flags entirely unexplained — the last two being the most consequential for correct invocation.

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 gives a specific verb and resource: 'Import user-supplied option-chain data' plus the destination, a 'bearer-private interactive dashboard'. That is enough to tell it apart from option_delete_snapshot or option_validate_snapshot, though it never names a sibling or states the boundary explicitly. 'Bearer-private' is unexplained jargon that slightly blurs what exactly is being created.

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?

There is no guidance on when to import versus call option_chain_snapshot, option_validate_snapshot, or option_plots_from_snapshot, and no stated prerequisites. Nothing tells the agent which input form to prefer or what conditions must hold before an import is allowed.

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