Skip to main content
Glama
questdb

mcp-server-questdb

Official

apply_notebook_state

Bulk-apply the complete desired state of a notebook in one atomic call. Use it to create, edit, or restructure multiple cells at once.

Instructions

Bulk-apply the entire desired state of a notebook in one atomic call. Use this for bulk edits spanning multiple cells or creating a notebook from scratch. Use update_cell or set_cell_* for small operations. Use INSTEAD OF chained add_cell + update_cell + set_cell_mode + set_cell_chart_config only when composing a multi-cell layout from scratch, changing many cells at once, or restructuring an existing notebook. The cells array is the COMPLETE desired list: cells in the current notebook whose id is missing from your request are DELETED. For new cells, omit id and one will be generated. Each cell carries exactly one of value (full verbatim SQL) or preserve_value: true (keep the existing cell's SQL, results, and run history unchanged) — prefer preserve_value for every cell whose SQL you are not changing, and NEVER send a value reconstructed from a preview or a truncated get_cell read. Charts in mode='draw' with auto_refresh=true render automatically — do not call run_cell afterwards. Cells with resolved mode='run' (explicit, or omitted: new defaults to 'run', existing preserves) auto-execute after the apply — EXCEPT cells whose statements include DDL/DML (INSERT/UPDATE/CREATE/DROP/...): those are NEVER auto-executed (their runs entry gets skipped: true), so applying state can never trigger a write's side effects. Take consent from the user, then call run_cell explicitly to execute them. Markdown cells (type:"markdown") are rendered prose and are likewise never auto-run. The response includes a runs: [{cellId, success, queryCount?, results?, error?, skipped?}] array — results is the per-statement status list ("success" / "cancelled" / "ERROR: <message>"); a top-level error is set only when the run was refused before any statement executed. Always call get_workspace_state first; the state-freshness gate applies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cellsYesComplete desired cell list, in order. Cell at index N gets position N. Missing existing-cell ids are deleted.
buffer_idYes
variablesYesOrdered notebook-scoped global variables to be referenced as @var in the query (the DECLARE block surfaced in the Variables popover). Each item is {"name": "from", "value": "dateadd('d', -7, now())"}; names have no leading '@'. Order matters: if one variable references another, place the dependency first and the dependent variable later. Values are sent as a notebook-scoped `DECLARE` block prepended to each cell statement (or merged into the cell's own `DECLARE` block when present). Globals are server-resolved at parse time, so operator precedence and lexical shadowing follow QuestDB's `DECLARE` semantics. For non-`SELECT` statement forms (`INSERT`/`CREATE`/`UPDATE`/`ALTER`/…) globals are not injected; declare locally inside the inner `SELECT` if needed. Pass null to preserve current; pass [] to clear all.
layout_modeYesNotebook layout mode after this apply. Null preserves current.
maximized_cell_idYesSpotlight one cell id, or null to clear. Pass null to clear.
Behavior5/5

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

With no annotations provided, the description fully carries the behavioral disclosure burden, and it excels. It discloses critical side-effect behavior: cells missing from the request are DELETED; DDL/DML statements are NEVER auto-executed (skipped: true) so applying state can never trigger write side effects; markdown cells never auto-run; charts with auto_refresh=true render without a separate run_cell call; and the response includes a runs array with per-cell outcome details. It also warns against sending values reconstructed from truncated reads and explains the state-freshness gate. This is far more than typical.

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 a specific behavioral or usage constraint essential for correct invocation. It is front-loaded with the core purpose and usage contrast, then systematically covers deletion semantics, value/preserve_value, auto-run behavior, DDL/DML safety, response format, and the precondition to call get_workspace_state. The density is justified by the tool's complexity; there is no filler or tautology.

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?

Given the tool's high complexity (5 required params, nested cell objects, rich side effects), this description is exceptionally complete. It covers the entire lifecycle of an apply call: prerequisites (get_workspace_state first), the atomic full-replace semantics, deletion of missing ids, execution behavior (charts auto-render, run cells auto-execute except DDL/DML and markdown), and the response shape (runs array with success/error/skipped). The guidance on preserve_value and never reconstructing SQL from truncated reads preempts common misuse. There is no gap left for the agent to guess.

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?

Even though schema description coverage is 80%, the description adds substantial meaning beyond the schema. For `cells` it explains that the array is the COMPLETE desired list with deletion semantics; for `value` it mandates verbatim/complete SQL and warns against preview/truncated sources; for `preserve_value` it explains the preference and when it is the only safe option; for `mode` it clarifies defaults; for `chart_config` it explains that apply is a full PUT and how queries array maps to statements; and for `variables` it details ordering and DECLARE semantics. The description compensates for and extends the schema rather than repeating it.

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 a specific verb+resource+scope: 'Bulk-apply the entire desired state of a notebook in one atomic call.' It clearly distinguishes from siblings by explicitly contrasting with 'update_cell or set_cell_*' for small operations and by positioning itself as the replacement for chained add/update/set calls when composing a multi-cell layout from scratch or restructuring. This leaves no ambiguity about what the tool does and how it differs from alternatives.

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?

Usage guidance is explicit and actionable: it states when to use (bulk edits spanning multiple cells, creating a notebook from scratch, restructuring) and when not to (small operations use update_cell/set_cell_*). It also names the exact alternative flow it replaces and gives a hard prerequisite: 'Always call get_workspace_state first; the state-freshness gate applies.' This is exemplary when-to-use versus when-not-to-use instruction.

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