analyze_company

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

With no annotations, the description carries the full burden, and it delivers meaningful behavioral context: it is a composite pipeline, it reuses other tools' results, and it benefits from shared/cached Yahoo fetches. It does not explicitly declare read-only behavior or failure modes, but for an analysis-only tool this is reasonably transparent given the output schema.

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 dense but every sentence earns its place: the first sentence establishes scope and content, the second explains the composite/cached implementation advantage, and the third documents the parameter. The key purpose is front-loaded with no filler.

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?

An output schema exists, so the description does not need to enumerate return fields. It fully explains what the tool does, lists the major analysis components, identifies its relation to sibling tools, and documents the sole parameter with examples. For a complex pipeline tool, nothing essential is missing.

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 only says 'Symbol' with no description coverage, so the description fully compensates by documenting the lone parameter: ':param symbol: ticker symbol, e.g. "RELIANCE", "TCS.NS", or "TCS.BO".' Concrete examples and exchange suffix conventions remove all ambiguity.

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?

Starts with a specific verb and resource: 'Run the complete fundamental-analysis pipeline for one NSE/BSE-listed Indian equity in a single call.' It enumerates the covered analyses (profile, ratios, growth, margin trends, etc.) and explicitly notes that it 'Composes every other tool in this server,' distinguishing it clearly from the individual sibling tools.

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 makes the primary use case clear: get a complete fundamental analysis in one call rather than invoking many separate tools. It also explains that this approach is cheaper because Yahoo fetches are shared/cached. However, it does not explicitly state when NOT to use it, such as when only a single metric or statement is needed.

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