Side effect: retries one failed delivery only. DANGER ZONE: state the failed execution and its destination from get_report_execution, then ask the user to confirm before calling. Use after partial failure.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Organization slug. Omit to auto-detect from your account (fails if you belong to multiple orgs). | |
| executionId | Yes | Report execution id to retry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation has a side effect, is a 'DANGER ZONE', and should only be used after confirmation. This adds meaningful behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=false). It also clarifies the scope ('one failed delivery only'), which is not apparent from the schema. No contradiction with annotations.
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 extremely concise, with a clear front-loaded warning ('Side effect', 'DANGER ZONE') followed by actionable instructions. All sentences earn their place, and there is no redundancy or 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?
The description is complete for a side-effectful tool: it states the trigger condition, the required preliminary step, and the need for user confirmation. It does not describe the return value, but no output schema exists and the description does not need to. Slight gap: it does not mention what happens on success or failure, but the core context is sufficiently covered.
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 input schema already provides full descriptions for both parameters (slug and executionId), so schema description coverage is 100%. The description does not add further parameter-level detail, but the schema suffices. Baseline score of 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 clearly states the tool's function: it retries one failed delivery only. This specifies the verb (retry), the resource (failed delivery), and the scope (one only), distinguishing it from sibling tools like run_report_now or transfer_report_execution. The purpose is unambiguous.
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 provides explicit when-to-use guidance ('Use after partial failure') and a required precondition (state the failed execution and its destination from get_report_execution, then ask the user to confirm). It does not explicitly name alternatives, but the instructions are clear enough for safe invocation. Slight deduction for lacking explicit when-not-to-use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are organized by resource (alerts, dashboards, reports, events, virtual dimensions) with distinct actions, so most are clearly separable. The main confusion risks are the three report-delivery side-effect tools (run_report_now, retry_report_execution, transfer_report_execution) and the generic get that spans five resource types, though detailed descriptions mitigate these.
The dominant verb_noun pattern (create_*, list_*, update_*, preview_*, get_*) is consistent and predictable across the set. Deviations like bare verbs query/search/get and the noun-only virtual_dimension_overlap_matrix are readable but break the otherwise uniform convention.
44 tools is heavy and exceeds the comfortable range, but the server covers a genuinely broad FinOps platform spanning querying, dashboards, reports, alerts, events, virtual dimensions, docs, skills, and suggestions. Each tool has a distinct job, though the sheer count makes agent navigation harder.
Core workflows are well covered: query → dashboard/report/alert/event, plus a full virtual-dimension draft lifecycle. Notable gaps include alerts being create-only with no update/delete, no deletes for dashboards/events/published virtual dimensions, and budget management limited to query/get with no create/update.