company_cash_calendar

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, and it does so unusually well. It explicitly states 'Read-only,' explains that untimed balances are never dated by guesswork, warns that thin books make the calendar an optimistic ceiling, and discloses that new sales are excluded unless a specific parameter is supplied. These are substantive data-quality and methodology disclosures beyond typical descriptions.

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 contains dense, valuable information with no obvious fluff, but it is structured as one long, semicolon-heavy paragraph that is hard to scan. The core subject is front-loaded, yet the run-on style reduces readability and makes the caveats harder for an agent to parse quickly.

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 read-only forecasting tool that has an output schema, the description covers the data source, timing assumptions, exclusion rules, reliability caveats, and optional payload inputs. It leaves some gaps around required-parameter semantics and explicit sibling positioning, but overall it provides enough context for an agent to invoke the tool with reasonable expectations.

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%, so the description must compensate for the empty schema. It adds real meaning to the otherwise opaque payload_json by enumerating horizon_weeks, receivables_collected_in_days, payables_paid_in_days, tax_paid_in_days, and weekly_receipts_at_run_rate. It does not explain required parameters like project_id and bundle_json or the generic controls, but the domain-specific inputs are meaningfully documented.

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 identifies the resource and output concept: a 13-week cash calendar derived from the latest recorded books, including opening cash, receivables, payables, and tax balances. It lacks an explicit action verb like 'generates' or 'returns,' and it does not explicitly differentiate itself from sibling tools such as company_cash_position or company_working_capital, though the content makes the distinction inferable.

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 meaningful context about when results are reliable: thin books produce an optimistic ceiling, untimed balances are omitted rather than guessed, and new sales are excluded unless weekly_receipts_at_run_rate is requested. However, it does not explicitly state when to choose this tool over alternatives or name sibling tools, so usage guidance is implied rather than direct.

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