Skip to main content
Glama

Costory: Your Finops MCP

update_dashboard

Update an existing dashboard's shared dashboardContext, widgets, tags, and/or team. Call get_skill with skillId: "dashboards" first — see skill for inheritance rules. Look up the dashboard id via search. Pass dashboardContext as a partial patch to edit the global filter (conditionsCel), period, groupBy, metricId, currency, or scopeId without recreating the dashboard — omit fields you want to keep; empty conditionsCel clears the filter. The legacy context alias is temporarily accepted but deprecated; never send both. Pass operations to add/replace/remove widgets. Pass tags to replace the full tag list (existing IDs from list_tags and/or { name, color? } for new tags; [] clears). Pass teamId (from list_teams) to assign a team, or teamId: null to detach. At least one of dashboardContext, operations, tags, or teamId is required. Response includes inheritedContext so new chart widgets can omit fields matching the dashboard. Chart widgets inherit metricId, groupBy, currency, period, and conditionsCel by default — only pass per-widget overrides. Text widgets: { type: "text", title, textContent }. Do not repeat from/to, datePreset, or groupBy when they match the dashboard context. Set extendDashboardConditions: false only when a chart widget must ignore the dashboard filter. Optional grid fields on add: x/y/w/h (from get). Returns a URL — you MUST include it in your response. EXAMPLES: see skill dashboards Workflow B (widgets) and Workflow D (context / global filter). • "Tag the AWS dashboard as infrastructure" (after list_tags returned tag id "tag_abc") → { dashboardId: "clx9aws", tags: ["tag_abc"] } • "Move the K8s dashboard to the infra team" (after list_teams returned id "team_xyz") → { dashboardId: "clx9k8s", teamId: "team_xyz" } • "Remove the dashboard from its team" → { dashboardId: "clx9k8s", teamId: null }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugNoOrganization slug. Omit to auto-detect from your account (fails if you belong to multiple orgs).
tagsNoComplete tag list to set on the dashboard (replaces current tags). Pass existing tag IDs from `list_tags`, and/or new tag objects `{ name, color? }` (created in the org if missing; color defaults to #6366F1). Pass [] to clear all tags. Use `get` to read current tags before removing one. Optional; omit to leave tags unchanged.
teamIdNoTeam to assign the dashboard to (from `list_teams`), or null to detach from any team. Optional; omit to leave team unchanged.
contextNoDeprecated alias for `dashboardContext`; supported temporarily for backward compatibility. Do not send both fields.
operationsNoList of operations to apply atomically. Each op is "add" (append a new widget), "replace" (overwrite an existing widget in place), or "remove" (delete a widget). For add/replace, widgets inherit dashboard context by default; only pass per-widget overrides. Optional when `dashboardContext`, `tags`, or `teamId` is provided. Example: [{"op":"add","widget":{"title":"Monthly cost","queries":[{"type":"cost","name":"a","chartType":"BAR"}],"aggBy":"Month"}}].
dashboardIdYesID of the DashboardV2 to mutate. Get it from `search` (V2 surface).
dashboardContextNoPartial patch for dashboard-level shared context (global filter, period, groupBy, metricId, currency, scopeId). Omitted fields keep their current values. Set `conditionsCel` to update/clear the global filter (empty string clears it). When changing period mode, null the unused side (`datePreset` vs `startDate`/`endDate`). Can be used alone or together with `operations`, `tags`, or `teamId`.

TDQS

A5/5.0
Behavior5/5

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

Annotations carry little here, so the description carries the burden, and it delivers: partial-patch semantics (omitted fields keep values), explicit clear behavior for conditionsCel, tags [], and teamId null, the deprecated context alias with the warning never to send both, and the required at least one of dashboardContext/operations/tags/teamId. It also discloses the response contract by saying the response includes inheritedContext and returns a URL the agent MUST include.

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

Conciseness5/5

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

The description is long, but every sentence carries a distinct rule or prerequisite, and the structure front-loads the core purpose before layering details. The embedded examples are high-leverage: three small payloads communicate the common usage patterns more efficiently than additional prose.

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 tool with seven params and deeply nested widget schemas, the description covers prerequisites, conditional requirements, inheritance rules, partial-update semantics, clearing behavior, and the return contract without needing to restate the schema. It also routes the agent to get_skill for workflow examples, closing the gap left by having no output schema.

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%, but the description adds substantial meaning beyond the schema: dashboardContext is a partial patch, tags fully replace the list, teamId null detaches, operations are add/replace/remove, and chart widgets inherit dashboard context so agents should pass only overrides. This guidance directly prevents common misinvocations like repeating inherited fields or sending both context and dashboardContext.

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?

The opening sentence names the exact verb (update), the resource (existing dashboard), and the affected surfaces (dashboardContext, widgets, tags, team), clearly distinguishing it from create_dashboard and get. The phrase 'without recreating the dashboard' reinforces that this tool modifies an existing dashboard rather than building a new one.

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?

The description gives concrete preconditions: call get_skill with skillId 'dashboards' first, look up dashboardId via search, source tags from list_tags, teams from list_teams, and grid positions from get. It also signals the alternative to creation via 'without recreating the dashboard' and includes representative examples that show exactly when to use the tool and how to construct payloads.

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.

TDQS

A4.1/5.0
Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness3/5

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.

Resources