mureo_state_platform_daily_set
Merges daily platform metrics into your state file by calendar date, preserving all other stored days to show trend lines and day-over-day deltas that window rollups miss.
Instructions
Add DAY-GRAIN history to a platform in STATE.json's v2 platforms section, keyed by calendar date — the trend line and day-over-day delta the reporting dashboard cannot show from the window rollups alone. Distinct from mureo_state_platform_metrics_set, which holds ONE rollup per window (YESTERDAY / LAST_7_DAYS / LAST_30_DAYS) and overwrites it on every collection, so the value it replaces is gone; this map accumulates instead, merged PER DATE KEY. Re-writing a day replaces that day only, and every other stored day survives. Write the daily rows you already fetched (the delivery report a health check pulls) — never fire an extra platform API call to fill this in. A day you did not collect is OMITTED, never written as zeros: a zero-filled day is indistinguishable from an account that stopped spending, and the readers render a gap as a gap. Only complete PAST days are accepted — today is still being spent into, and half a day filed as a day is a false low forever, because nothing revisits a day already in the map. Whose today that is, is yours to state: pass as_of_date (today in the AD ACCOUNT's timezone) when the server and the account may not share a day — without it the check uses the server's own today. Each bucket you pass without a usable fetched_at is stamped with the write time; a day this call merely preserves is never re-stamped. mureo keeps the most recent 35 days and drops older ones on write. Campaigns, the window rollups, the conversion override, any not_collected note and every other platform are preserved. Returns the updated state document.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | Day-grain rollups keyed by calendar date in **YYYY-MM-DD** (zero-padded — ``2026-08-05``, not ``2026-8-5``), one key per day, each value a totals-shaped object. Any other key shape is refused. Every key must be a day that has ENDED: today and any later date are refused, because a part-spent day stored as a whole one is a false low nothing ever corrects. Pass only the days you actually collected — omit a day you have no figures for rather than sending zeros for it. Merged per date key into the stored history. | |
| 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. | |
| platform | Yes | Platform key: a built-in (``google_ads`` / ``meta_ads`` / …), a platform an installed plugin registered, or ``plugin:<dist>:<provider>``. Use the SAME key the account is already stored under. | |
| 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. | |
| as_of_date | No | Optional. TODAY in the AD ACCOUNT's timezone, as **YYYY-MM-DD** — the day the completeness check is measured against. Omit it and the check uses the server's own today, which is correct whenever the host and the account share a day. Pass it when they may not: an account closes its day in its own timezone, so on a UTC host at 02:00 Asia/Tokyo, yesterday-in-Tokyo is still today in UTC and a genuinely complete day would be refused. The rule does not move — a day at or after this date is still refused — you are only stating whose today it is, and mureo checks that claim: an ``as_of_date`` more than 2 days ahead of the server's own date is refused outright (no timezone is further ahead than that), so a mis-inferred year cannot turn dates nobody has reached into complete history. |