Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

mureo_external_changes_import

Import changes made outside mureo into STATE.json's action_log, making manual operations visible to daily-check without duplicating known entries.

Instructions

Import changes made OUTSIDE mureo (a platform's own UI, its editor, another tool) into STATE.json's action_log, so manual operation is visible to daily-check instead of showing up only as unexplained movement in the numbers. Polls each configured platform's change feed, skips changes already imported and changes mureo itself made, and records the rest with origin='external' plus an observation window anchored on when the change actually happened. Imported entries are NOT reversible by mureo — it never saw the prior value. Every configured platform appears in the response: a platform with no change feed returns status='unavailable' with reason 'change_import_unavailable_for_', which means mureo is BLIND there, not that nothing happened. Read 'truncated': true as 'older changes in this window are unreachable' — change history cannot be backfilled, so poll often. Safe to call repeatedly; importing the same change twice is a no-op.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoOptional path to STATE.json. Defaults to STATE.json in the MCP server's current working directory. Paths outside it are refused.
sinceNoISO 8601 date or datetime to start the window at. Omit to resume from the newest change already imported for each platform (or a short default lookback on the first run). Use it to re-check a period, not to backfill: a row-capped feed cannot answer a wide window, and history that has aged out is gone.
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.
platformsNoPlatform keys to poll (e.g. ['google_ads']). Omit to cover EVERY platform in STATE.json, which is what surfaces the ones mureo cannot poll. Use the canonical key — 'plugin:<dist>:<provider>' for a plugin platform.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. Addedv0.10.44

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries full disclosure burden and excels: it states imported entries are not reversible, every platform appears in response, 'unavailable' means blind (not nothing happened), 'truncated' means older changes unreachable, and importing same change twice is a no-op. This is exemplary transparency for a complex mutation tool.

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 longer than average but every sentence contributes—no filler. It front-loads the core purpose, then details behavioral nuances and edge cases. While not terse, it is structured logically and avoids redundancy, making it efficient despite length.

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?

For a tool with no output schema and no annotations, it covers all critical aspects: idempotency, non-reversibility, per-platform response statuses, truncation semantics, and platform key usage. It even explains why 'unavailable' is important (blind spot). Nothing an agent needs to call it correctly is missing.

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 baseline is 3, but the description adds meaningful context: 'since' is clarified as not for backfilling, 'platforms' omitting covers every platform and surfaces unpollable ones, and 'reason' is stored on the journal and action_log entry. These go beyond schema descriptions, earning a 4.

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 imports changes made outside mureo into STATE.json's action_log for visibility in daily-check. It uses specific verbs (import, polls, records) and a specific resource (STATE.json action_log). It distinguishes from siblings by focusing on external changes vs. internal operations like mureo_state_action_log_append, though it doesn't name that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context: use it to surface manual operations that otherwise appear as unexplained movement. It gives guidance on when to use 'since' (re-check a period, not backfill) and notes it is safe to call repeatedly. However, it does not explicitly contrast with alternatives like mureo_state_action_log_append, relying on the purpose statement alone for differentiation.

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