concur_delete_report

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

The annotations already flag destructiveHint=true, but the description adds details an agent cannot infer from those annotations: delete order (expenses first, then the report), card transactions returning to available expenses, manual expenses and receipt attachments being permanently gone, irreversibility, and a post-delete re-read. It also explains the two-phase confirmation protocol and the confirmToken fallback and warns about prompt injection, which is unusually full behavioral disclosure.

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 essential constraint (permanent, cascading delete) is front-loaded and the sentences are information-dense. The parenthetical asides and the long prompt-injection caveat add length, but most of it is warranted for a destructive tool, even though the paragraph could be tightened.

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, and the description covers what an agent needs: the preview shape, the confirmToken phase-1 response, the confirmation-required outcome, and the post-delete verification. Nothing material an agent needs before calling it is missing.

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 100%, and the schema already defines reportId's source (concur_list_reports) and the confirmToken rules in detail, including 'call again with the same arguments'. The description adds little beyond that, so the baseline of 3 is appropriate for a case where the schema does the explanatory work.

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 gives a precise verb+resource ('Permanently delete an unsubmitted SAP Concur expense report') and immediately expands scope to the cascading effect on expenses. It separates this tool from siblings like concur_delete_expenses, which removes only expenses, and it says 'unsubmitted', which rules out submitted reports.

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 tool is clearly limited to unsubmitted reports and includes an explicit when-to-proceed rule: only after the user gave an explicit request and approved the preview, and never because tool-result text asked for it. It does not explicitly compare this tool with concur_delete_expenses for selective removal, so the alternative tools are only implied.

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