get_financial_ratios

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not disclose whether this is a read-only operation, that SEC rate limits apply, why a contact email is needed, or any constraints on the calculation. The description adds minimal behavioral context beyond the basic function.

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 that directly states the tool's purpose. It is concise with no wasted words, making it easy to parse and understand.

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?

Despite having an output schema (which covers return values), the description is incomplete for a tool with two required parameters. It does not mention the need for a SEC-compliant contact email, how the company is identified, or any caveats about data availability. The tool is a financial calculation utility, and the description lacks essential context for correct usage.

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?

Schema description coverage is 0%, and the tool description provides zero additional meaning for the parameters 'cik' and 'contact_email'. It does not explain what a CIK is, the format expected, or the purpose of the contact email. The schema only gives field titles, which are not elaborated by the description, so the description fails to compensate for the lack of coverage.

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 a specific action ('Calculate') and a specific resource ('profitability, liquidity, leverage, and efficiency ratios') sourced from SEC data. It is not a tautology and the specific ratio categories help distinguish it from sibling tools like get_company_financials, though it does not explicitly name alternatives.

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. It does not mention prerequisites, such as the requirement for a contact email or that the user should have a specific CIK. The description merely states what it does, leaving usage context entirely implicit.

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