Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

mureo_decision_record

Log decisions with rationale, metrics, and status; update via superseding records to preserve the full decision history for audit and reproducibility.

Instructions

Record a decision — a proposal, or the operator's answer to one — so the reasoning survives the session. Call it BEFORE you surface a proposal to the operator, with status='proposed', the figures you judged it on in metrics, and your reasoning in rationale. When the operator answers, call it AGAIN with status='adopted' / 'rejected' / 'deferred' and supersedes set to the first record's decision_id: the section is APPEND-ONLY, so a status change is a new record, never an edit — that is what keeps 'we proposed this on the 4th and it was turned down' recoverable. After you carry a decision out, record it once more (or name the entries in related_actions) so the change and the reason for it are joined. display.proposals is the SCREEN — one moment, replaced whole on every dashboard write; this is the RECORD. decision_id and recorded_at are minted by the server; do not compute either. Every bound below refuses the write rather than truncating it.

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.
titleYesWhat is being decided, in one line (e.g. 'Pause the generic ad group in Search_Lead-Gen').
statusYesWhere the decision stands. 'proposed' before the operator has answered; 'adopted' / 'rejected' / 'deferred' afterwards, with `supersedes` set. 'deferred' is not 'rejected' — 'not now' and 'no' call for different behaviour next week.
metricsNoThe figures the decision was judged on, as they stood THEN (e.g. {"cpa_7d": 5200, "conversions_7d": 45}). At most 20 keys, each value a string, number, boolean or null — a nested object is refused, and so is a string longer than 200 characters (a figure that needs a sentence belongs in `rationale`). Without them a rationale read next month against today's numbers is unfalsifiable.
batch_idNoThe declared change set this decision concerns. A CLOSED batch is fine — the verdict on a bulk pass is normally recorded after it finished.
platformNoPlatform the decision is about (google_ads / meta_ads / ...), when it is about one.
entity_idNoThe entity's id. Must be given together with `entity_type`.
rationaleYesWhy — the evidence you acted on and the effect you expect. This is the payload: nothing downstream can reconstruct it, and you are the last point at which it exists.
supersedesNoThe `decision_id` of the record this one updates. Required in practice for any status other than the first 'proposed', and validated: it must name a decision already on record.
campaign_idNoCampaign the decision is about, if any.
entity_typeNoSub-campaign entity kind (ad_group / ad_set / placement / ...). Must be given together with `entity_id`.
related_actionsNoPositional indices into the full action_log of the entries this decision produced. Validated against the log — an index past its end is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.20.0

TDQS

A5/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 it delivers: append-only semantics, new-record-on-status-change, server-minted `decision_id`/`recorded_at`, refusal rather than truncation on bound violations, and server-side validation for `supersedes` and `related_actions`. It also discloses data-shape rules (metrics flat and bounded, entity_id/entity_type must be paired, nested objects refused). This is far beyond what a bare 'Record a decision' would provide.

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 single dense paragraph is long but every sentence earns its place—lifecycle timing, append-only rule, screen-vs-record contrast, server-minted IDs, and validation behavior are all load-bearing. The use of monospace names and bolded statuses keeps it scannable, and information is front-loaded with the core action before the lifecycle details. No filler or repetition.

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 12-parameter side-effecting write with no annotations and no output schema, the description is unusually complete: it explains when to call, what values to pass at each stage, how records link, and what the server enforces. The only implicit piece is that the first call returns `decision_id`, but the instruction to set `supersedes` to 'the first record's decision_id' makes that readable from context. Nothing essential to correct invocation is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds substantial cross-parameter meaning: the status lifecycle and its relationship to `supersedes`, the role of `metrics` as figures 'as they stood THEN,' `rationale` as the payload, and the instruction not to compute server-owned IDs. It also explains validation behavior that the JSON schema cannot express, such as bound violations refusing the write. This raises the score well above baseline.

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 states the tool's verb and resource explicitly—'Record a decision—a proposal, or the operator's answer to one—so the reasoning survives the session'—and frames it as the durable record of either a proposal or an operator decision. It also separates itself from sibling concerns by contrasting `display.proposals` (the screen, replaced whole) with 'this is the RECORD,' and from action entries via `related_actions`. This is specific enough to distinguish it from the many state/mutation siblings.

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 an explicit call protocol: call BEFORE surfacing a proposal with status='proposed'; call AGAIN when the operator answers with adopted/rejected/deferred and `supersedes` pointing at the first record; record once more after carrying the decision out or name `related_actions`. It also states the when-not boundary—status changes are never edits because the section is append-only—and identifies the display screen as an alternative destination not to confuse with this record. This covers when, how often, and what distinguishes the write.

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