Skip to main content
Glama
Sign In
mcp-multi-db

mcp-multi-db

by mahAnuj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

run_query

Execute read-only SQL (SELECT, WITH, EXPLAIN) on a configured database to query data safely. Writes are blocked; policy-restricted tables are refused and redacted columns return [redacted].

Instructions

Execute a read-only SQL query (SELECT, WITH, EXPLAIN) on a configured database. Writes are blocked. If the database has a policy, queries reading tables outside it are refused with the reason, and redacted columns come back as "[redacted]" (listed in redacted).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "database_id": "<database_id>",
      "sql": "<sql>"
    },
    "name": "run_query"
  }
}

Input Schema

NameRequiredDescriptionDefault
sqlYesRead-only SQL query
limitNoMax rows to return. Defaults to 100 with a ceiling of 1000 unless configured; each database's effective default and ceiling are in list_databases (rowLimits). Larger values are clamped to the ceiling.
database_idYesDatabase id from list_databases

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed2 schema fields changedv1.1.0
    • changedInput schema / properties / limit / description
      Previous value: -"Max rows to return (default 100, max 1000)"New value: +"Max rows to return. Defaults to 100 with a ceiling of 1000 unless configured; each database's effective default and ceiling are in list_databases (rowLimits). Larger values are clamped to the ceiling."
    • changedInput schema / properties / limit / maximum
      Previous value: -1000New value: +10000
  3. First observedv1.0.2

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well: it discloses that writes are blocked, that policy-restricted tables produce a refusal with a reason, and that redacted columns return "[redacted]" and are listed in a `redacted` field. Gaps remain around authentication requirements, error shapes, and timing/timeout behavior, so it is not fully exhaustive for an execution 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?

Three tight sentences, front-loaded with the core action and the read-only guarantee. There is slight redundancy between "read-only SQL query" and "Writes are blocked", but the sentence still earns its place by making the enforcement explicit rather than merely implied.

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?

For a three-parameter query tool with no annotations and no output schema, the description covers the essential safety profile (read-only, policy refusal, redaction) and even hints at a return field (`redacted`). The remaining omission is general result-shape detail, which matters less because the query itself determines the columns returned.

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 100%, so all three parameters are already documented including the limit default and clamping behavior via rowLimits. The description adds no parameter-level detail beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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 ("Execute a read-only SQL query") and enumerates the accepted statement types (SELECT, WITH, EXPLAIN) on a configured database. This clearly separates it from the sibling tools, which are all metadata/schema-listing operations rather than query execution.

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?

The read-only constraint and the SQL dialect scope give clear context for when this tool applies, and the schema points agents to list_databases for the database_id. It stops short of explicitly naming alternatives (e.g., use describe_table to learn columns before writing a query), so the routing guidance is implicit rather than spelled out.

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