Skip to main content
Glama

edit_widget

Edit an existing report widget using plain language, e.g. "make the sessions chart weekly", "show the cost table for last quarter", "turn the donut into a bar chart", "sort the queries table by impressions", or set KPI targets: "set targets of 500 leads and a cost per lead of 180 € on the totals card" (the card then shows attainment, and for sums in a running period the linear pace and projection). Same catalog validation as add_widget — an impossible change is refused with a reason, never a wrong widget. Returns a deterministic receipt of what changed plus the widget's previous configuration (so you can restore it with another edit). Pass widgetId (from get_report) to pin the target; otherwise it is identified from your description. GRANULARITY: on a time-series chart, "by/per/each ", "one bar per ", "monthly/weekly/daily" (pro/je Monat, monatlich, wöchentlich, täglich…) are read deterministically into its time scale (Search Console, AI Visibility and All channels charts; a Day/Week/Month table switches its time bucket); a period ("last 12 months"), "a week ago", "month-over-month" or "monthly budget" is never one; a chart by Campaign, Device… is left alone; one a widget cannot show (by quarter, or weekly on a daily-only source) is refused, nothing changed. The receipt compares the widget before and after field by field: it says nothing changed only when no field differs. MOVE ONE WIDGET: with widgetId and move {position, anchorId} (no AI): after / before a widget, section_start / section_end of a section, or start / end of the report — or with widgetId and an instruction like "move this widget so it sits directly after the Top campaigns table": a move verb and a placement that names an existing widget or section are read without AI, so the preview shows from/to too (without widgetId the AI picks the widget and only the receipt names the positions). The widget keeps its configuration and joins the section it lands in; the receipt names the old and the new position, the result carries undo (the move that puts it back); an anchor that is not in the report is refused. Also handles SECTION ops on the report layout: "add a section called Paid Media above the Google Ads table", "rename the first section to Overview", "move the SEO section to the end", "remove the Awareness section but keep its widgets" (a section moves with its widgets; removal keeps them unless asked). TEXT widgets (type "text", free-text blocks) are not edited by instruction: to change one, write the new text yourself and pass it as text together with its widgetId (no instruction needed). The body is replaced exactly as given, with no AI — HTML (p, br, strong, em, u, s, ul, ol, li, h2–h4, blockquote, a href) or plain text, at most 50,000 characters. Scripts, event handlers, javascript: links, iframes, images and any inline style other than text-align are removed before saving, and the preview says so. Styling is carried by attributes, never inline styles: (text colour), (highlight), , (a tinted box around one block) and (a divider); each is painted with the report theme's own colours in light and dark mode and in the PDF. Title, width and hideTitle stay unchanged; the result carries the previous widget, so passing previous.body back as text undoes it. An instruction is read by AI: the preview's aiCost says who pays for it (the workspace's own AI key, billed by its provider, or CrunchJunkie's at no charge); text uses no AI. Requires MCP write actions; without confirm:true it returns a preview.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
moveNoMove the widget given by widgetId, deterministically (no AI; instruction is not needed and is ignored). A section moves with its widgets through an instruction instead.
textNoTEXT widgets only: the complete new body of the text widget given by widgetId, as HTML or plain text (at most 50,000 characters). Replaces the body as given, with no AI and no rewording; unsafe markup is removed. Title, width and hideTitle are kept.
confirmNoSet true to apply. Omit for a preview of what will be interpreted. With confirm:true, also pass the preview's previewToken.
reportIdYesReport id (from list_reports).
widgetIdNoExact widget id (from get_report) to pin the target. Required with text.
instructionNoThe change, in plain language. Can also remove a widget ('remove the donut'). Required unless you pass text.
previewTokenNoWith confirm:true: the previewToken from this tool's preview (valid 15 minutes, once, for exactly the previewed arguments).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false): it discloses catalog validation and refusal semantics, deterministic receipts comparing before/after, undo payloads for moves, previewToken validity (15 minutes, single use, bound to exact args), AI cost attribution via aiCost, and a detailed HTML sanitization allowlist (scripts, handlers, javascript: links, iframes removed). These are the operational facts an agent needs and they are not in the structured fields.

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?

Purpose is front-loaded in the first clause and the document is segmented by mode (GRANULARITY, MOVE ONE WIDGET, SECTION ops, TEXT widgets). It is long, but the length tracks real tool complexity (7 params, several distinct modes) and nearly every sentence carries a decision-relevant rule; some of the sanitization detail could be trimmed without loss.

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?

With no output schema, the description fully covers the return contract: a deterministic field-by-field receipt, the previous configuration for restore/undo, from/to positions for moves, and the aiCost field. It also covers prerequisites (write actions, confirm + previewToken) and refusal behavior, leaving no material gap for correct invocation.

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 the per-parameter text already carries basic meaning; the description adds genuine extra semantics: widgetId pins vs otherwise inferred, move{position,anchorId} bypasses AI and also previews from/to, text replaces the body verbatim with no AI, and instruction is ignored when move/text is supplied. It does not add syntax detail the schema lacks, so it sits just above the baseline rather than at the top.

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?

Opens with a specific verb+resource ("Edit an existing report widget") and immediately illustrates with concrete plain-language examples ("make the sessions chart weekly", "turn the donut into a bar chart"). It clearly delineates the tool's multiple modes (edit, move, section ops, text-widget replacement) and explicitly contrasts itself with add_widget and remove_widget, so an agent can place it against its siblings without opening schemas.

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 is unusually explicit about when to use which mode: pass widgetId to pin the target vs let AI identify it, use widgetId+move for deterministic no-AI moves, note that TEXT widgets are not edited by instruction, and that removal is achievable via instruction. It also states the alternative path for text (write the body yourself and pass `text`) and the precondition ("Requires MCP write actions; without confirm:true it returns a preview").

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources