Fastero

Update dashboard

fastero_update_dashboard

DestructiveIdempotent

Change a dashboard’s name, description, layout, filter bar or tabs; fields not sent stay as they are. layout, filters and tabs each replace the whole list, so send the full list with the change made: fastero_get_dashboard has the current ones. A chart left out of layout comes off this dashboard only, and the chart, its query and its place on other dashboards stay (fastero_delete_report deletes a chart everywhere). fastero_save_chart adds one chart from SQL without resending the layout. Returns the dashboard with its url.

Input Schema

Name	Required	Description
`name`	No	A new name.
`tabs`	No	The dashboard’s tabs, replacing the whole list; [] removes them and every chart is on one page again. Each entry is { id, name }: id a short string unique on the dashboard, which layout entries name as tabId; name at most 60 characters. Filters and the date grouping apply across every tab. At most 12.
`layout`	No	The charts on the dashboard, replacing the whole list. Each entry is { reportId, i, x, y, w, h, tabId?, height? }: reportId a report of this project (fastero_list_reports); i a unique string for the entry, such as the reportId. Fastero shows any summary first, then number cards, charts and tables, each in the order of this list. The first line or time-series chart leads at full width, other charts pair up two across, and one with w over 6 takes the full width (a pie never does); x, y and h change nothing on screen, which follows the order of this list, but keep y then x in that order: the PDF attached to dashboard emails and the editor’s Reset sort by them. height 'tall' makes a chart, and the one beside it, half as tall again. tabId is the tab an entry is on when the dashboard has tabs; an entry naming none is on the first.
`filters`	No	The dashboard’s filter bar, replacing the whole list; [] removes every filter. Each filter narrows every chart whose result has its column, and a dropdown lists the values in the data. Each entry is { column, type, label?, default? }: column spelled as the charts’ results name it; type one of dateRange, select, multiselect, number, text; a dateRange default is { start, end }, each YYYY-MM-DD. At most 20.
`projectId`	Yes	The project’s id, from fastero_list_projects.
`dashboardId`	Yes	A dashboard’s id, from fastero_list_dashboards.
`description`	No	A new description.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 18, 2026

addedInput schema / properties / dashboardId / description

Added value: +"A dashboard’s id, from fastero_list_dashboards."

addedInput schema / properties / description / description
```
Added value: +"A new description."
```

changedInput schema / properties / layout / description

Previous value: -"Widget placements, replacing the whole layout. Each entry is { reportId, i, x, y, w, h, tabId? }: i a unique string for the entry, x/y the grid position, w/h the size in grid units, tabId the id of the tab it is on when the dashboard has tabs (an entry naming no tab is on the first)."New value: +"The charts on the dashboard, replacing the whole list. Each entry is { reportId, i, x, y, w, h, tabId?, height? }: reportId a report of this project (fastero_list_reports); i a unique string for the entry, such as the reportId. Fastero shows any summary first, then number cards, charts and tables, each in the order of this list. The first line or time-series chart leads at full width, other charts pair up two across, and one with w over 6 takes the full width (a pie never does); x, y and h change nothing on screen, which follows the order of this list, but keep y then x in that order: the PDF attached to dashboard emails and the editor’s Reset sort by them. height 'tall' makes a chart, and the one beside it, half as tall again. tabId is the tab an entry is on when the dashboard has tabs; an entry naming none is on the first."

addedInput schema / properties / layout / items

Added value: +{
+  "properties": {
+    "h": {
+      "type": "number"
+    },
+    "height": {
+      "enum": [
+        "tall"
+      ],
+      "type": "string"
+    },
+    "i": {
+      "type": "string"
+    },
+    "reportId": {
+      "description": "A report’s id, from fastero_list_reports, or from a dashboard’s items in fastero_get_dashboard.",
+      "type": "string"
+    },
+    "tabId": {
+      "description": "The id of one of the dashboard’s tabs (tabs, here or in fastero_get_dashboard).",
+      "type": "string"
+    },
+    "w": {
+      "type": "number"
+    },
+    "x": {
+      "type": "number"
+    },
+    "y": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "reportId",
+    "i",
+    "x",
+    "y",
+    "w",
+    "h"
+  ],
+  "type": "object"
+}

addedInput schema / properties / name / description
```
Added value: +"A new name."
```

addedInput schema / properties / projectId / description

Added value: +"The project’s id, from fastero_list_projects."

addedInput schema / properties / tabs / items / properties / id / description

Added value: +"A short id you choose, unique on the dashboard; layout entries name it as tabId."

First observedOct 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: layout/filters/tabs are whole-list replacements, a chart dropped from layout only leaves this dashboard (its query and other placements survive), and the return value is the dashboard with its url. This explains exactly what the destructiveHint=true annotation means in practice and where destruction does not occur.

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?

Front-loads the core action and the replace-vs-patch rule in the first sentence, then layers caveats and sibling routing. Dense but every sentence carries a distinct constraint; it is long, though the complexity of a 7-parameter nested mutation justifies most of it.

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 still states the return value (dashboard plus url). It covers prerequisites (read current state via get_dashboard), destructive replacement scope, and the non-destructive chart-removal nuance, which is everything an agent needs to call this safely.

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 per-field syntax is already documented, but the description adds cross-parameter semantics the schema cannot: omitted fields are preserved while list-valued fields are replaced wholesale, and the full list must be resent. That is real added meaning beyond the field-level descriptions.

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?

States a specific verb and resource plus the exact fields it touches (name, description, layout, filter bar, tabs) and the patch semantics ('fields not sent stay as they are'). It distinguishes itself from fastero_get_dashboard, fastero_delete_report and fastero_save_chart by naming them and their distinct jobs.

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?

Gives clear routing: use fastero_get_dashboard to fetch current layout/filters/tabs before resending, use fastero_delete_report to remove a chart everywhere, use fastero_save_chart to add one from SQL without resending the layout. No explicit 'do not use this for X' exclusion, but the conditions that select each alternative are stated.

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

All Fastero tools Inspect

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.

Update dashboard

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources