Skip to main content
Glama

Put a data source on a dashboard

add_data_source_to_dashboard
Idempotent

Put one data source on one of the account's dashboards, so widgets can be built on it. Use when: the user has just saved data with add_custom_data (when it is listed) and wants it on a dashboard — that call returns the sourceId to pass here — or when search_data_sources found the source they meant. Name the source ONE of three ways, in this order of preference: 'sourceId' when a previous call gave you one; 'connectionId' plus 'providerKey' exactly as search_data_sources returned them; or 'sourceName' as a last resort, which looks only among sources DashThis already holds and refuses rather than guessing between several. Returns: whether it was added, the source's id, and how many plan source slots it used. Rules: one source per call. Confirm with the user first — this changes a dashboard they may be sending to a client. A source already used on another dashboard costs no slot; one used nowhere claims one, and the call is refused rather than taking the account over its plan limit. Adding a source the dashboard already has is harmless. It does not build widgets, and it cannot connect a platform the user hasn't connected in DashThis. Then: say which source landed on which dashboard, and that the widgets are still theirs to add in DashThis.

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": {
      "dashboardId": "<dashboardId>"
    },
    "name": "add_data_source_to_dashboard"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceIdNoThe sourceId returned by search_data_sources, or by add_custom_data when it is listed. Use this whenever you have it — it is exact.
sourceNameNoThe source's name, exactly as search_data_sources returned it. Pass it alongside 'connectionId' and 'providerKey' — it becomes the name shown on the dashboard. With no ids at all it is instead used to search among sources DashThis already holds, and if more than one matches the call is refused with the candidates listed — put those to the user and never pick one yourself.
dashboardIdYesThe dashboard to add to — its GUID or the short id from its URL. Both come back from list_dashboards.
providerKeyNoThe providerKey from search_data_sources, exactly as returned. Pass with 'connectionId'. Never invent one — it is the platform's own identifier for the source.
connectionIdNoThe connectionId from search_data_sources. Pass with 'providerKey' to add a source the platform offers that DashThis has not set up yet.

Output Schema

NameRequiredDescriptionDefault
addedYesTrue when this call put the source on the dashboard, false when it was already there.
summaryNoRead this first: the result in plain language, including any caveat you must repeat when you report it. The fields alongside carry the same facts as data.
sourceIdYesThe source's id in DashThis. Present whether it was already set up or set up by this call.
slotsUsedYesPlan source slots this consumed — 0 when the source was already in use on another dashboard, or already on this one.
slotsRemainingYesSlots left on the plan afterwards. Null when there was no count to make — the account has no plan limit, or the source was already on this dashboard and nothing was claimed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: plan-slot accounting rules, refusal-rather-than-over-limit behavior, the fact that re-adding is harmless (consistent with idempotentHint=true), and the instruction to confirm with the user before mutating a client-facing dashboard. The annotations only cover safety hints; the description supplies the operational consequences.

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-loaded with purpose then use-case, returns, rules, and a next-step hint, so an agent can stop reading early. It is long and somewhat dense in the middle, but nearly every sentence carries a constraint or routing decision.

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 5-parameter mutation tool with an output schema, the description covers the full lifecycle: when to call, which sibling produced the ids, slot/cost implications, refusal cases, and what to tell the user afterward. Nothing material is missing.

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 the baseline is 3, but the description adds real meaning on top: the preference ordering among sourceId/connectionId+providerKey/sourceName and the ambiguous-name refusal semantics. It stops short of restating syntax details the schema already gives.

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 ('Put one data source on one of the account's dashboards') plus the purpose ('so widgets can be built on it'). It distinguishes itself from siblings by naming add_custom_data and search_data_sources as the upstream calls that produce its inputs.

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?

Gives explicit triggering conditions ('the user has just saved data with add_custom_data ... or when search_data_sources found the source they meant') and an ordered preference for which identifier to pass. It also states exclusions ('does not build widgets', 'cannot connect a platform the user hasn't connected') and a required confirmation step.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources