Chartbrew MCP

get_chart_data

Read-only

Read prepared chart data using saved settings and runtime inputs. May execute datasets; a stale default result can trigger background refresh. Use read_chart_results for summaries without execution, or run_dataset for dataset rows. Field filters default to chart scope; scope:cdc requires a cdcId belonging to this chart. Date filters use {type:'date',startDate:'2026-01-01',endDate:'2026-01-31'} with ISO dates and start <= end. Refresh, date filters, non-empty variables, and forceSourceRefresh require data:refresh.

Input Schema

Name	Required	Description
`chartId`	Yes	Chart ID from search_workspace; must belong to projectId.
`filters`	No	Runtime filters; defaults to []. Field filter: {type:'field',field:'root[].status',operator:'is',value:'paid'}. Operators: is, isNot, contains, notContains, greaterThan, greaterOrEqual, lessThan, lessOrEqual, isNull, isNotNull. Only isNull/isNotNull may omit value. Optional forceSourceRefresh:true requires data:refresh. Tool-specific field and date rules apply; server limits can be lower than 50.
`refresh`	No	Bypass cached source data; requires data:refresh when true. False allows cache use but does not prevent source execution on a cache miss.
`projectId`	Yes	Dashboard ID from search_workspace (dashboard result id or chart result dashboard.id). Must be accessible to the caller.
`variables`	No	Map of existing request variable names to JSON values, for example {region:'APAC'}. Defaults to {}. Any non-empty map requires data:refresh. Server size and nesting limits apply; do not use __proto__, constructor, or prototype keys.

Output Schema

Name	Required	Description	Default
`result`	Yes	Tool-specific result. Chart preview and filter write verification is returned in result.completion_check; completionRequirements is an input.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 3, 2026

addedInput schema / properties / chartId / description

Added value: +"Chart ID from search_workspace; must belong to projectId."

addedInput schema / properties / filters / description

Added value: +"Runtime filters; defaults to []. Field filter: {type:'field',field:'root[].status',operator:'is',value:'paid'}. Operators: is, isNot, contains, notContains, greaterThan, greaterOrEqual, lessThan, lessOrEqual, isNull, isNotNull. Only isNull/isNotNull may omit value. Optional forceSourceRefresh:true requires data:refresh. Tool-specific field and date rules apply; server limits can be lower than 50."

addedInput schema / properties / filters / examples

Added value: +[
+  [
+    {
+      "field": "root[].status",
+      "operator": "is",
+      "type": "field",
+      "value": "paid"
+    }
+  ]
+]

addedInput schema / properties / projectId / description

Added value: +"Dashboard ID from search_workspace (dashboard result id or chart result dashboard.id). Must be accessible to the caller."

addedInput schema / properties / refresh / description

Added value: +"Bypass cached source data; requires data:refresh when true. False allows cache use but does not prevent source execution on a cache miss."

addedInput schema / properties / variables / description

Added value: +"Map of existing request variable names to JSON values, for example {region:'APAC'}. Defaults to {}. Any non-empty map requires data:refresh. Server size and nesting limits apply; do not use __proto__, constructor, or prototype keys."

addedOutput schema / properties / result / description

Added value: +"Tool-specific result. Chart preview and filter write verification is returned in result.completion_check; completionRequirements is an input."

First observedNov 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, but the description adds important behavior: datasets may execute, stale default results can trigger background refresh, and refresh/date filters/non-empty variables/forceSourceRefresh require data:refresh. This discloses side effects and authorization needs beyond the annotations.

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?

The description is dense but front-loaded, moving from purpose to behavioral warning to alternatives to filter and permission constraints. Every sentence carries a routing rule, constraint, or permission detail; there is no filler.

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 five-parameter nested tool with an output schema and annotations, the description covers execution behavior, alternatives, filter semantics, scope rules, and permissions. Return-value details are appropriately left to the output schema.

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 description coverage is 100%, so the baseline is 3. The description adds cross-parameter meaning such as chart-scope defaults for field filters, cdcId belonging to the chart, date-filter syntax, and permission implications for variables, which goes beyond the schema.

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: 'Read prepared chart data using saved settings and runtime inputs.' It also explicitly distinguishes the tool from read_chart_results and run_dataset, so an agent can identify its role without opening sibling schemas.

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 routing guidance: use read_chart_results for summaries without execution or run_dataset for dataset rows. It also states key conditions around field-filter scope, cdcId requirements, date-filter format, and permission-gated options.

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

All Chartbrew MCP 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?