mcp-database-server

Overview Schema Source Related Servers Discussions Admin

run_query

Execute one read-only SQL statement against the shop SQLite database and return the resulting rows; write operations are blocked.

Instructions

Run one SQL statement on the shop database (SQLite) and return the rows.

The database is opened read-only: statements that write will fail.

Args: sql: One SQL statement

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": {
      "sql": "<sql>"
    },
    "name": "run_query"
  }
}

Input Schema

Name	Required	Description	Default
`sql`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 11, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must carry behavior, and it does disclose the most important trait: the database is opened read-only and write statements will fail. That is genuinely useful context an agent could not otherwise know. It omits row limits/truncation, whether DDL or PRAGMA are rejected, timeout behavior, and how errors are surfaced — significant gaps for a raw-SQL executor.

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-loaded with purpose and the critical read-only constraint in the first two sentences; nothing is buried. The 'Args: sql: One SQL statement' block is largely a restatement of the schema but is short and harmless.

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?

Because an output schema exists, return values need no explanation, and the description covers the essentials: dialect, single-statement limit, read-only enforcement, and row-returning behavior. It falls short on result-size limits and error semantics, which matter for an arbitrary-query tool.

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 0%, so the description must compensate, and it does: it names the parameter ('sql'), restricts it to exactly one statement, and identifies the SQL dialect as SQLite, which affects syntax the agent emits. No further detail on statement length or parameter binding is given, but the key semantics are covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 SQL statement on the shop database (SQLite) and return the rows.' That cleanly separates it from describe_table and list_tables, which are metadata tools, though the description never names them. The scope ('one statement', 'return the rows') is concrete enough to act on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the read-only constraint tells the agent not to attempt writes, and 'one SQL statement' implies no multi-statement scripts. There is no guidance on when to prefer describe_table or list_tables first to learn the schema, and no stated exclusions beyond writes.

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

Deploy Server