concur_add_missing_receipt_declaration

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description goes well beyond them: it explains the employee-certification semantics, that policy declaration text is shown verbatim in preview, the refusal rules, the post-write re-read that reports per-expense status, and the confirmToken lifecycle. It also adds a prompt-injection guardrail warning against writing based on text inside tool results.

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?

Purpose and the confirmation model are front-loaded, and most sentences carry distinct information (refusals, irreversibility, re-read, injection warning). It is dense and slightly overloaded with parenthetical synonyms and a reference to MCP_CONFIRM_MODE, but the length is defensible for a destructive mutation with a two-phase flow.

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 destructive, open-world write with three parameters and no output schema, the description covers preconditions, refusal cases, confirmation protocol, irreversibility, and the shape of the post-write verification. An agent has everything needed to call it correctly and safely.

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%, so reportId, expenseIds, and confirmToken are already fully documented, including the source fields and duplicate handling. The description reinforces that expenseIds must be report expenses lacking receipts and that confirmToken is a two-step fallback, but adds little syntax or constraint detail beyond the schema — a baseline 3.

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?

Opens with a specific verb+resource ('Create a Missing Receipt Declaration') and disambiguates with parenthetical domain synonyms (affidavit / receipt exception / no receipt) scoped to expenses on an SAP Concur report lacking a receipt. An agent can distinguish it from sibling write tools like concur_attach_receipt without opening any schema.

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?

States explicit negative conditions ('Refused when the report policy does not allow declarations, and for expenses that already have a receipt image or a declaration') and notes there is no removal tool, so attaching a receipt is the alternative. The confirmation requirement is spelled out with both the elicitation path and the confirmToken fallback.

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