Skip to main content
Glama

Report Page Update

report_page_update
Destructive

Update page title, description, and/or layout. Layout is authoritative: send every slot on the page. KPI (number/big_number) cards default to 6x40 grid units (24-column grid, 10px rows) and are raised to at least 4x32; other cards below an enlarged KPI are pushed down automatically. Filter cards on the layout follow report dateRange (report_update); dateRange here alone is rejected — include layout/title/description changes. Requires revisions from report_page_get. Invalid/overlapping layout → LAYOUT_INVALID; stale revisions → CONFLICT (re-read report_page_get). Page title header: the markdown card with a single ## Page title line (page title only, no description). It uses default report card chrome (no MCP style overrides). Keep its cardId in the layout; you may resize or move it, e.g. title x=0,w=19 and the date-range filter x=19,w=4 on the same row (keep column 24 free; x=20 clips the filter). Optional styling uses report_card_update configDelta.style, not inline content. Page writes never add a second header while it is in the layout. 24-column grid (x,y,w,h). To move a card: drop from source layout, report_card_update configDelta.pageId, full layout on target page.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "clientId": "<clientId>",
      "pageId": "<pageId>"
    },
    "name": "report_page_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNoDisplay title for the report, page tab, or card.
layoutNoFull page layout: [{cardId, cardType?, chartType?, x, y, w, h}, ...] — 24-column grid.
pageIdYesPage tab id (page_<hex> or hex).
clientIdYes16-character hex client id from client_list.
dateRangeNoPreset (last30days) or [startISO, endISO] on report_create, report_update, or report_card_create. Ignored on report_page_create; on report_page_update use report_update for view dateRange.
revisionsNoOptimistic lock from the matching get tool (report_get, report_page_get, or report_card_get). Omit for Jepto agent sessions (server loads). 0 is valid on never-edited resources.
descriptionNoDescription or explanatory subtitle.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / dateRange / description
      Previous value: -"Preset (last30days) or [startISO, endISO] on report_create, report_update, or report_card_generate. Ignored on report_page_create; on report_page_update use report_update for view dateRange."New value: +"Preset (last30days) or [startISO, endISO] on report_create, report_update, or report_card_create. Ignored on report_page_create; on report_page_update use report_update for view dateRange."
  2. Changed7 schema fields changed
    • changedInput schema / properties / dateRange / description
      Previous value: -"Preset (last30days) or [startISO, endISO] for report or card date range."New value: +"Preset (last30days) or [startISO, endISO] on report_create, report_update, or report_card_generate. Ignored on report_page_create; on report_page_update use report_update for view dateRange."
    • changedInput schema / properties / description / description
      Previous value: -"Optional string parameter."New value: +"Description or explanatory subtitle."
    • addedInput schema / properties / revisions / anyOf
      Added value: +[
      +  {
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / revisions / default
      Previous value: -0New value: +null
    • changedInput schema / properties / revisions / description
      Previous value: -"Optimistic lock from report_page_get / report_card_get / report_get (0 = omit)."New value: +"Optimistic lock from the matching get tool (report_get, report_page_get, or report_card_get). Omit for Jepto agent sessions (server loads). 0 is valid on never-edited resources."
    • removedInput schema / properties / revisions / type
      Removed value: -"integer"
    • changedInput schema / properties / title / description
      Previous value: -"Optional string parameter."New value: +"Display title for the report, page tab, or card."
  3. Added

TDQS

A4/5.0
Behavior4/5

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

Beyond the destructiveHint=true annotation, it discloses real operational consequences: layout is authoritative and must contain every slot, KPI cards are auto-raised to at least 4x32 and push other cards down, and specific failure modes (LAYOUT_INVALID, CONFLICT with a re-read remedy). It does not say what the response contains after a successful write, which keeps it short of a 5.

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

Conciseness3/5

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

The first two sentences are well front-loaded, but the middle is a run-on of layout geometry, header-card rules, and styling detours that an agent must parse before reaching the error semantics. Several clauses ("It uses default report card chrome (no MCP style overrides)") are low-value for tool selection and add density without proportional benefit.

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 destructive mutation with no output schema, it covers preconditions, layout invariants, error codes, and the cross-tool sequence for moving cards. It stops short of describing what a successful call returns or how the resulting page can be verified, leaving a small gap for a write tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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, and the schema already documents pageId, clientId, revisions, and dateRange formats. The description adds genuine semantic weight to layout (full-slot requirement, 24-column grid, KPI sizing floors, x=20 filter clipping) and to revisions (stale → CONFLICT), but says little extra about title/description beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource plus the three mutable fields: "Update page title, description, and/or layout." It partially differentiates from siblings by naming report_update for view dateRange and report_card_update for styling, though it does not state outright why one would choose report_page_update over report_page_create/delete.

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 explicit preconditions ("Requires revisions from report_page_get") and explicit exclusions ("dateRange here alone is rejected — include layout/title/description changes"; dateRange belongs on report_update; styling belongs on report_card_update configDelta.style). The alternative-condition mapping is spelled out rather than implied.

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.