mureo_state_platform_metrics_set
Set a platform's metric rollups in STATE.json so the reporting dashboard renders per-platform KPIs without re-querying. Provide totals and per-window periods with period_end to keep age accurate.
Instructions
Atomically set a platform's metric ROLLUP in STATE.json's v2 platforms section so the read-only reporting dashboard can render per-platform KPIs (and the YESTERDAY / LAST_30_DAYS period toggle) without re-querying. This writes the PLATFORM-LEVEL rollup — distinct from mureo_state_upsert_campaign, which writes per-campaign metrics. Pass totals + metrics_period for the single most-recent window, and/or periods ({"YESTERDAY": {…}, "LAST_30_DAYS": {…}}) for the per-window rollups the toggle reads. periods is merged per window key (a YESTERDAY write keeps a prior LAST_30_DAYS bucket); omitted fields preserve their existing value. The window vocabulary is closed — see metrics_period. Every rollup you pass without a usable fetched_at — omitted, null or blank — is stamped with the write time, so the dashboard can state an age instead of "update time unknown"; pass your own only when the figures were pulled at some other time (a historical window). Also pass period_end on every rollup (YYYY-MM-DD): the last calendar date those figures cover, in the ad account's own timezone. It is NOT the same fact as fetched_at, and the server cannot derive it — the account's timezone is not something this process reliably knows, and a coverage date off by one day is worse than none. A rollup written without it is judged stale on its write time alone, which is how a card comes to read "Updated 14 hours ago" over figures from two days earlier. Campaigns and every other platform are preserved. account_id is required and always written onto the entry. If this platform carries a not_collected note (a previous collection failure), clear it in the same pass — call mureo_state_platform_not_collected_set with reason omitted; this call preserves the note rather than guessing that one window's rollup means the platform recovered. Returns the updated state document.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional path to the file. Defaults to STRATEGY.md / STATE.json in the MCP server's current working directory. Paths outside cwd are refused. | |
| reason | No | Why this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session. | |
| totals | No | Single-rollup totals for the most recent window (spend, impressions, clicks, conversions, cpa, ctr, result_indicator, period, fetched_at, period_end). Omit to preserve the existing value. ``fetched_at`` (ISO 8601) is stamped with the write time when you leave it out — or send it null/blank; supply a real one only for figures pulled at some other time. ``period_end`` (YYYY-MM-DD) is the last calendar date these figures COVER, which is a different fact from when they were written and is never derived for you — see the tool description. | |
| periods | No | Per-window rollups keyed by period token; each value is a totals-shaped object. The keys are the same closed set as ``metrics_period``, under the same rule: any other key is refused, never rounded onto a neighbouring window. Merged per key into the existing map. Omit to preserve the existing map. Each bucket you pass without a ``fetched_at`` is stamped with the write time; a bucket this call merely preserves is never re-stamped. State each bucket's own ``period_end`` — the windows end on different days and one date copied across them mislabels the rest. | |
| platform | Yes | Platform key: a built-in (``google_ads`` / ``meta_ads`` / ``tiktok_ads`` / ``search_console`` / ``ga4``), a platform an installed plugin registered (its provider name), or a plugin bridge ``plugin:<dist>:<provider>``. Use the SAME key the account is already stored under — one ad account has exactly one platform key, and a second key for an account another key already holds is REJECTED (the reporting view sums the entries, so it would double-count). A NEW key that is none of the three is REJECTED too: do not invent or abbreviate a platform name. | |
| account_id | Yes | The platform account id (Google customer_id / Meta act_*). Always written onto the platform entry, and used to detect a second entry for the same account. A placeholder (``unknown``, ``n/a``, …) is refused: if the collection could not resolve an id, use mureo_state_platform_not_collected_set. | |
| metrics_period | No | The window ``totals`` covers — the only windows mureo reports on. A window outside this list is refused, never rounded onto a neighbour (eight days of figures are not a seven-day answer). If your analysis covers another span, report it in your reply instead of inventing a window token: no view reads one, so the write would report success while the dashboard truthfully keeps showing the last real figures as stale. Omit to preserve the existing value. |