financials_market_cap

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get market capitalization' without indicating whether it returns a single current value or a historical time series, despite the presence of from/to/frame parameters. It also does not mention output format, pagination, or any special behaviors. This is a significant gap for a tool that clearly supports date ranges.

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 a single, front-loaded sentence with no wasted words. It is concise and immediately conveys the core purpose. However, it could be slightly more informative without losing conciseness, such as mentioning that it supports historical ranges, which would add value. Still, it is appropriately short.

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 tool with four parameters including optional date range and resampling, the description is too sparse. Since there is no output schema to clarify the return format, the description should at least hint that the tool can return historical time series given the from/to/frame parameters. Without this, an agent may not know when to supply those parameters or what to expect in response, making the description incomplete for effective invocation.

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 provides 100% coverage for all four parameters, each with a clear description ('End date (YYYY-MM-DD)', 'Start date (YYYY-MM-DD)', 'Resampling frequency: daily, weekly, monthly', 'Stock ticker'). The description adds no additional parameter guidance, so the baseline of 3 applies because the schema already documents the parameters sufficiently.

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 ('Get'), a specific resource ('market capitalization'), and a specific target ('a ticker'). This clearly distinguishes it from sibling financials_* tools like financials_revenue or financials_pe, which cover different metrics. There is no ambiguity about what it does.

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?

No guidance is provided on when to use this tool versus alternatives. While the purpose is clear, the description does not mention when to prefer market cap over other financial metrics, nor does it note any exclusions or prerequisites (e.g., needing historical data). The usage context is entirely implied by the name, not explicitly stated.

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