Skip to main content
Glama

mureo_state_display_set

Set the client dashboard display by replacing the entire display section with your highlights, proposals, breakdowns, and stated values, ensuring the screen shows one consistent run.

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.
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.
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.

  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.17.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 burden of behavioral disclosure, and it does so thoroughly. It reveals that the section is replaced wholesale, omitted sections are written as absent, an empty call clears the contract, oversized bounds refuse the write rather than truncating, and the last writer wins. It also discloses the read-before-write requirement and the source-naming rule, which are critical for correct execution.

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 is front-loaded with a strong opening sentence, but it is heavily repetitive: 'The dashboard reads THIS section and nothing else' appears twice, 'Every bound below refuses the write rather than truncating it' appears nearly verbatim twice, and the 'Do NOT write the KPI funnel / daily chart' warning appears twice. The same high-stakes material could be stated half as long without losing information.

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 complex, high-stakes write operation with nested objects and no output schema, the description is complete. It covers return behavior, replacement semantics, cross-tool carry-over rules, per-field bounds and refusal behavior, the source requirement, and the relationship to other state tools. Nothing needed to invoke it correctly is left unexplained.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: source is REQUIRED despite the schema listing no required properties, source identifies whose judgment is displayed, date values are shown exactly as written, stated_values must be numeric-column-appropriate, and state enums map to colors. This turns bare parameter names into a usable contract.

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 resource: 'Write what the DASHBOARD shows for this client' and explicitly separates this from 'everything else you store.' It names the exact section of STATE.json, identifies the sibling mureo_state_report_set as the partner call, and states what this tool is not (the KPI funnel and daily chart). An agent can distinguish this from related state tools without ambiguity.

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?

The description gives explicit when-to-use and when-not-to-use guidance: call it 'in the same pass as mureo_state_report_set,' do NOT write the KPI funnel or daily chart because mureo computes them, and read the current state via mureo_state_get before writing. It also specifies the exact carry-over rule for other skills' proposals, so the invocation context is fully bounded.

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