Skip to main content
Glama

Run a database query

db_query
Destructive

Run one read-only statement against PostgreSQL, MySQL, SQLite, MongoDB, or Redis, inferring the engine from the connection; writes stay refused until explicitly enabled.

Instructions

Run one statement against one database (PostgreSQL, MySQL/MariaDB, SQLite, MongoDB or Redis, inferred from the connection). READ-ONLY BY DEFAULT: writes are refused unless "readOnly" is false, and statements that change schema or privileges additionally require "allowDestructive" to be true. Call db_list and db_schema first so table and column names are not guessed, and prefer "params" over inlining values in "query" so the values never appear in the statement text. Put a LIMIT in every query: results are capped anyway, and a cap you did not ask for is how a table gets silently half-read. MongoDB: "collection" is required and "action" picks the operation -- find, count, distinct, aggregate and explain read; insert, update, updateOne, replace, delete and deleteOne write and need "readOnly": false. Prefer the *One actions: one document, not every match. Redis: "query" is a single command such as GET or SCAN.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uriNoConnection string, for example postgres://user@host/db, mysql://user@host/db, sqlite:///path/to/app.db, mongodb://host/db or redis://host. Pass "profile" wherever db_list shows one.
sortNoMongoDB only, action "find". Sort document as JSON, for example {"createdAt":-1}.
fieldNoMongoDB only, action "distinct". The field whose distinct values are wanted.
limitNoMongoDB only. Documents to return, at most 1000; defaults to 50.
queryYesOne statement only: SQL, a MongoDB filter (JSON object), a MongoDB aggregation pipeline (JSON array), or a single Redis command. Multiple statements separated by ";" are refused.
actionNoMongoDB only. Reads: find (default), count, distinct, aggregate, explain. Writes: insert, update, updateOne, replace, delete, deleteOne, which need "readOnly": false. "explain" returns the planner output and never runs it. The *One actions touch one document and accept an empty filter; the plural ones refuse one, because there it means the whole collection.find
cursorNoMongoDB only. An opaque resume token from a previous result's "nextCursor". Not used by PostgreSQL, MySQL, SQLite or Redis.
formatNoHow rows are rendered as text. "json" is an array of objects; "jsonl" is one object per line and cheapest for many wide rows; "csv", "tsv" and "markdown" are tables.json
offsetNoMongoDB only. Documents to skip, for pagination. Not used by PostgreSQL, MySQL, SQLite or Redis -- put an OFFSET or a keyset predicate in "query" for those.
paramsNoValues bound to placeholders in "query" instead of pasted into it: ? for MySQL and SQLite, $n for PostgreSQL. Prefer this: a bound value never reaches the statement text, the log, or a plan cache. SQL only.
updateNoMongoDB only, action "update" or "updateOne". The update document as JSON, for example {"$set":{"seen":true}}. "update" applies it to every match, "updateOne" to the first.
upsertNoMongoDB only, action "update", "updateOne" or "replace". Insert when nothing matches.
maxRowsNoRows to return at most (default 1000, ceiling 1000000). The response says whether anything was dropped.
profileNoA profile name from db_list. Exactly one of "profile" (a name from db_list) or "uri" (an ad-hoc connection string). Prefer "profile": it keeps the password out of the transcript.
timeoutNoMilliseconds before giving up on the statement (default 30000, between 1 and 86400000).
documentNoMongoDB only, action "replace". The replacement document as JSON, for example {"name":"x"}. It replaces the matched document whole, so fields it omits are gone.
maxBytesNoBytes of result to return at most (default 262144, ceiling 67108864).
readOnlyNoTrue (the default) allows only reads. False permits writes to existing data.
collectionNoMongoDB only. Required for every MongoDB action.
projectionNoMongoDB only, action "find". Fields to return as JSON, for example {"name":1,"email":1}.
allowDestructiveNoThe second gate. With "readOnly": false, required for schema and grant changes (CREATE, ALTER, DROP, TRUNCATE, GRANT, REVOKE) and for MongoDB $out/$merge. Two flags from one caller is a weak boundary; the control that holds is a database role without those privileges.
allowWriteStagesNoMongoDB only, action "aggregate". Permit $out and $merge, which replace a collection.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesFalse when the call failed; read "error" then.
hintNo
rowsYesThe result. Null if a result limit dropped it.
bytesYes
errorNoPresent only when "ok" is false.
driverNo
formatYesRendering used for the text content block.
profileNo
rowCountYes
timezoneNo
elapsedMsYes
truncatedYesTrue when a limit removed something: the result is a prefix, not the answer.
nextCursorNo
limitReasonNomaxRows or maxBytes, when the result was truncated.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.4

TDQS

A4.8/5.0
Behavior5/5

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

Enormous disclosure beyond annotations: writes refused unless readOnly=false, schema/privilege changes need a second flag allowDestructive, results are capped silently, MongoDB write actions enumerated, and Redis takes a single command. This is consistent with the destructive/openWorld annotations rather than contradicting them.

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?

Dense and front-loaded: the read-only-by-default rule and the call-order advice lead, and the engine-specific details follow. It is long, but nearly every sentence carries actionable behavioral weight; only the engine enumeration at the top is partly redundant with the schema.

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 22-parameter, multi-engine tool, the definition covers safety gating, prerequisites, result capping, and engine-specific invocation. With a 100%-covered schema and an output schema handling return values, nothing material is missing.

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

Parameters4/5

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

Schema coverage is already 100%, but the description adds cross-parameter guidance the schema cannot: the readOnly/allowDestructive interaction, preferring params over inline values for log/plan-cache safety, and the MongoDB action split. It complements rather than repeats the field descriptions.

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 and resource ('Run one statement against one database') and enumerates the supported engines with how they are inferred. It also names sibling tools (db_list, db_schema), so an agent can place it relative to alternatives without opening the schema.

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?

Explicit when/when-not guidance: call db_list and db_schema first to avoid guessing names, prefer 'params' over inlining, always put a LIMIT because caps are enforced, and for MongoDB prefer the *One actions. Alternatives are named rather than implied.

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