Skip to main content
Glama

mureo_state_get

Read and parse the latest STATE.json to get campaign state, authoritative server time, and auto-evaluate past-due observations for daily operations.

Instructions

Read STATE.json and return its parsed v2 document: version, last_synced_at, platforms (per-platform campaigns), legacy v1 campaigns, and action_log. Returns an empty default doc when the file is absent. The response also carries server_now — the server's clock as ISO 8601 with UTC offset (e.g. 2026-07-28T10:12:33+09:00). It is the authoritative current date: every OTHER date in the document (last_synced_at, reports.*.period, action_log timestamps) is history and must never be read as 'today'. The response also names the file it read — path (the STATE.json consulted) and the runtime workspace_id (and notices when the runtime has any). server_now, path, workspace_id and notices are response fields only — do not write them back into STATE.json. A notice means the runtime does not consider this session to be on the workspace it should be on; workspace-bound skills stop on it rather than proceed. action_log scopes the returned log to cut context cost: all (default) returns the full history unchanged; pending returns only entries with an OPEN observation_due — past-due ones you still owe an outcome evaluation, and future-due ones still under observation — dropping plain log entries and entries a later rollback (rollback_of) or evaluation record (evaluation_of) already closed; none omits the log entirely. Each pending entry carries an index field (its position in the FULL log) so you can close it after evaluating — append an entry with evaluation_of: <index> — without ever loading the whole history. When filtered (pending / none) the response carries action_log_scope (the mode) and action_log_total (the full pre-filter entry count) so the log you were shown is never mistaken for the complete history. decisions scopes the recorded decisions trail the same way and independently: all (default) or none. Unless auto_evaluate is false, the call also CLOSES every past-due observation this document decides on its own and reports them in auto_evaluations / auto_evaluation_skipped.

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.
decisionsNoScope of the returned decisions trail. ``all`` (default) = every recorded decision. ``none`` = omit the section; the response still carries ``decisions_total`` and a ``decisions_scope`` marker, so an omitted trail is never read as an empty one. Independent of ``action_log``.
action_logNoScope of the returned action_log. ``all`` (default) = the full history, byte-identical to the legacy behaviour. ``pending`` = only entries with an open ``observation_due`` (past-due + future-due), for the daily-check evidence loop. ``none`` = omit the log. Filtered responses add ``action_log_scope`` + ``action_log_total`` markers.
auto_evaluateNoClose past-due observations automatically (default true). Before reading, mureo evaluates every open ``action_log`` entry whose ``observation_due`` has passed and whose outcome its own document determines — a campaign-level action with a numeric ``metrics_at_action``, on a platform whose campaign metrics were collected on or after the due date — and WRITES an ``evaluation_of`` record for each, so it leaves the pending set. The response then carries ``auto_evaluations`` (what was closed, with the verdict) and ``auto_evaluation_skipped`` (what still needs the manual ``mureo_outcome_evaluate`` + ``evaluation_of`` append, each with a reason). Pass false for a strictly read-only call — an inspection, a dry run, or a host that must not have its STATE.json touched by a read; the two keys are then omitted entirely and you owe every past-due entry a manual evaluation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.20.0
    • addedInput schema / properties / auto_evaluate
      Added value: +{
      +  "description": "Close past-due observations automatically (default true). Before reading, mureo evaluates every open ``action_log`` entry whose ``observation_due`` has passed and whose outcome its own document determines — a campaign-level action with a numeric ``metrics_at_action``, on a platform whose campaign metrics were collected on or after the due date — and WRITES an ``evaluation_of`` record for each, so it leaves the pending set. The response then carries ``auto_evaluations`` (what was closed, with the verdict) and ``auto_evaluation_skipped`` (what still needs the manual ``mureo_outcome_evaluate`` + ``evaluation_of`` append, each with a reason). Pass false for a strictly read-only call — an inspection, a dry run, or a host that must not have its STATE.json touched by a read; the two keys are then omitted entirely and you owe every past-due entry a manual evaluation.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / decisions
      Added value: +{
      +  "description": "Scope of the returned decisions trail. ``all`` (default) = every recorded decision. ``none`` = omit the section; the response still carries ``decisions_total`` and a ``decisions_scope`` marker, so an omitted trail is never read as an empty one. Independent of ``action_log``.",
      +  "enum": [
      +    "all",
      +    "none"
      +  ],
      +  "type": "string"
      +}
  2. Changed2 schema fields changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / action_log
      Added value: +{
      +  "description": "Scope of the returned action_log. ``all`` (default) = the full history, byte-identical to the legacy behaviour. ``pending`` = only entries with an open ``observation_due`` (past-due + future-due), for the daily-check evidence loop. ``none`` = omit the log. Filtered responses add ``action_log_scope`` + ``action_log_total`` markers.",
      +  "enum": [
      +    "all",
      +    "pending",
      +    "none"
      +  ],
      +  "type": "string"
      +}
  3. Addedv0.9.12
  4. Removedv0.9.6
  5. Addedv0.9.2
  6. Removedv0.9.1
  7. Addedv1.0.6

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 the full burden and handles it impressively. It discloses the empty default doc when the file is absent, the authoritative server_now semantics, the notice/workspace behavior, response-only fields that must not be written back, and the auto_evaluate side effect that writes evaluation_of records.

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 it is front-loaded with the core operation and every subsequent sentence adds a warning, side effect, or scope detail an agent needs. Some content overlaps with the schema, and the wall-of-text style is harder to scan, but there are no wasted sentences.

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 four-parameter, no-output-schema, no-annotation tool with a hidden write side effect, the description is complete. It covers return fields, missing-file behavior, response-only fields, filtering semantics, workspace notices, and the auto-evaluation mechanism, so an agent can call it correctly without additional context.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: pending entries carry an index usable for closing via evaluation_of, filtered responses have scope/total markers so they cannot be mistaken for full history, and auto_evaluate=false makes the call strictly read-only. Path and decisions gain less, but the additions are material.

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 first sentence names a specific verb ('Read'), an exact resource ('STATE.json'), and a concrete output ('parsed v2 document'), then lists the document's major sections. This clearly distinguishes mureo_state_get from mureo_state writers and from strategy/history tools.

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?

The description gives strong context for how to use the tool: which scopes to select, what the pending action_log mode is for, how to close pending entries, and when to pass auto_evaluate=false for a strict read. It does not explicitly name alternatives or say when another mureo tool would be preferred, but the read intent and scope choices are unambiguous.

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