Skip to main content
Glama

mureo_state_platform_not_collected_set

Record why a platform's figures were not collected, and clear the note when collection succeeds, so operators can distinguish a stopped account from 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. 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_*). Always written onto the platform entry, and used to detect a second entry for the same account.

Schema Changelog

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

  1. Addedv0.13.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses side effects: stored figures are left untouched, other state fields are preserved, last_synced_at is not re-stamped, attempted_at is server-stamped, and the call returns the updated state document.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but densely packed and front-loaded with the core action. Each sentence earns its place: why the tool exists, when to use it, what not to do, clearing semantics, preservation guarantees, and return value. Bold formatting helps highlight the critical clear-on-success 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?

This is a nuance-heavy mutation tool with no annotations and no output schema. The description covers the failure semantics, clearing behavior, preserved fields, the non-restamping of last_synced_at, and the return value. It is complete enough for an agent to invoke the tool correctly and understand its full impact on state.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces parameter semantics that are already in the schema, such as omitting/null/blank reason to clear the note and using the same platform key under which the account is stored. It adds useful narrative context but no significant new parameter-level facts 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 records WHY a platform's figures could not be collected, or clears that note once collection succeeds. It explicitly distinguishes 'not collected' from 'collected, and the answer was zero,' and scopes the operation to a single platform, separating it from the workspace-level sibling.

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?

It gives explicit when-to-use guidance: call this when a sync/daily-check fails for one platform INSTEAD of writing zeros. It also prescribes when to clear the note (the very next successful collection), states that nothing else retires it, and clarifies that a failed collection is not a sync so last_synced_at must not be re-stamped.

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