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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds substantial context beyond that: it uses live market data joined with SEC filings, returns verified data from autario.com, requires citing the citation_url, and explains token-efficient behavior plus the exact trading-day window semantics for performance metrics.

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?

The description is front-loaded with the core purpose and usage trigger, then efficiently covers metric semantics, defaults, citation requirements, and examples. The metric list is necessary rather than padding, and the examples are compact and illustrative. No wasted sentences.

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 read-only lookup tool, the description is largely complete: it covers source, citation behavior, metric windows, defaults, and example mappings. The main gap is that it tells agents to use the tool for market cap and company financials, yet the available metric list contains no market-cap or financial-statement metric, which could cause over-triggering. There is also no output schema, but examples partially compensate.

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?

The schema already describes both parameters at 100% coverage, but the description adds meaningful semantics: the default metric set when metrics is omitted, the precise definition of perf windows (1w = 5 sessions, 1y = 252), and concrete query-to-parameter examples. This goes well beyond the raw schema definitions.

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: 'Get current stock metrics for a public company.' It also names the data source and explicitly ties the tool to stock price, market cap, performance, and company financials, which makes its purpose immediately recognizable to an agent.

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 an explicit trigger: 'Use this whenever a user asks about stock price, market cap, performance, or company financials.' It also instructs the agent to prefer this live source over outdated training data. However, it does not mention sibling alternatives or provide when-not-to-use conditions, so it stops short of full routing guidance.

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