freshbooks_decline_estimate

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the tool always fails, never sends a request, exists only to return a reason, and explains the underlying API limitations. This is model transparency for a deliberately non-functional tool.

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 front-loaded with the most critical information—'NOT SUPPORTED' and 'always fails'—and every sentence contributes. The middle sentence is somewhat detailed and lengthy, but it substantiates why the tool cannot work, making the verbosity justified.

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 that always fails and has no output schema, the description is complete: it states behavior, the API reason, the purpose, and the intended action. An agent understands exactly what will happen and what the tool is for. Missing return-format details are irrelevant because the tool never succeeds.

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 single parameter `id` is fully documented in the schema as 'Estimate id' with 100% coverage, so the description does not need to add param details. It does imply the id is ignored because no request is ever sent, but this is behavioral rather than semantic parameter documentation. Baseline 3 is appropriate.

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 is explicit that this tool is NOT SUPPORTED, always fails, and never sends a request. It clearly explains the tool's actual purpose—returning the reason and alternatives rather than performing a decline—and distinguishes it from a real operation by citing the missing declined state and action_deny counterpart.

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 makes it clear the tool cannot perform a decline and says to 'call it to get the alternatives,' which implies usage but does not explicitly name the alternative tools or state when to prefer them. It gives context for when it might be invoked but lacks explicit when-to-use vs when-not-to-use guidance.

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