Skip to main content
Glama
questdb

mcp-server-questdb

Official

set_cell_chart_config

Configure chart for a notebook cell: set x-axis column, per-query type/options, and shared right axis for multi-query charts.

Instructions

Configure the chart for a draw-mode cell. The cell's ;-separated SELECTs AUTO-COMBINE into one chart sharing the first query's x-axis; queries holds one config per statement (index-aligned). Queries combine when their x-axis kind matches: all-temporal merge by time, all-categorical merge by category name. Each query keeps its own type (line/area/stepLine/stepArea/bar/stackedBar/scatter/pie/candlestick); set axis:"right" (+ optional right_axis) for a series on a different unit/scale; enabled:false opts a query out (the first query is always included — it defines the x-axis). For a candlestick query, supply ohlc:{open,high,low,close} (required — a candlestick needs an explicit ohlc mapping). When x_column is a NUMERIC column (not a timestamp/category) it renders as a continuous value axis. Numeric-x charts are single-query (they don't combine). Patch semantics: top-level x_column/right_axis null = preserve; queries null = preserve; queries: [] clears overrides (back to inference); a non-null queries array REPLACES all per-query configs (send one entry per ;-split statement — a non-empty array whose length differs from the statement count is rejected). pie/scatter/stackedBar only render as a chart of their own (single-query).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cell_idYes
queriesYesOne config per `;`-split query, index-aligned. Send the FULL array — one entry per statement, never a partial subset: a non-null array REPLACES all per-query configs, so any omitted statement loses its config. A non-empty array whose length ≠ the cell's `;`-split statement count is REJECTED. Null (the whole array) preserves the current config; `[]` resets every statement to inference; a `null` entry infers just that statement.
x_columnYesShared x-axis column (the first query's). Null preserves.
buffer_idYes
right_axisYesShared right y-axis; meaningful when some query has axis='right'. Null preserves.
Behavior5/5

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

With no annotations, the description fully carries the behavioral disclosure burden. It explains auto-combine semantics, index-aligned query configs, the always-included first query, enabled:false opting out, required ohlc mapping for candlesticks, and patch semantics including replacement vs reset behavior. This is exemplary transparency.

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 description is dense and information-packed; every sentence contributes meaningful detail with no filler. However, it is one long paragraph that mixes high-level behavior, edge cases, and patch semantics, making it harder to scan. A little structural separation would improve readability without losing content.

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?

This is a complex configuration tool with no output schema, yet the description thoroughly covers combine rules, per-query types, axis handling, numeric-x limitations, candlestick requirements, and patch semantics including rejection conditions. It leaves few open questions and is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 60% of parameters with descriptions, but the tool description significantly extends this by explaining index-alignment, replacement semantics for the queries array, conditionality of ohlc, axis behavior, and the meaning of x_column as the shared x-axis. It adds meaning far beyond the structured schema fields.

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 opens with 'Configure the chart for a draw-mode cell,' a specific verb+resource statement that clearly distinguishes this tool from sibling cell operations like set_cell_mode or set_cell_layout. It precisely names the target (chart config for draw-mode cells) and the action (configure), leaving no ambiguity about what the tool does.

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?

The description provides detailed contextual guidance on how to use the tool, including combining rules, when numeric-x charts cannot be combined, and when pie/scatter/stackedBar render only as single-query charts. It does not explicitly name alternative tools, but the unique scope makes exclusions unnecessary and the usage context is strong.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/questdb/mcp-server-questdb'

If you have feedback or need assistance with the MCP directory API, please join our Discord server