Skip to main content
Glama
questdb

mcp-server-questdb

Official

run_cell

Run a SQL cell from a QuestDB notebook, executing read statements in parallel and write statements sequentially while returning per-statement success or error details.

Instructions

Execute a SQL cell. A cell whose statements are all reads runs them in PARALLEL: one failure skips nothing, and a statement the server rejects at validation is skipped with its validation error as that statement's result. A cell containing any DDL/DML runs sequentially instead, and a failure stops the remaining statements. Returns { success, queryCount, results: string[] }, where each results entry is "success", "cancelled", or "ERROR: <message>", in source order. You do NOT see columns, rows, or values — call run_query if you need data. success is true only when every statement reached "success". This is the ONLY path that executes agent-initiated DDL/DML in a cell (apply_notebook_state and add_cell never auto-run writes) — it requires the 'write' permission and the user's consent. A markdown cell is never executed: the response is { ran: false, skipped: true, note: <reason> }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cell_idYes
buffer_idYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.3.0

TDQS

A4.6/5.0
Behavior5/5

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

Even though annotations are absent, the description clearly discloses parallel vs sequential execution, failure/skip semantics, permission and consent requirements, the exact return shape, and markdown-cell behavior. This fully carries the behavioral burden.

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 long but every sentence carries essential operational information. It is front-loaded with the core action and then layers execution semantics, return format, security, and exclusions without redundancy.

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 tool with no annotations and no output schema, this description covers everything an agent needs to call it correctly: execution model, expected results strings, no data returned, permissions, consent, and the markdown edge case. The only gap is parameter provenance, which is already reflected in the parameter_semantics score.

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

Parameters2/5

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

Schema coverage is 0%, so the description needed to explain buffer_id and cell_id, but it never mentions either parameter or how to obtain them. The word 'cell' gives some context, but an agent receives no guidance on the meaning or provenance of the two required parameters.

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 first sentence states the action and resource precisely: 'Execute a SQL cell.' It then distinguishes itself from run_query ('You do NOT see columns, rows, or values — call run_query if you need data') and from apply_notebook_state/add_cell by being the only path that executes writes.

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?

Explicitly tells an agent when to choose this tool: when a SQL cell must be executed, especially any agent-initiated DDL/DML, and names alternatives for data retrieval and note that other cell tools never auto-run writes. This removes ambiguity about tool selection.

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

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