Skip to main content
Glama
questdb

mcp-server-questdb

Official
by questdb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

set_cell_layout

Positions a QuestDB notebook cell in grid mode with x, y, and width values (max 12 columns), returning the applied layout and cell view/mode. Use it to place cells precisely in dashboard layouts.

Instructions

Position a single cell in grid mode. x/y/w are integers in the react-grid-layout grid; width is limited to 12 columns. Cell height is derived from its semantic pane dimensions. The response includes the applied grid position plus the cell's presented view and mode; editor-only and markdown cells report mode null, and markdown also reports view null. Use set_cell_dimensions to resize a cell or change its view.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wYes
xYes
yYes
cell_idYes
buffer_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.5.0
    • removedInput schema / properties / h
      Removed value: -{
-  "type": "number"
-}
    • addedInput schema / properties / w / maximum
      Added value: +12
    • addedInput schema / properties / w / minimum
      Added value: +1
    • changedInput schema / properties / w / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / x / maximum
      Added value: +11
    • addedInput schema / properties / x / minimum
      Added value: +0
    • changedInput schema / properties / x / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / y / minimum
      Added value: +0
    • changedInput schema / properties / y / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / required
      Previous value: -[
-  "buffer_id",
-  "cell_id",
-  "x",
-  "y",
-  "w",
-  "h"
-]New value: +[
+  "buffer_id",
+  "cell_id",
+  "x",
+  "y",
+  "w"
+]
  2. First observedv0.3.0

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the 12-column width cap, that height is derived from semantic pane dimensions, and the return shape including that editor-only and markdown cells report mode null and markdown also reports view null. It omits mutation side effects and permissions, but the behavioral disclosure is unusually rich for an unannotated tool.

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-loads the core action in the first sentence, then adds grid semantics and return details. Three sentences, each earning its place, though the return-value clause is somewhat dense since no output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description appropriately explains the response; with no annotations, it covers the safety-neutral mutation context reasonably. Gaps remain around unresized cells' behavior and validation failures, but nothing essential to calling it correctly is missing.

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 description coverage is 0% for 5 parameters. The description adds real meaning for x/y/w ('integers in the react-grid-layout grid; width is limited to 12 columns'), but buffer_id and cell_id receive no explanation, so it only partially compensates for the coverage gap.

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 ('Position') plus resource and scope ('a single cell in grid mode'), and explicitly names set_cell_dimensions as the sibling for a different operation. An agent can distinguish it from set_layout_mode and set_cell_dimensions without opening schemas.

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?

Gives the operating context ('in grid mode') and an explicit alternative: 'Use set_cell_dimensions to resize a cell or change its view.' It does not cover edge cases or when this tool is inappropriate, but the primary routing decision is clear.

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

Deploy Server

Other Tools