Connection check
verified live · 28h ago
plutus-cost-data
Query cloud, AI and SaaS spend across 25+ providers: costs, budgets, anomalies, unit economics.
Tools
29
GitHub stars
—
Installs / wk
—
Licence
—
Transport
streamable-http
Last checked
28h ago
Tools & capabilities
29 toolsRead from the running server on 28h ago.
get_cost_entries
read-only
endDatestartDate
Fetch raw per-service cost entries for this account over a date range (unaggregated). Prefer query_costs for time-bucketed/aggregated spend — this is for inspecting individual rows… Fetch raw per-service cost entries for this account over a date range (unaggregated). Prefer query_costs for time-bucketed/aggregated spend — this is for inspecting individual rows. Each row's `cost` is in USD (see the response's top-level `currency` field), like every other figure this server returns. A row also carries `native_cost`/`native_currency` — what the provider actually billed, for reconciling against their invoice. Those are the one exception to the USD rule here: never sum or compare `native_cost` across rows, and never quote it without naming the row's `native_currency`. Unlike query_costs, there is no cost_metric parameter here — `cost` is always billed cost, never amortized.
get_dashboard
read-only
dashboard_id*
Fetch one org-shared dashboard's full layout — its placed widgets, custom metrics and custom charts, and their grid positions. A `widgets` entry references a preset catalog_id (see… Fetch one org-shared dashboard's full layout — its placed widgets, custom metrics and custom charts, and their grid positions. A `widgets` entry references a preset catalog_id (see list_dashboard_widget_catalog); `customMetrics`/`customCharts` carry their own full config inline. Call this before set_dashboard_widgets if you want to keep some of what's already there rather than replacing the whole set — that tool always replaces everything.
list_alert_channels
read-only
List this account's alert notification channels (Slack/Teams/webhook/email) — need a channel's id to call create_alert_subscription. Never returns the channel's credentials/URL, on… List this account's alert notification channels (Slack/Teams/webhook/email) — need a channel's id to call create_alert_subscription. Never returns the channel's credentials/URL, only its id/type/name/enabled state.
list_alert_deliveries
read-only
limit
List recent alert delivery history for this account (did an alert actually fire, and did it send successfully) — the same data behind the Alerts page's delivery heatmap. Does not i… List recent alert delivery history for this account (did an alert actually fire, and did it send successfully) — the same data behind the Alerts page's delivery heatmap. Does not include the delivery error text. Mirrors GET /api/accounts/:accountId/alert-deliveries.
list_alert_subscriptions
read-only
List which alert channels are subscribed to which trigger (a specific budget's spend_threshold, or account-wide event_overage/cost_anomaly). Mirrors GET /api/accounts/:accountId/al… List which alert channels are subscribed to which trigger (a specific budget's spend_threshold, or account-wide event_overage/cost_anomaly). Mirrors GET /api/accounts/:accountId/alert-subscriptions.
list_anomalies
read-only
days
List detected cost anomalies for this account over a trailing lookback window — the real output of Plutus's nightly anomaly detector (severity, baseline vs. current spend, and what… List detected cost anomalies for this account over a trailing lookback window — the real output of Plutus's nightly anomaly detector (severity, baseline vs. current spend, and what drove a tag-level spike), not something recomputed here from raw spend. Prefer this over eyeballing query_costs for "did anything spike" — the detector already accounts for day-of-week baselines and an absolute-dollar noise floor that a naive comparison would miss or over-trigger on. Capped at 200 rows, most recent first; `days` (default 30, max 90) bounds the lookback. `kind` is "service" or "tag". `current_cents`/`baseline_cents`/`delta_cents` are the USD base. `suppressed: true` means a human has marked this exact signature (provider+service, or tag_key+tag_value) as expected — mention it but do not lead with it as a live problem. `driven_by` is null when driver attribution was not measured for this anomaly (a service anomaly, or a grain with no service) and `[]` when it WAS measured and found no dominant driver — those mean different things. `correlated_events` is the service-anomaly counterpart: deploy/incident/release activity that was unusual (above the account's own baseline rate) in the 2-day window ending on the spike day, ranked by share of that excess. Same null-vs-`[]` distinction — null is "not measured" (a tag anomaly, or a row recorded before this shipped), `[]` is "measured and nothing was unusual". It is account-scoped and temporal: it does NOT claim the event caused this particular service's spend to rise, so report it as activity that lines up, never as a cause. `notified: false` means this anomaly was recorded but withheld from alerting because its tag_key was already at the per-run notify cap. Mirrors GET /api/accounts/:accountId/anomalies.
list_anomaly_suppressions
read-only
List this account's active anomaly suppressions — signatures (a provider+service pair, or a tag_key+tag_value) a human has marked as expected, so the detector stops surfacing them.… List this account's active anomaly suppressions — signatures (a provider+service pair, or a tag_key+tag_value) a human has marked as expected, so the detector stops surfacing them. Each has an `expires_at` (null = indefinite). Mirrors GET /api/accounts/:accountId/anomaly-suppressions. Creating/deleting a suppression is not available over MCP.
list_budgets
read-only
List this account's spend budgets with their current-cycle status (spend so far, projected total, ok/warning/exceeded state, and forecast state). Mirrors GET /api/accounts/:account… List this account's spend budgets with their current-cycle status (spend so far, projected total, ok/warning/exceeded state, and forecast state). Mirrors GET /api/accounts/:accountId/budgets. A budget carries its own `currency` (budgets are NOT converted to the USD base the cost tools return), and `amount_cents` is denominated in it; `spend_cents`/`projected_cents` are in `status_currency`, the budget's currency as of the rollup that wrote them. Never quote any of these figures as dollars without checking those two fields.
list_commitment_utilization
read-only
List Reservation (RI) and Savings Plan utilization/coverage snapshots for this account — sourced from AWS Cost Explorer's own GetReservationUtilization/GetSavingsPlansUtilization A… List Reservation (RI) and Savings Plan utilization/coverage snapshots for this account — sourced from AWS Cost Explorer's own GetReservationUtilization/GetSavingsPlansUtilization APIs, one snapshot per commitment type per month. Shows how much of a purchased commitment is actually being used and its net savings vs on-demand. Mirrors GET /api/accounts/:accountId/commitment-utilization.
list_cost_sources
read-only
List the cost-source providers (AWS, GCP, Anthropic, etc.) enabled for this account. Each row's cost_basis says where that provider's money figures come from: "invoiced" = amounts… List the cost-source providers (AWS, GCP, Anthropic, etc.) enabled for this account. Each row's cost_basis says where that provider's money figures come from: "invoiced" = amounts the provider actually charged; "estimated_from_provider_rates" = an estimate built from the provider's own published rates, because it exposes no historical billing API; "estimated_from_static_rates" = an estimate built from a list-rate card Plutus maintains, which will not reflect rates the customer negotiated. Qualify any total that includes an estimated source rather than reporting it as billed spend.
list_cost_source_tag_keys
read-only
cost_source_id
List distinct provider-native tag/label keys actually present in this account's cost data (AWS Cost Allocation Tags, GCP/Hetzner labels, Azure tags) — useful for discovering what a… List distinct provider-native tag/label keys actually present in this account's cost data (AWS Cost Allocation Tags, GCP/Hetzner labels, Azure tags) — useful for discovering what a "tags.<key>" cost-tag-rule match could reference before creating one. Only ever populated on grain='service' rows. Omit cost_source_id to search across every enabled provider.
list_cost_source_tag_values
read-only
tag_name*cost_source_id
List distinct values seen for one provider-native tag/label key (see list_cost_source_tag_keys) in this account's cost data. List distinct values seen for one provider-native tag/label key (see list_cost_source_tag_keys) in this account's cost data.
list_cost_tag_rules
read-only
tag_key*
List the actual match rules for one of this account's cost-allocation tag_keys (see list_cost_tags) — which dimension values (or provider-native tag) map to which tag_value, and in… List the actual match rules for one of this account's cost-allocation tag_keys (see list_cost_tags) — which dimension values (or provider-native tag) map to which tag_value, and in what priority order. Rules are evaluated in ascending priority and the first match wins; spend matching no rule falls to "Untagged". Mirrors GET /api/accounts/:accountId/cost-tags/:tagKey/rules. IMPORTANT — a rule is NOT always a single assignment: when its `splits` field is non-null it is an array of {tag_value, weight} with weights summing to 1, and matched spend is divided across those tag_values by weight rather than going wholly to the rule's own tag_value. On a split rule, `tag_value` is only the rule's display label (e.g. "Shared EKS cluster") and no spend is attributed to it. Do not describe a rule with splits as assigning its spend to one team. Note also that some spend may be reallocated after these rules run — see list_cost_tags' redistribute_bucket.
list_cost_tags
read-only
List the virtual cost-allocation tag_keys defined for this account (e.g. "team", "product"), each with the cost_entries grain it's locked to and how many rules map dimension values… List the virtual cost-allocation tag_keys defined for this account (e.g. "team", "product"), each with the cost_entries grain it's locked to and how many rules map dimension values to a tag_value. Use a tag_key with query_costs (breakdown_by: "tag") to see spend broken down by it. redistribute_bucket, when non-null, names a bucket (often "Untagged") whose spend is dissolved into the other tag_values in proportion to their own attributed spend in the same period — so that bucket will not appear in a query_costs breakdown for this tag_key, and the other values include a proportional share of it. It reappears only in periods where there was no other spend to redistribute against.
list_dashboards
read-only
List this account's org-shared dashboards — visible to every account member. Does not include any member's PERSONAL dashboard: those live in one specific signed-in user's own brows… List this account's org-shared dashboards — visible to every account member. Does not include any member's PERSONAL dashboard: those live in one specific signed-in user's own browser session and have no id an account-level MCP key can address. Use a returned `id` with get_dashboard, set_dashboard_widgets or delete_dashboard.
list_dashboard_widget_catalog
read-only
List the built-in ("preset") dashboard widgets available to place with create_dashboard/set_dashboard_widgets — small `kpi` stat tiles and larger `widget` data cards, each with the… List the built-in ("preset") dashboard widgets available to place with create_dashboard/set_dashboard_widgets — small `kpi` stat tiles and larger `widget` data cards, each with the id (`catalog_id`) a {"kind": "preset", "catalog_id": "..."} widget spec references. There is no preset chart: to put a trend chart on a dashboard, build one inline with a {"kind": "custom_chart", ...} spec instead of a catalog_id — see create_dashboard's description for that shape. The response also carries `grid_cols` (the canvas width every widget's x/w is measured against) and `size_bounds`, the min/max `w`/`h` each widget TYPE (`kpi`/`chart`/`widget` — not each individual catalog_id) accepts when a spec overrides its default size — use these before calling create_dashboard/set_dashboard_widgets with an explicit `w`/`h`.
list_data_health
read-only
List sync health for every cost/event/usage connection this account has — last synced time, next scheduled sync, the outcome of its most recent run, and `is_overdue` (no successful… List sync health for every cost/event/usage connection this account has — last synced time, next scheduled sync, the outcome of its most recent run, and `is_overdue` (no successful sync within twice the connection's own effective sync interval). `status` is only ever set on a successful sync and is never flipped back on failure, so `is_overdue` — not `status` — is the real signal that a connection has gone stale. Check this before asserting that recent cost or usage data is complete, especially right before calling query_costs or query_usage for a very recent date range. Mirrors GET /api/accounts/:accountId/data-health.
list_dimensions
read-only
end_datedimension*start_datecost_source_id*
List the distinct values seen for a given dimension (service, region, linked_account, usage_type, or operation) for one provider — useful for discovering filter values before calli… List the distinct values seen for a given dimension (service, region, linked_account, usage_type, or operation) for one provider — useful for discovering filter values before calling query_costs.
list_event_facets
read-only
attr*end_datesource_idstart_date
List the distinct values seen for a faceted event metadata field over a date range — currently just "repo" (every GitHub repo with at least one event), the same facet the Event Exp… List the distinct values seen for a faceted event metadata field over a date range — currently just "repo" (every GitHub repo with at least one event), the same facet the Event Explorer's repo picker uses. Useful for discovering query_events' meta_repo filter values before calling it. Mirrors GET /api/events/facets.
list_savings_recommendations
read-only
List active cost-reduction recommendations for this account — sourced from each provider's own already-computed engine (AWS Cost Explorer, Azure Advisor, GCP Recommender), not some… List active cost-reduction recommendations for this account — sourced from each provider's own already-computed engine (AWS Cost Explorer, Azure Advisor, GCP Recommender), not something Plutus computes itself. `type` is one of: `terminate` (an idle resource to shut down), `modify` (an overprovisioned one to downsize), `commitment_savings_plan` or `commitment_reservation` (a commitment worth *buying* — an AWS Savings Plan / Reserved Instance, Azure reservation or savings plan, or GCP committed use discount). Commitment rows have no `current_instance_type`/`recommended_instance_type` — they are a purchase, not an instance swap; their term, payment option, lookback window and hourly commitment are in `detail`. Only one term/payment/lookback variant per commitment is surfaced (AWS: 30-day lookback, 1-year, no upfront — Cost Explorer's own console default), so do not report these as the only commitment options available. Mirrors GET /api/accounts/:accountId/savings-recommendations. Each recommendation carries the provider's own figure in its own `currency`; the total is in USD (stated in the response's `currency` field), since providers may bill in different ones.
list_scheduled_reports
read-only
List this account's scheduled cost digests — cadence, scope (whole account, one cost source, or one cost-allocation tag value), destination alert channel, and when the next one is… List this account's scheduled cost digests — cadence, scope (whole account, one cost source, or one cost-allocation tag value), destination alert channel, and when the next one is due. `next_period_label` names the concrete date range the next digest will cover. Mirrors GET /api/accounts/:accountId/scheduled-reports. Creating/editing a scheduled report is not available over MCP.
list_tag_recommendations
read-only
List suggested cost-allocation tag rules this account doesn't have yet — high-spend values currently falling through to "Untagged" for an existing tag_key, or a provider-native tag… List suggested cost-allocation tag rules this account doesn't have yet — high-spend values currently falling through to "Untagged" for an existing tag_key, or a provider-native tag worth promoting into a virtual tag_key of its own (see list_cost_tags). Each recommendation carries `estimated_monthly_spend_cents` (USD base) it would newly cover. Mirrors GET /api/accounts/:accountId/tag-recommendations. Accepting or dismissing a recommendation is a UI/REST-only action, not available over MCP.
list_teams
read-only
List this account's teams (user groups) with their members and the cost-tag tag_value each is reserved under — team-scoped budgets (create_budget with scope_type: "team") reference… List this account's teams (user groups) with their members and the cost-tag tag_value each is reserved under — team-scoped budgets (create_budget with scope_type: "team") reference a team's id as scope_ref. Mirrors GET /api/accounts/:accountId/teams.
list_unit_metrics
read-only
List this account's saved unit-economics metrics — each one a cost ÷ business-unit ratio such as "cost per 1k API requests" or "infra cost per order". `numerator_scope` says which… List this account's saved unit-economics metrics — each one a cost ÷ business-unit ratio such as "cost per 1k API requests" or "infra cost per order". `numerator_scope` says which slice of spend is on top (the whole account, one cost source, or one cost-allocation tag_value — see list_cost_tags), `denominator_metric` names the usage metric counting the business units, and `denominator_scale` is the readability factor the ratio is quoted at (1, 1000 or 1000000). Pass an id to query_unit_costs to compute one over a date range.
list_usage_dimensions
read-only
end_datedimension*start_date
List the distinct values seen for a usage dimension ("metric" or "external_customer_id") over a date range — useful for discovering filter values before calling query_usage. Each e… List the distinct values seen for a usage dimension ("metric" or "external_customer_id") over a date range — useful for discovering filter values before calling query_usage. Each entry pairs the raw `value` with a `label` (for external_customer_id, the customer's name from account_customers when known, falling back to the id itself). Mirrors GET /api/usage/dimensions.
query_costs
read-only
tag_keyend_dategroup_bystart_datecost_metricbreakdown_by
+12
Query time-bucketed spend for this account, optionally broken down by a dimension (service, region, linked_account, usage_type, operation, or identity) or by a custom cost-allocati… Query time-bucketed spend for this account, optionally broken down by a dimension (service, region, linked_account, usage_type, operation, or identity) or by a custom cost-allocation tag (see list_cost_tags), and filtered by dimension values. `identity` is per-actor spend (e.g. an OpenAI or Anthropic api_key_id) where a provider's cost/usage API can group by it; not every provider populates it. Mirrors the GET /api/analytics endpoint used by the Plutus dashboard charts. All amounts are in USD, converted from each provider's own billing currency at the rate in effect on the day of the charge; the response states this in its `currency` field. A row carries `cost_basis` only when its `cost` figure is an estimate rather than a real invoiced charge — e.g. Anthropic's identity-grain rows, priced from Anthropic's own published per-token rates because Anthropic's cost API has no per-key breakdown at all. Absent (null) `cost_basis` means the figure is invoiced. Always qualify an estimated figure as such when relaying it — do not present it with the same confidence as an invoiced one. Where a provider reports usage alongside cost, a row also carries `quantity` and its `unit` (e.g. tokens, GB-month), plus a derived `cost_per_unit` in that same USD base. Always read `cost_per_unit` together with `cost_per_unit_label`, which names the denominator it is quoted against: token costs are quoted per 1,000 tokens ("per 1k tokens", `cost_per_unit_scale: 1000`), NOT per single token. All four fields are null when the provider reports no usage, and also when the rows behind a group carry more than one unit — a total mixing tokens and GB-month is not a quantity, so none is given. The response also carries `coverage.complete_through`: cost data for the newest periods often has not landed yet (it arrives hours-to-a-day after the period it covers), so `rows` may end before `end_date` without that being a gap in spend — the newest period(s) simply aren't complete yet. `coverage.lagging_sources`, when non-empty, names a cost source that is behind or has stopped reporting; recent periods will under-count its spend. Unlike query_unit_costs, `rows` is NOT truncated to the horizon here — treat complete_through as a caveat on the newest bucket(s), not evidence anything is missing from the rows themselves.
query_events
read-only
qend_datemeta_reposource_idevent_typestart_date
Query this account's business-event timeline (GitHub releases/PRs, PagerDuty incidents, Jira issues, GitLab, Salesforce onboarding/churn, Stripe subscription created/canceled, Verc… Query this account's business-event timeline (GitHub releases/PRs, PagerDuty incidents, Jira issues, GitLab, Salesforce onboarding/churn, Stripe subscription created/canceled, Vercel production deploys, Linear issue creation, Sentry newly reported errors) — the same events overlaid on the Cost/Event Explorer charts. Always scope with start_date/end_date: there is no pagination and results are capped at 5000 rows (oldest-first), so an unscoped query over a long history may be silently truncated. Carries no cost figure. Mirrors GET /api/events.
query_unit_costs
read-only
end_dategroup_bystart_dateunit_metric_id*
Compute one of this account's saved unit-economics metrics (see list_unit_metrics) over a date range — the cost of a slice of spend divided by the business units it produced. Each… Compute one of this account's saved unit-economics metrics (see list_unit_metrics) over a date range — the cost of a slice of spend divided by the business units it produced. Each row carries `cost` (the numerator, in the USD base like every other figure this server returns), `quantity` (the denominator, a raw count with no currency), and `unit_cost`. CRITICAL: `unit_cost` is null whenever it could not be computed, and null does NOT mean zero. It means one half of the fraction is missing for that period — either no usage was ingested (a telemetry gap) or no cost data has landed yet. Do not describe a null unit cost as a cost of zero, and do not average nulls in as zeroes; the `coverage` block reports how many rows are affected and why. Always read `unit_cost` together with `denominator_label` (e.g. "per 1k requests"), which names what it is quoted against — a per-1k figure reported as a per-request figure is wrong by three orders of magnitude. The series stops at `coverage.complete_through` rather than at the requested end_date whenever cost data for the newest periods has not arrived yet (it lands hours-to-a-day after the period it covers, while usage telemetry is pushed live). A short series is therefore normal and is NOT evidence that spend or usage stopped — say what it is complete through instead. `coverage.lagging_sources`, when non-empty, is the opposite case: a cost source that is behind or has stopped reporting, so recent periods are missing its spend and their unit costs read lower than the truth. If `numerator_status.available` is false, the cost source this metric measured has been removed from the account and `rows` is empty. That is a broken definition, not a period of zero spend — never report it as costs having fallen. Amounts are billed cost, never amortized, regardless of any cost_metric used elsewhere. A tag-scoped metric inherits that tag_key's allocation policy, so its numerator may include a redistributed share of shared spend (see list_cost_tags' redistribute_bucket) and will not match a raw dimension total. A metric whose denominator_mode is "per_customer" returns one row per (period, customer) and a `customers` block splitting them into matched, cost_without_usage (spend attributed to a customer who is not sending telemetry) and usage_without_cost (telemetry from a customer whose spend is not being allocated). Those two lists are the honest caveat on any per-customer figure and are worth mentioning when either is non-empty.
query_usage
read-only
end_dategroup_bystart_datebreakdown_byfilter_metricfilter_source_id
+1