Costory: Your Finops MCP

get_alert_message_execution_widget

Read-only

Fetch one widget from an alert message run (get_alert_message_execution). GRAPH_SNAPSHOT supports view "series" (compacted chart series); every type supports view "detail" (the full frozen parameters + result). Optional returnImage "link" or "base64" returns the PNG already stored on a GRAPH_SNAPSHOT (no re-render). Omit for the usual view. "base64" also attaches the PNG bytes — large, only if the host cannot fetch the URL. Other widget types have no stored image. No DIGEST on alerts. Read-only. EXAMPLE: { alertId: "clx…", executionId: "clx…", widgetId: "clx…", view: "series", returnImage: "base64" }

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "alertId": "<alertId>",
      "executionId": "<executionId>",
      "widgetId": "<widgetId>"
    },
    "name": "get_alert_message_execution_widget"
  }
}

Input Schema

Name	Required	Description
`slug`	No	Organization slug. Omit to auto-detect from your account (fails if you belong to multiple orgs).
`view`	No	`series` (GRAPH_SNAPSHOT only) returns the compacted chart series; `detail` (default) returns the full frozen widget — parameters and result. No DIGEST on alerts.
`alertId`	Yes	Cost alert id.
`widgetId`	Yes	Widget id within that execution.
`executionId`	Yes	Alert message execution id.
`returnImage`	No	Omit (default) for the usual view only. "link": same view plus imageUrl of the PNG already stored on a GRAPH_SNAPSHOT (no re-render). "base64": same plus an inline PNG block fetched from that URL — large payload, only if the host cannot fetch the URL. Widgets with no stored image keep the view and append JSON { "image": "unsupported", "message": "..." }.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / returnImage

Added value: +{
+  "description": "Omit (default) for the usual view only. \"link\": same view plus imageUrl of the PNG already stored on a GRAPH_SNAPSHOT (no re-render). \"base64\": same plus an inline PNG block fetched from that URL — large payload, only if the host cannot fetch the URL. Widgets with no stored image keep the view and append JSON { \"image\": \"unsupported\", \"message\": \"...\" }.",
+  "enum": [
+    "link",
+    "base64"
+  ],
+  "type": "string"
+}

AddedOct 28, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds real behavioral context beyond the readOnly/non-destructive annotations: images are returned from storage with no re-render, other widget types have no stored image, DIGEST is unsupported on alerts, and unsupported image requests append a JSON marker rather than erroring. Missing only details like size limits or failure modes when the widget id is unknown.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and scope, then layered view, image, and caveat details, closing with a concrete example. Slightly dense and repetitive with the schema's enum descriptions, but nearly every sentence carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only fetch with 6 parameters and no output schema, the description covers the important unknowns: what each view returns, what the image option attaches, and the alert-specific limitations. A brief note on the returned structure for the default 'detail' view would close the gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the enum semantics of view and returnImage are already documented; the description largely paraphrases them. It does add the operational note that base64 payloads are large and only warranted when the host cannot fetch the URL, which is minor incremental value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Fetch one widget from an alert message run', and names the parent operation (get_alert_message_execution) so the agent knows what entity it scopes into. The 'alert message' qualifier distinguishes it from get_report_execution_widget / get_report_execution without needing to open either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit selection rules between the two views ('series' only for GRAPH_SNAPSHOT, 'detail' generally) and between returnImage modes, including the exclusion 'only if the host cannot fetch the URL'. It lacks an explicit statement of when to call this versus get_alert_message_execution (fetch the whole run) or get_dashboard_widget_image, which is the main remaining gap.

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

All Costory: Your Finops MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?