Plutus

list_dashboard_widget_catalog

Read-onlyIdempotent

List the built-in ("preset") dashboard widgets available to place with create_dashboard/set_dashboard_widgets — small kpi stat tiles and larger widget data cards, each with the id (catalog_id) a {"kind": "preset", "catalog_id": "..."} widget spec references. There is no preset chart: to put a trend chart on a dashboard, build one inline with a {"kind": "custom_chart", ...} spec instead of a catalog_id — see create_dashboard's description for that shape.

The response also carries grid_cols (the canvas width every widget's x/w is measured against) and size_bounds, the min/max w/h each widget TYPE (kpi/chart/widget — not each individual catalog_id) accepts when a spec overrides its default size — use these before calling create_dashboard/set_dashboard_widgets with an explicit w/h.

Each widget also carries what its data is: data_version, report_scopes (the report scopes it can be shown for: account, cost_source, tag), window_mode (report: it covers the window it is given; fixed: it states its own, such as the last 30 days) and names_people (it lists people or API keys, so viewers cannot see it). Pass data_schema_for with up to 10 catalog ids to get the JSON Schema of each one's data under data_schemas.

Input Schema

Name	Required	Description	Default
`data_schema_for`	No	Catalog ids whose data JSON Schema to include, at most 10.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / data_schema_for

Added value: +{
+  "description": "Catalog ids whose data JSON Schema to include, at most 10.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

First observedSep 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare this as a safe read-only, idempotent, closed-world operation, but the description adds substantial behavioral context: `grid_cols`, `size_bounds`, `window_mode`, `report_scopes`, and the important caveat that widgets with `names_people` are not visible to viewers. This goes well beyond what annotations provide.

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?

The purpose and the key 'no preset chart' caveat are front-loaded, and the response-field explanations are relevant. It is still noticeably long for a one-parameter list tool and repeats `create_dashboard`/`set_dashboard_widgets` several times, so it is not maximally tight.

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?

There is no output schema, but the description enumerates the important return fields — `grid_cols`, `size_bounds`, `data_version`, `report_scopes`, `window_mode`, `names_people`, and `data_schemas` — so an agent has the context needed to use the results correctly.

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% and the only parameter, `data_schema_for`, is already documented in the schema. The description largely repeats that limit and adds only the output location (`data_schemas`), so the baseline of 3 is appropriate.

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?

The first sentence states a specific verb and resource — listing built-in preset dashboard widgets — and immediately distinguishes the two preset types (`kpi` tiles vs `widget` cards) plus the absence of preset charts. That is enough for an agent to tell this apart from `list_dashboards` or `get_dashboard`.

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 explicitly says to use the catalog before calling `create_dashboard`/`set_dashboard_widgets` with an explicit `w`/`h`, and it names the alternative path for charts: build a `custom_chart` inline instead of using a `catalog_id`. It also explains when to pass `data_schema_for`.

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

All Plutus 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?