key_ratios

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

With no annotations provided, the description carries the full burden. It openly discloses the scope of returned data (valuation, profitability, growth, etc.) and market coverage (Indian/US). It does not mention potential errors, data freshness, or permission requirements, but for a simple data retrieval tool, the disclosure is adequate and adds value beyond the 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 well-structured with a clear opening, bulleted metric categories, market scope, Args, and examples. Every line serves a purpose: the categories tell the agent what to expect, the market scope prevents misapplication, and examples illustrate correct invocation. It is concise enough for the information provided.

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?

Given the tool has a single parameter and an output schema exists, the description is complete. It specifies input format, output content categories, market applicability, and realistic examples. There are no ambiguous aspects left for the agent to infer.

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 input schema only defines 'symbol' as a string with no description. The description explains the symbol parameter in the Args section with examples (RELIANCE, TCS, AAPL, MSFT) and contextualizes it in the Examples. This fully compensates for the 0% schema coverage and gives the agent clear guidance on what to pass.

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 clearly states the tool's function: 'Get key financial ratios and valuation metrics for a company.' It enumerates specific metric categories (valuation, profitability, growth, etc.) and provides examples for both Indian and US stocks, distinguishing it from financial statement or technical indicator 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 gives clear context on when to use the tool (when ratio/valuation analysis is needed) and notes it works for Indian and US stocks. It does not explicitly compare with alternatives like income_statement or technical_indicators, but the purpose is specific enough to imply appropriate usage.

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