Skip to main content
Glama
Sign In

OrionBI

by ai.orionbi
OverviewDiscussionsAdmin

Change part of a dashboard

dashboard_patch

Change part of a dashboard you own, or one shared with you to edit, without resending the whole spec: replace, add or remove a panel; set or remove a query; set the title, subtitle, notes, theme or filters. Operations apply in order to the LIVE version's spec (or to the current draft's when draft: true and a draft exists), and the result goes through the same checks a publish does — validation, every query run, the content scan — so a patch is refused on exactly what a publish would be refused on, with the same findings. A successful patch is a new version; nothing is edited in place and the previous version stays in the history. Operations: { "op": "replace_panel", "id", "panel" } (the whole new panel; keeps the id if the panel omits it) · { "op": "add_panel", "canvas", "panel", "after"? } (after a panel id on that canvas, else at the end) · { "op": "remove_panel", "id" } · { "op": "set_query", "name", "query" } · { "op": "remove_query", "name" } · { "op": "set", "path", "value" } with path one of "/title", "/subtitle", "/notes", "/theme", "/filters" (value null clears). Read the current spec with dashboard_get first so ids and query names are right. As an EDITOR you can keep the owner's queries exactly as they are and change everything around them; a query you add or change must read data you can use yourself, because the dashboard reads everything as its owner. dashboard is a name, or a /d/owner/slug path.

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": {
      "dashboard": "<dashboard>",
      "operations": "<operations>"
    },
    "name": "dashboard_patch"
  }
}

Input Schema

NameRequiredDescriptionDefault
draftNoWrite the result as a draft rather than making it live; builds on the current draft if there is one
handoffNoThe handoff id from dashboard_handoff, when this call finishes one; the page the reader is watching opens what you made
messageNoWhat changed, for the version list
dashboardYesName of the dashboard, from dashboard_list
operationsYesApplied in order; the first that cannot apply stops the patch and nothing is written

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say it is a non-readonly, non-idempotent, non-destructive open-world write. The description adds what actually matters: the patch is validated exactly as a publish would be (validation, every query run, content scan) and refused with the same findings, operations apply in order to the LIVE spec or the current draft, a successful patch creates a new version with the old one retained, and the first failing operation aborts with nothing written.

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?

Purpose and constraints are front-loaded in the first sentences, which is good, but the block is a single dense paragraph and the operations enumeration largely duplicates the anyOf consts already in the schema. Some of that prose earns its place (id retention, null clearing, ordering), but the bulk of the shape restatement could be trimmed.

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 mutating, non-idempotent tool with no output schema, the description covers everything an agent needs: target (live vs draft), ordering and failure semantics, validation/publish parity, versioning outcome, and the editor permission caveat that queries execute as the owner. Nothing material is left to inference.

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 baseline is 3, and the description goes beyond it with semantics the schema lacks: replace_panel keeps the id when the panel omits it, `after` targets a panel on the given canvas otherwise appends, `set` with value null clears the field, and dashboard accepts either a name or a /d/owner/slug path. The restating of op shapes overlaps the anyOf definitions, which keeps it from a 5.

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?

"Change part of a dashboard... without resending the whole spec" names a specific verb (partial patch) and resource, and immediately separates it from dashboard_publish. The enumerated operation set makes the scope of what can be changed unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit prerequisite workflow ("Read the current spec with dashboard_get first so ids and query names are right") and frames the alternative of sending a whole spec, which points at dashboard_publish. It does not spell out when a patch is a bad choice versus publish/promote, so it stops just short of full routing guidance.

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

All OrionBI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources