Skip to main content
Glama

Costory: Your Finops MCP

update_event

Destructive

Persist changes to an existing cost-chart annotation event already saved in Costory. Use when the user asks to correct or extend a saved event annotation. This is a write (not a preview): it overwrites the event's name, date, description, tags, metadata, team scope, and/or the annotation chart in the database. It does not create a new event, does not send Slack/Teams/email, and does not archive or delete the 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 }

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": {
      "eventId": "<eventId>",
      "context": "<context>"
    },
    "name": "update_event"
  }
}

Input 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: provide this unless the event is truly org-wide 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.
contextYesA few words on why you are calling this tool, for the server developer's analytics. Describe people and things by role, such as "a customer". Do not quote the user or include names, emails, or other personal details.
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.
llm_modelNoThe model identifier you are running as, for example "claude-opus-4-8" or "gpt-5.2". Pass "unknown" if you are not certain. Recorded for the server developer's analytics.
descriptionNoNew description.
widgetEventIdNoID of the widgetEvent to update when the event has multiple annotation charts.
conversation_idNoThe conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / context / description
      Previous value: -"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""New value: +"A few words on why you are calling this tool, for the server developer's analytics. Describe people and things by role, such as \"a customer\". Do not quote the user or include names, emails, or other personal details."
    • 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 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."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: provide this unless the event is truly org-wide 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."
    • changedInput schema / required
      Previous value: -[
      -  "eventId",
      -  "context",
      -  "llm_model"
      -]New value: +[
      +  "eventId",
      +  "context"
      +]
  2. Changed4 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
      +  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
      +  "type": "string"
      +}
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.",
      +  "type": "string"
      +}
    • addedInput schema / properties / llm_model
      Added value: +{
      +  "description": "The model identifier you are running as, for example \"claude-opus-4-8\" or \"gpt-5.2\". Pass \"unknown\" if you are not certain. Recorded for the server developer's analytics.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "eventId"
      -]New value: +[
      +  "eventId",
      +  "context",
      +  "llm_model"
      +]
  3. Changed2 schema fields changed
    • removedInput schema / properties / scopeId / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / scopeId / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  4. 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."
  5. 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."
  6. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag a write with destructiveHint=true; the description earns credit by specifying exactly what destruction looks like — tags replace the full list, widget is a full wholesale replacement, metadata is merged rather than replaced, 'source' is preserved and must not be supplied. It also resolves precedence rules (top-level scopeId wins over widget.scopeId) and null-vs-omit semantics, none of which annotations convey.

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 purpose, write semantics, and exclusions before parameter detail, then closes with four targeted examples. It is dense and slightly redundant — the 'full replacement / written from scratch' point is made three times across the widget paragraph — but nearly every sentence carries decision-relevant information.

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 15-parameter tool with a nested widget object and no output schema, the description covers mutation semantics, partial-update behavior, nested chart requirements (title, queries, datePreset/from-to, chartType on every series), and conflict resolution. Nothing an agent needs in order to avoid a destructive mistake appears to be missing.

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

Parameters5/5

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

Schema coverage is 100%, so a 3 would be the floor, but the description goes well beyond field labels: omit-to-keep, scopeId tri-state (omit keeps, null clears, id replaces), widget.scopeId alone invalid, widgetEventId for multi-chart events, labels/category deprecation behavior, and the 'send the full chart from scratch, don't patch' constraint. Mapping to the list_events/list_teams sources for ids is genuinely additive.

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 — 'Persist changes to an existing cost-chart annotation event' — and immediately delimits it against siblings: 'does not create a new event', 'does not archive or delete the event'. An agent can distinguish update_event from create_event and archive_object 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.

Usage Guidelines5/5

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

States the triggering condition ('when the user asks to correct or extend a saved event annotation'), gives a required prerequisite ('Use list_events to find the event id first'), and enumerates what it does not do (no create, no Slack/Teams/email, no archive/delete). Alternatives and exclusions are explicit rather than inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources