Atwork

Read Dashboard

dashboard.read

Read-onlyIdempotent

Read a dashboard's structure: returns dashboard (id, title, description, sheetId + sheetName when bound to a sheet) and widgets[] (each id, title, type, optional summary). Set includeWidgetData=true to also fetch each widget's current rendered numbers — slower, only needed when answering questions ABOUT the numbers (totals, trends, breakdowns) rather than the layout. Without it you save a fetch per widget.

Input Schema

Name	Required	Description	Default
`dashboardId`	Yes
`includeWidgetData`	No

Output Schema

Name	Required	Description	Default
`widgets`	Yes	Widgets in layout order; `summary` describes the rendered data when includeWidgetData was set
`dashboard`	Yes	The dashboard and, when bound to one, its sheet

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 4, 2026
- removedOutput schema / properties / dashboard / properties / id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
```
- addedOutput schema / properties / dashboard / properties / id / type
```
Added value: +[
+  "string",
+  "number"
+]
```
- removedOutput schema / properties / widgets / items / properties / id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
```
- addedOutput schema / properties / widgets / items / properties / id / type
```
Added value: +[
+  "string",
+  "number"
+]
```
First observedOct 20, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still earns credit by disclosing a cost tradeoff ('slower', 'save a fetch per widget') that no annotation conveys. It stops short of details like pagination or widget-count limits, which is acceptable for a read tool.

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

Conciseness5/5

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

Three sentences, front-loaded with the return shape and followed by the flag's tradeoff. Every clause carries information; nothing restates the schema or the title.

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 two-parameter read tool with an output schema, the description supplies everything needed to choose the right call: what is returned, what the optional flag changes, and when that extra cost is justified. No material gap remains.

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 0%, so the description has to carry the parameter meaning and largely does: it explains exactly what `includeWidgetData` adds to the response, its performance cost, and its default-off behavior. `dashboardId` is left as implicitly obvious (it selects the dashboard) and gets no format or id-source detail.

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 precise verb and resource ('Read a dashboard's structure') and enumerates what comes back (`dashboard` with id/title/description/sheet binding, and `widgets[]` with id/title/type/summary). The verb alone separates it from dashboard.create/update/delete/restore siblings in the namespace.

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 explicit when/when-not guidance for the only real decision point: set `includeWidgetData=true` only when answering questions ABOUT the numbers, not the layout. It does not point to alternative siblings (e.g. sheet.read or widget.update) for any residual need, but the mode-selection guidance is unambiguous.

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

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

Resources

Need Help?