supermetrics

get_dashboards

Read-onlyIdempotent

Read Supermetrics Studio dashboards: 'list' the dashboards the user owns or has been shared with (metadata only, no code, newest first; optional 'filter' narrows by id, title, description or tag, and 'limit'/'offset' paginate — the response carries 'total'), 'get' one dashboard's source code and metadata by ID, or 'changelog' its version history. Load the current code with 'get' before editing.

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": {
      "action": "<action>"
    },
    "name": "get_dashboards"
  }
}

Input Schema

Name	Required	Description
`limit`	No	'list' only: page size (max 500)
`action`	Yes	'get' to retrieve a dashboard's source code and metadata by ID, 'changelog' to view its version history, 'list' to list the dashboards the user owns or has been shared with (metadata only, no code)
`filter`	No	'list' only: narrow by id, title, description, or tag (case-insensitive substring)
`offset`	No	'list' only: rows to skip for pagination
`dashboard_id`	No	UUID of the dashboard. Required for 'get' and 'changelog'

Output Schema

Name	Required	Description	Default
`data`	No
`error`	No
`notes`	No
`success`	Yes
`business_context`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the readOnly/idempotent annotations, the description discloses that 'list' returns metadata only with no code, sorted newest first, with a 'total' count in the response. That ordering and shape information is genuinely useful and not derivable from annotations, though error behavior and payload size limits are not covered.

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?

One structured sentence front-loads the resource, then handles each action in order, ending with the actionable prerequisite for editing. No filler, no restated title, and the read-before-write rule lands last where it is most likely to be remembered.

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?

With five parameters, three enum actions, and an output schema, the description covers what each action yields and the pagination contract, which is what an agent needs to select and call it. Only minor gaps remain, such as behavior when 'dashboard_id' is omitted for 'get' or 'changelog'.

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 description coverage is 100% and the schema already labels 'limit'/'offset' as 'list' only and states 'dashboard_id' is required for 'get' and 'changelog'. The description restates the same action-to-parameter mapping without adding format or edge-case detail, so it sits at the baseline.

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 description names the resource (Supermetrics Studio dashboards) and enumerates three concrete operations ('list', 'get', 'changelog') with the exact object each returns (metadata only, source code, version history). An agent can distinguish this read-only accessor from the sibling 'manage_dashboards' write path without opening either schema.

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?

Each action is bound to a clear situation, and the closing sentence 'Load the current code with get before editing' gives an explicit ordering constraint for the edit workflow. It stops short of naming the write tool (manage_dashboards) as the alternative for modifications, so the read/write routing is implied rather than fully spelled out.

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

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