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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the safety profile is covered. The description then adds real behavioral context: data provenance (SEC XBRL filings, FINRA settlement data), the guarantee that 'every figure carries the date it holds for,' and a detailed fallback for unlisted companies that returns prospectus and fund-file data instead of a price — a genuinely useful disclosure for an edge case an agent could otherwise misread as an error.

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 body is a single dense paragraph with nested asides ('debt as the filed balance sheet presents it — each line, with the page on sec.gov —') that reads as a field dump rather than a structured summary. Roughly half the text is an exhaustive pre-IPO field inventory, which is disproportionate to a rare edge case and buries the primary when-to-use guidance mid-paragraph.

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?

With no output schema, the description carries the full burden of describing returns and does so exhaustively, including the pre-IPO variant and as-of dating of every figure. It omits only peripheral behavior — what happens for an unknown ticker, whether fields can be null or omitted, and any rate or cost characteristics.

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?

There is a single required parameter with 100% schema description coverage, including examples and a case-insensitivity note, so the schema fully documents `symbol`. The description adds nothing about the parameter itself, but with one fully-documented parameter the baseline of 3 is exceeded only marginally rather than needing compensation.

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 opening sentence gives a specific verb and resource ('Returns one company's current snapshot') and then enumerates the data domains covered (price, performance, fundamentals, short interest, SEC profile). This is clearly a single-company lookup, which separates it from compare_companies and the list/screen tools, though it never names a sibling to sharpen the boundary against get_financials or get_price_history.

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 supplies an explicit trigger: 'Use it when the user asks about one company's price, market cap, valuation, fundamentals or risk,' and it defines the pre-IPO branch handled by the same tool. It stops short of exclusions or alternatives — an agent gets no instruction on when get_financials, get_price_history, or get_market should win instead, despite heavy overlap in the listed fields.

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