Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

mureo_state_platform_daily_set

Add day-grain platform history to STATE.json, merging completed daily rollups by calendar date to show trends and day-over-day deltas while preserving existing days.

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 in the document and archives older ones under history/daily/<YYYY-MM>.json 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

TableJSON Schema
NameRequiredDescriptionDefault
daysYesDay-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.
pathNoOptional path to the file. Defaults to STRATEGY.md / STATE.json in the MCP server's current working directory. Paths outside cwd are refused.
reasonNoWhy 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.
platformYesPlatform 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_idYesThe 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.
as_of_dateNoOptional. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.21.3
    • changedInput schema / properties / account_id / description
      Previous value: -"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."New value: +"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."
  2. Changed1 schema field changedv0.20.0
    • addedInput schema / properties / reason
      Added value: +{
+  "description": "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.",
+  "maxLength": 500,
+  "type": "string"
+}
  3. Changed1 schema field changedv0.17.1
    • addedInput schema / properties / as_of_date
      Added value: +{
+  "description": "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.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}
  4. Addedv0.13.1

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It thoroughly documents merge-per-date-key semantics, preservation of other days, fetched_at stamping rules, retention and archival to history/daily/<YYYY-MM>.json, zero-fill avoidance, and the completeness check. This is far beyond what any structured field could 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?

The description is long, but every sentence adds a distinct behavioral rule, and the core purpose and sibling distinction are front-loaded. There is some overlap with the schema's parameter documentation, but the prose is organized and free of filler.

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?

Given six parameters, no annotations, and no output schema, the description still tells the agent what is preserved, what is refused, what gets archived, and that the updated state document is returned. It covers alternatives, retention, timestamp behavior, and edge cases, leaving no obvious gap for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds non-obvious semantics: whose today the as_of_date claim represents, the 'merely preserves is never re-stamped' behavior, and the directive to write already-fetched rows rather than triggering a new API call. It complements the schema instead of repeating it.

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?

States a specific verb and resource: 'Add DAY-GRAIN history to a platform in STATE.json's v2 platforms section' and immediately names the sibling it is not, mureo_state_platform_metrics_set, which holds one rollup per window. An agent can distinguish this from siblings without opening the 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?

Explicitly explains when to use this tool: for trend lines and day-over-day deltas that window rollups cannot show. It also gives when-not guidance: never fire an extra platform API call, omit uncollected days rather than zero-filling, only accept complete past days, and route unresolved account IDs to mureo_state_platform_not_collected_set.

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

Deploy Server

Other Tools