Skip to main content
Glama

mureo_state_platform_metrics_set

Atomically set platform-level metric rollups in STATE.json so the reporting dashboard can render per-platform KPIs and YESTERDAY/LAST_30_DAYS toggles without re-querying.

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). 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

TableJSON Schema
NameRequiredDescriptionDefault
pathNoOptional path to the file. Defaults to STRATEGY.md / STATE.json in the MCP server's current working directory. Paths outside cwd are refused.
totalsNoSingle-rollup totals for the most recent window (spend, impressions, clicks, conversions, cpa, ctr, result_indicator, period, fetched_at). 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.
periodsNoPer-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.
platformYesPlatform 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_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.
metrics_periodNoThe 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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed7 schema fields changedv0.13.1
    • changedInput schema / properties / metrics_period / description
      Previous value: -"The window ``totals`` covers (e.g. ``LAST_30_DAYS``). Omit to preserve the existing value."New value: +"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."
    • addedInput schema / properties / metrics_period / enum
      Added value: +[
      +  "YESTERDAY",
      +  "LAST_7_DAYS",
      +  "LAST_30_DAYS"
      +]
    • addedInput schema / properties / periods / additionalProperties
      Added value: +false
    • changedInput schema / properties / periods / description
      Previous value: -"Per-window rollups keyed by period token (``YESTERDAY`` / ``LAST_30_DAYS`` / …); each value is a totals-shaped object. Merged per key into the existing map. Omit to preserve the existing map."New value: +"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."
    • addedInput schema / properties / periods / properties
      Added value: +{
      +  "LAST_30_DAYS": {
      +    "description": "Totals-shaped rollup for this window (spend, impressions, clicks, conversions, cpa, ctr, result_indicator, fetched_at).",
      +    "type": "object"
      +  },
      +  "LAST_7_DAYS": {
      +    "description": "Totals-shaped rollup for this window (spend, impressions, clicks, conversions, cpa, ctr, result_indicator, fetched_at).",
      +    "type": "object"
      +  },
      +  "YESTERDAY": {
      +    "description": "Totals-shaped rollup for this window (spend, impressions, clicks, conversions, cpa, ctr, result_indicator, fetched_at).",
      +    "type": "object"
      +  }
      +}
    • changedInput schema / properties / platform / description
      Previous value: -"Platform key: a built-in (``google_ads`` / ``meta_ads`` / ``tiktok_ads`` / ``search_console`` / ``ga4``) or a plugin bridge ``plugin:<dist>``. 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)."New value: +"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."
    • changedInput schema / properties / totals / description
      Previous value: -"Single-rollup totals for the most recent window (spend, impressions, clicks, conversions, cpa, ctr, result_indicator, period, fetched_at). Omit to preserve the existing value."New value: +"Single-rollup totals for the most recent window (spend, impressions, clicks, conversions, cpa, ctr, result_indicator, period, fetched_at). 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."
  2. Changed4 schema fields changedv0.10.43
    • changedInput schema / properties / account_id / description
      Previous value: -"The platform account id (Google customer_id / Meta act_*). Always written onto the platform entry."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."
    • addedInput schema / properties / account_id / minLength
      Added value: +1
    • changedInput schema / properties / platform / description
      Previous value: -"Platform key: a built-in (``google_ads`` / ``meta_ads`` / ``search_console`` / ``ga4``) or a plugin bridge ``plugin:<dist>``."New value: +"Platform key: a built-in (``google_ads`` / ``meta_ads`` / ``tiktok_ads`` / ``search_console`` / ``ga4``) or a plugin bridge ``plugin:<dist>``. 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)."
    • addedInput schema / properties / platform / minLength
      Added value: +1
  3. Changed1 schema field changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
  4. Addedv0.10.8

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behaviors: atomicity, preservation of existing values, auto-stamping of fetched_at, merging of periods per key, rejection of invalid windows/platform keys, and the nuance about not_collected notes (that this call preserves them). It also states that account_id is always written and that other platforms/campaigns are preserved. There is no contradiction with annotations since none are present.

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 (multiple paragraphs) but each sentence provides crucial behavioral details, such as merging semantics and not_collected note handling. It is front-loaded with the main purpose and then details; however, it could be more concise by trimming some restatements of schema info (e.g., window vocabulary is already in metrics_period enum). Slight over-specification reduces conciseness, but the structure is logical and information is valuable.

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 the tool's complexity (multiple optional nested fields, closed vocabularies, merge behavior, stamping) and absence of output schema and annotations, the description is remarkably complete. It covers edge cases, alternates, and the consequence of using invalid periods. It explains the return value (state document). No significant gaps identified; it fully compensates for lack of annotations and output schema.

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% and the schema already provides detailed descriptions for each parameter, including the closed set and merge behavior. The description adds context beyond schema by explaining how periods merging works per key and that omitted fields preserve values, but much of this is already in the schema (e.g., periods description says 'Merged per key'). The description adds a slight benefit by reinforcing the write-time stamping and the requirement of account_id, but does not go far beyond schema. Given high coverage, a 4 is appropriate for the additional clarity on edge cases like omitted fields and fetched_at behavior.

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 description clearly states the function: 'Atomically set a platform's metric ROLLUP in STATE.json's v2 platforms section'. It names the specific resource (platform metric rollup) and the action (set), and explicitly distinguishes from the sibling tool mureo_state_upsert_campaign which writes per-campaign metrics. This unequivocally identifies the tool's purpose and prevents confusion.

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?

Provides explicit when-to-use guidance: for storing platform-level rollups for the dashboard, and explicitly contrasts with a sibling tool (mureo_state_upsert_campaign). It also states when not to use certain parameters (metrics_period outside closed set) and points to calling another tool (mureo_state_platform_not_collected_set) for clearing not_collected notes, giving clear alternatives and exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/logly/mureo'

If you have feedback or need assistance with the MCP directory API, please join our Discord server