tax_deadlines_export

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

With no annotations supplied, the description carries the full burden and does well on write safety: create_f24 is idempotent ('senza duplicarli') and dry_run defaults to TRUE, which tells the agent the default call is non-mutating. It does not state permission/token requirements, what dry_run actually returns, or whether the .ics is written when ics_path points at a directory vs. a file.

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?

Three compact sentences, front-loaded with the outcome, then the two modes, then the safety default. Slight waste in restating the schema default for dry_run, but no sentence is filler.

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 5-parameter, zero-annotation, no-output-schema mutation tool, the definition covers the two modes and the idempotency/dry-run safety profile, but leaves the meaning of revenue_estimate, the company scoping behavior, and the result of a dry run unexplained. Adequate rather than complete.

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 coverage is 60%, and the description adds meaning for three parameters (ics_path creates the .ics, create_f24 toggles F24 creation, dry_run default TRUE). It says nothing about company_id or revenue_estimate, and revenue_estimate has no schema description at all, so the effect of that input on the exported amounts remains undocumented.

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 names a specific verb (export) and resource (estimated tax deadlines: substitute tax and contributions, 30 June and 30 November) and ties each output mode to a parameter (ics_path, create_f24). It stops short of explicitly routing against close siblings such as tax_estimate or the standalone create_f24 tool, so an agent must infer the boundary.

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?

Usage is clear per mode: ics_path produces an importable .ics file with 7-day and 1-day reminders; create_f24 creates or updates planned F24s. There is no explicit when-not-to-use guidance (e.g., when to run tax_estimate first, or what happens if no revenue_estimate is supplied), which keeps it below a top mark.

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