Skip to main content
Glama
questdb

mcp-server-questdb

Official

get_cell

Fetch a QuestDB notebook cell's value, type, view, heights, chart config, last-run status, and refresh flags. Use before rewriting cells to check if the value was truncated.

Instructions

Get full details of a cell (value, kind via type, editor_height/result_height, view, chart config, last-run status + trimmed error). Height values are fixed CSS pixels or "auto". view reports what a SQL/draw cell presents: "editor" while there is nothing to show, else the stored result or editor_result arrangement. Markdown has no pane-view state: it reports view and result_height as null. Other LIVE-ONLY fields are refreshing: true, last_refresh_error, and auto_refresh_blocked: "contains_write"; absence never means "not refreshing" or "not blocked". last_run_status is unrelated to refresh state: it stays the outcome of the last completed RUN. type:"markdown" marks a prose cell whose value is markdown source; SQL cells omit type. Never includes query result data. By default the value is capped at 4 KB; a capped response carries truncated: true and full_length. A truncated value is NOT the cell's real content — NEVER write it back (update_cell / apply_notebook_state value); re-read with get_full_content: true first, or keep the cell with preserve_value: true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cell_idYes
buffer_idYes
get_full_contentYesTrue returns the verbatim full value with no cap (errors above 1 MB). Required before rewriting any cell whose read came back truncated. Null/omitted applies the 4 KB cap.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: live-only fields (refreshing, last_refresh_error, auto_refresh_blocked), the rule that absence never means 'not refreshing', the distinction between last_run_status and refresh state, and the critical warning that truncated values must never be written back. This is exactly the context an agent needs.

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 what is returned, and the length is justified by the many live-only fields and the write-back hazard. A few clauses are tightly packed, but nothing is redundant 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?

No output schema exists, so the description has to explain return values, and it fully does: per-field semantics, null-value rules for markdown cells, truncation flags, and what is deliberately excluded (query result data). An agent can interpret the response without any schema.

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 only 33% — cell_id and buffer_id have no descriptions anywhere. The description reinforces get_full_content semantics (4 KB cap, 1 MB error ceiling, re-read before rewriting), but buffer_id/cell_id stay undocumented, so it only partly compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Get full details of a cell') and enumerates the returned facets, which implicitly separates it from list_cells and get_notebook_state. It stops short of explicitly naming the sibling it replaces when you only need a summary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Embedded guidance exists for the truncation workflow: re-read with get_full_content: true before rewriting, and use preserve_value: true to avoid clobbering. However, there is no explicit statement of when to choose get_cell over list_cells or get_notebook_state.

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