Skip to main content
Glama

mureo_state_display_set

Write the client dashboard section that operators see, replacing it wholesale with your current run's highlights, proposals, breakdowns, and stated values so the screen shows one consistent moment.

Instructions

Write what the DASHBOARD shows for this client — a small, strictly bounded surface, separate from everything else you store. STATE.json is your working memory and is prose-heavy by design; the dashboard reads THIS section and nothing else, so your reasoning keeps going exactly where it already goes and stops reaching the screen. Call it in the same pass as mureo_state_report_set, from the same figures. The whole section is replaced by what this call states — an omitted section is written as absent, not kept from the last run, because these five describe one client at one moment and mixing two runs on one screen is worse than showing a section fewer. A call that states nothing CLEARS the contract. Do NOT write the KPI funnel (spend / impressions / clicks / conversions, CPM / CPC / CPA) or the daily chart: mureo computes both from the stored totals and the day-grain history, so there is nothing for you to get wrong there. Every bound below REFUSES the write rather than truncating it — a sentence cut in half reads like a bug and nobody can tell what was removed. Returns the updated state document. The dashboard reads THIS section and nothing else — keep your reasoning where it already goes. Every bound below refuses the write rather than truncating it, because a sentence cut in half is worse than a long one. nav_message: one line, at most 80 characters. highlights: at most 3 items of {tone, text}, tone one of good/watch/bad, text at most 60 characters. proposals: {title, body, status, date}, title at most 30 and body at most 80 characters, status one of proposed/done. breakdown.campaigns / breakdown.adgroups: rows of {name, spend, mcpa, target_cpa, state, note} — the three figures are raw numbers, state is one of target_met/improving/watch/worsening/no_data, note at most 40 characters. stated_values: {label, value}, label at most 24 characters and value a raw number or a string of at most 12 characters — a sentence there is refused, because it lands in a numeric column. Do NOT write the KPI funnel or the daily chart: mureo computes both from the stored totals. display is REPLACED WHOLE and the last writer wins — there is no merge. Before you write it, read the current one (mureo_state_get). Of what another skill wrote TODAY, carry exactly one thing into your own write: its proposals that are still live — not yet done, and not contradicted by what you just found. Everything else you write from your own run alone, because a screen assembled from two runs shows a moment that never happened. And carry over NOTHING ELSE: never copy another skill's nav_message, highlights, breakdown or stated_values, which would put its judgement under your name when you cannot vouch for it. Name yourself in source so the screen says whose answer it is.

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.
sourceNoThe skill writing this screen — 'daily-check', 'weekly-report', your own name. REQUIRED whenever you state any section: the contract is replaced wholesale by whoever writes it last, so without this the card cannot say whose answer it is showing. ``generated_at`` is stamped by the server — do not compute it.
breakdownNoThe two per-entity tables: ``campaigns`` and ``adgroups``, each an array of {name, spend, mcpa, target_cpa, state, note}. Figures are raw numbers, ``state`` comes from a closed set, and a figure you do not have is OMITTED rather than written as 0.
proposalsNoWhat you propose doing, or have done — one entry each, never one paragraph listing several.
highlightsNoAt most 3 chips — what this client's card says at a glance. A fourth is not extra information on screen; it is the point at which none of them is read, so choose.
nav_messageNoThe single operator-facing line at the top of the report (運用ナビ): what to do next, in at most 80 characters. One line — a second sentence here is a paragraph by tomorrow.
stated_valuesNoLabelled figures this report states that are not one of mureo's headline metrics — a CVR, a target, a count. Chips, not a table of prose.

Schema Changelog

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

  1. Addedv0.17.1

TDQS

A4.5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it is exhaustive: replace-whole/no-merge semantics ('REPLACED WHOLE and the last writer wins'), an empty call clears the contract, bounds refuse writes rather than truncate, and the return value is stated ('Returns the updated state document'). It also discloses that the KPI funnel is server-computed and that source attribution is required.

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

Conciseness2/5

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

The description runs roughly 700 words and repeats key points almost verbatim: 'The dashboard reads THIS section and nothing else' appears three times, 'Every bound below refuses the write rather than truncating' twice, and the KPI-funnel exclusion twice. It front-loads the core message well, but every sentence does not earn its place; the redundancy is a clear structural defect.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a state-write tool with heavily nested schemas and no output schema, the description is complete: it states the return value, preconditions (read before write), postconditions (wholesale replacement, clearing on empty), and concurrency behavior (last writer wins). Nothing an agent needs to call it safely is missing, though the verbosity detracts from the presentation.

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% (every property has inline constraints, enums, and rationale), so the baseline is 3; the description earns a 4 by adding document-level semantics the schema cannot express — omitted sections are written as absent rather than preserved, proposals from other skills carry over only when still live, and the numeric-column rationale for refusing prose in stated_values.value.

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 opens with a specific verb and bounded resource — 'Write what the DASHBOARD shows for this client — a small, strictly bounded surface, separate from everything else you store.' It differentiates from siblings by naming mureo_state_report_set (same pass, different surface) and mureo_state_get (read before write), making it unmistakably the display-surface writer among the mureo_state_* cluster.

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?

Explicit call-when guidance is present: 'Call it in the same pass as mureo_state_report_set, from the same figures' and 'Before you write it, read the current one (mureo_state_get)'. It also gives hard exclusions — 'Do NOT write the KPI funnel or the daily chart: mureo computes both from the stored totals' — and a precise carry-over policy naming exactly what may and may not be reused from other skills' writes.

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