Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

mureo_state_platform_not_collected_set

Record why a platform's figures weren't collected, or clear the note after successful sync. Prevents confusing a stopped account with a stopped collector.

Instructions

Record WHY a platform's figures could not be collected — or CLEAR that note once collection succeeds again. Without it, "not collected" and "collected, and the answer was zero" are the same STATE.json, so an operator looking at a card whose numbers have not moved cannot tell a stopped ad account from a stopped collector, and has nothing to act on. Call this when a sync / daily-check fails for one platform (expired token, permissions error, API outage) INSTEAD of writing zeros: the stored figures are left untouched, because they are still the last ones truly collected — this note says they were not UPDATED, never that they are wrong. When what failed IS resolving the account — no accessible ad account, no customer id configured — send account_id as "": that is how mureo spells "unknown", and it is the one platform writer that accepts it. Never invent a placeholder id. attempted_at is stamped by the server — do not compute it. Omit reason (or send null / blank) to CLEAR the note, and do that on the very next successful collection: nothing else retires it, and a note that outlives its failure is permanently stale information stated with confidence. Campaigns, rollups, the conversion override and every other platform are preserved, and last_synced_at is NOT re-stamped (a failed collection is not a sync). 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.
reasonNoWhat happened, in words an operator can act on — "the Meta access token expired", "the sync did not run". Not a stack trace: it is rendered on the client card, and long text is truncated. Omit / null / blank CLEARS the note.
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_*), used to detect a second entry for the same account. Send ``""`` (or null) when THIS is what the collection could not resolve — an account mureo could not name is exactly the failure worth recording, and a made-up id such as "unknown" on two failed platforms reads as ONE ad account held under two keys, which the reporting view then refuses to total. An unknown id is never written over an id the entry already holds: that entry still describes the account it described yesterday. A real id IS written onto the entry, as before.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields 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_*), used to detect a second entry for the same account. Send ``\"\"`` (or null) when THIS is what the collection could not resolve — an account mureo could not name is exactly the failure worth recording, and a made-up id such as \"unknown\" on two failed platforms reads as ONE ad account held under two keys, which the reporting view then refuses to total. An unknown id is never written over an id the entry already holds: that entry still describes the account it described yesterday. A real id IS written onto the entry, as before."
    • removedInput schema / properties / account_id / minLength
      Removed value: -1
    • changedInput schema / properties / account_id / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
  2. Addedv0.13.1

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: it leaves stored figures untouched, does not re-stamp last_synced_at, preserves other entries, and returns the updated state document. It also explains the special handling of unknown account_id and the clearing mechanism, all beyond what any schema could provide.

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 detailed and long, but every sentence carries important operational guidance. It is front-loaded with the core purpose and includes critical edge-case handling. It could be slightly more concise, but the length is justified by the complexity and the need for precise behavior.

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?

The description is exceptionally thorough for a tool with no output schema or annotations. It covers when to use, what behavior to expect, edge cases (unknown account, clearing), and side effects (last_synced_at not stamped, other entries preserved). An agent can call this correctly without any other documentation.

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

Parameters5/5

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

The schema covers 100% of parameters with descriptions, but the tool description adds significant meaning: it clarifies the semantic of account_id as an empty string for unknown, the cleared behavior of reason, and the platform key consistency requirement. This goes well beyond the schema.

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 tool's purpose: to record why a platform's figures could not be collected, and to clear that note on successful collection. It distinguishes from writing zeros and from updating metrics, and the name itself is explicit.

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?

The description explicitly says when to call (on sync failure) and when not to (INSTEAD of writing zeros), and provides guidance on clearing the note on the next successful collection. It also names the alternative (mureo_state_platform_metrics_set) by implication, as the tool used for normal metric updates.

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