Skip to main content
Glama

Costory: Your Finops MCP

by io.costory.app-api
OverviewDiscussionsAdmin

update_event

Update an existing event. Use list_events to find the event id first. All fields except eventId are optional — omit a field to keep the stored value. Metadata is merged into existing values; source is preserved on the event column and should not be supplied. Tags replace the full tag list. Name, date, description, tags, metadata, and scopeId need no widget.

scopeId (same id as list_teams) sets the event scope and leaves the chart unchanged. Omit it to keep the saved scope. null clears it. An id replaces it. If both scopeId and widget.scopeId are sent, scopeId wins.

widget replaces the annotation chart wholesale, or creates one if none exists. If you send widget, send the full chart on the first call, written from scratch exactly as for query: title, queries, and datePreset or from/to. Set chartType on every series (BAR, LINE, AREA, WATERFALL, or TABLE). Omitting it stores LINE and replaces the previous chart type. widget.scopeId alone is invalid. list_events returns chart id and title only, not the stored queries, so do not patch or echo the current chart. Omit widget to leave the chart unchanged. A full widget without widget.scopeId keeps the saved event scope unless top-level scopeId is set. widget.scopeId: null clears the event scope when top-level scopeId is omitted. If the event has multiple charts, pass widgetEventId. EXAMPLE: "Add a PR link to yesterday's deploy event" → { eventId: "clx9abc", metadata: { link: "https://github.com/acme/app/pull/99" } } EXAMPLE: "Fix the description on the migration event" → { eventId: "clx9abc", description: "Migrated prod cluster; temporary 2-day cost spike from dual-running nodes." } EXAMPLE: "Scope the migration event to the platform team" → { eventId: "clx9abc", scopeId: "" } EXAMPLE: "Clear the event scope" → { eventId: "clx9abc", scopeId: null }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoNew event date (YYYY-MM-DD).
nameNoNew event name.
slugNoOrganization slug. Omit to auto-detect from your account (fails if you belong to multiple orgs).
tagsNoReplace all tags on the event.
labelsNoDeprecated alias for tags. Ignored when tags is sent.
widgetNoAnnotation chart for the event. Same shape as the `query` tool (`queries`, `datePreset` or `from`/`to`, `aggBy`, `compare`, `limit`, `scopeId`) plus `title` and optional `description`. Providing a widget creates a visual annotation so the team can see which cost movement the event documents. On create: STRONGLY RECOMMENDED; omit only for truly org-wide events with no cost chart. On update: omit to leave the chart unchanged. If sent, widget is a full replacement (title, queries, and datePreset or from/to required; scopeId alone is invalid). Pass widgetEventId when the event has multiple charts.
eventIdYesEvent ID from list_events or create_event.
scopeIdNoEvent scope id from list_teams. Omit to keep the saved scope. null clears it. Does not change the chart. If widget.scopeId is also sent, this field wins.
categoryNoDeprecated. If sent, merged into tags then discarded.
metadataNoMetadata fields to merge into existing metadata (e.g. link, owner). Existing source is preserved.
descriptionNoNew description.
widgetEventIdNoID of the widgetEvent to update when the event has multiple annotation charts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / scopeId
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Event scope id from list_teams. Omit to keep the saved scope. null clears it. Does not change the chart. If widget.scopeId is also sent, this field wins."
+}
    • changedInput schema / properties / widget / description
      Previous value: -"Annotation chart for the event. Same shape as the `query` tool (`queries`, `datePreset` or `from`/`to`, `aggBy`, `compare`, `limit`, `scopeId`) plus `title` and optional `description`. Providing a widget creates a visual annotation so the team can see which cost movement the event documents. On create: STRONGLY RECOMMENDED; omit only for truly org-wide events with no cost chart. On update: omit to leave existing annotation charts unchanged; pass widgetEventId when the event has multiple charts."New value: +"Annotation chart for the event. Same shape as the `query` tool (`queries`, `datePreset` or `from`/`to`, `aggBy`, `compare`, `limit`, `scopeId`) plus `title` and optional `description`. Providing a widget creates a visual annotation so the team can see which cost movement the event documents. On create: STRONGLY RECOMMENDED; omit only for truly org-wide events with no cost chart. On update: omit to leave the chart unchanged. If sent, widget is a full replacement (title, queries, and datePreset or from/to required; scopeId alone is invalid). Pass widgetEventId when the event has multiple charts."
  2. Changed4 schema fields changed
    • changedInput schema / properties / category / description
      Previous value: -"New category."New value: +"Deprecated. If sent, merged into tags then discarded."
    • removedInput schema / properties / category / enum
      Removed value: -[
-  "BUSINESS",
-  "TECHNICAL",
-  "PROVIDER"
-]
    • addedInput schema / properties / labels
      Added value: +{
+  "description": "Deprecated alias for tags. Ignored when tags is sent.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / tags / description
      Previous value: -"Replace all labels on the event."New value: +"Replace all tags on the event."
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare the mutation safety profile (readOnlyHint=false, destructiveHint=false), so the description carries the real behavioral burden and does so: metadata merges while tags replace wholesale, `source` is preserved and must not be supplied, widget replaces the chart entirely rather than patching, and scopeId/widget.scopeId precedence and null semantics are spelled out. It does not mention permissions or error behavior, which keeps it short of 5.

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 verb and field-omission rule, then the two tricky sub-objects, then concrete examples. It is long, but the length is earned by a 12-parameter tool with nested widget semantics. The widget paragraph is dense and partly restates schema rules, which is the only drag on tightness.

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

Completeness5/5

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

For a complex mutation with nested objects and no output schema, the description covers prerequisites, partial-update merge-vs-replace semantics, the deprecated fields (labels, category), and the multi-chart addressing case. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema: scopeId wins over widget.scopeId, null clears vs omit keeps, 'widget.scopeId alone is invalid', chartType must be set per series, and slug auto-detection is easy to miss. Much of this is corroborated in the schema descriptions, so it is additive rather than unique, landing at 4.

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?

States a specific verb and resource ('Update an existing event') and immediately routes the agent to list_events to obtain the required eventId, distinguishing it from create_event in the sibling list. An agent can tell what it does without opening the schema.

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

Usage Guidelines5/5

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

Explicitly covers when to use it, the required prerequisite (list_events first), optional-field omission semantics, when to send widget vs omit it, and when widgetEventId is needed for multi-chart events. Four worked examples map natural-language requests to argument shapes, covering metadata merge, description edit, scope set, and scope clear.

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 toolsInspect
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