getCashFlowStatementTTM

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. Beyond that, the description adds nothing: it does not explain what TTM means here (rolling four quarters vs. most recent fiscal year), what period or currency the figures are in, or whether the response is a single statement or a time series. For a financial-data read tool this is a meaningful gap.

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?

Two sentences, no bloat, and reasonably front-loaded. However, the wording is generic marketing copy ('Gain insights into...') that spends its space on the category rather than on the one thing that differentiates this endpoint, which is the TTM basis.

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?

There is no output schema, so the description should carry the burden of explaining what comes back, and it does not. It also leaves the TTM concept unexplained, which is the single most important thing an agent needs to know to select this tool correctly.

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 100%, with symbol ('Stock symbol') and limit (default 100, max 1000) both documented in the schema, so the baseline of 3 applies. The description adds no extra meaning, such as whether limit applies to periods returned or whether symbol accepts only US tickers.

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 describes the general category of cash flow data ('Analyze cash generated and used from operations, investments, and financing activities') but never states the defining characteristic of this tool: that it returns trailing-twelve-month figures. It reads like boilerplate for the whole Cash Flow Statements API, so an agent cannot tell it apart from siblings such as getCashFlowStatement, getCashFlowStatementGrowth, getCashFlowStatementAsReported, or getCashFlowStatementsBulk.

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 only usage framing is the vague goal of evaluating 'financial health and sustainability'. There is no guidance on when to prefer TTM over the annual/quarterly getCashFlowStatement, over the growth variant, or over the bulk endpoint, despite a very crowded sibling set of near-identical names.

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