What can you do with this server?

This is a read-only MCP server for a SQLite database, enabling schema discovery, data querying, and query plan analysis. * listTables: Discover all tables in the database. * listViews: Discover all views in the database. * listTriggers: Discover all user-defined triggers in the database. * getTableSchema: Retrieve detailed column definitions (type, nullability, primary key, defaults) and foreign key relationships for a specific table. * readQuery: Execute read-only SQL queries (SELECT/EXPLAIN) with cursor-based pagination for large result sets. * explainQuery: Retrieve the execution plan (EXPLAIN QUERY PLAN) for a SQL query to diagnose performance and understand index usage.

Which integrations are available for this server?

Enables connection to MariaDB databases to list databases, inspect table schemas, and execute SQL read or write queries with built-in security validation. Enables connection to MySQL databases to list databases, inspect table schemas, and execute SQL read or write queries with built-in security validation. Enables connection to PostgreSQL databases to list databases, inspect table schemas, and execute SQL read or write queries with built-in security validation. Enables connection to SQLite databases to inspect table schemas and execute SQL read or write queries directly from the file system.

de en es ja ko ru zh

dbmcp

by haymon-ai

Overview Schema Related Servers Score Discussions

Rust

Hybrid

Database MCP

Release License: MIT Docs

A single-binary MCP server for SQL databases. Connect your AI assistant to MySQL/MariaDB, PostgreSQL, or SQLite with zero runtime dependencies.

Website · Documentation · Releases

demo

Features ✨

Multi-database — MySQL/MariaDB, PostgreSQL, and SQLite from one binary
MCP tools — schema discovery (listDatabases, listTables, listViews, listTriggers, listFunctions, listProcedures, listMaterializedViews), data access (readQuery, writeQuery), DDL (createDatabase, dropDatabase, dropTable), and explainQuery. Read-only mode hides the write tools (writeQuery, createDatabase, dropDatabase, dropTable). See MCP Tools for per-backend availability.
Single binary — ~7 MB, no Python/Node/Docker needed
Multiple transports — stdio (for Claude Desktop, Cursor) and HTTP (for remote/multi-client)
Two-layer config — CLI flags > environment variables, with sensible defaults per backend

Related MCP server: CentralMind/Gateway

Install 📦

macOS, Linux, WSL:

curl -fsSL https://dbmcp.haymon.ai/install.sh | bash

Windows PowerShell:

irm https://dbmcp.haymon.ai/install.ps1 | iex

Windows CMD:

curl -fsSL https://dbmcp.haymon.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

See the installation docs for Docker, Cargo, and other methods.

Quick Start 🚀

Using `.mcp.json` (recommended)

Add a .mcp.json file to your project root. MCP clients read this file and configure the server automatically.

Stdio transport — the client starts and manages the server process:

{
  "mcpServers": {
    "dbmcp": {
      "command": "dbmcp",
      "args": ["stdio"],
      "env": {
        "DB_BACKEND": "mysql",
        "DB_HOST": "127.0.0.1",
        "DB_PORT": "3306",
        "DB_USER": "root",
        "DB_PASSWORD": "secret",
        "DB_NAME": "mydb"
      }
    }
  }
}

HTTP transport — you start the server yourself, the client connects to it:

# Start the server first
dbmcp http --db-backend mysql --db-user root --db-name mydb --port 9001

{
  "mcpServers": {
    "dbmcp": {
      "type": "http",
      "url": "http://127.0.0.1:9001/mcp"
    }
  }
}

Note: The "type": "http" field is required for HTTP transport. Without it, clients like Claude Code will reject the config.

Using CLI flags

# MySQL/MariaDB
dbmcp stdio --db-backend mysql --db-host localhost --db-user root --db-name mydb

# PostgreSQL
dbmcp stdio --db-backend postgres --db-host localhost --db-user postgres --db-name mydb

# SQLite
dbmcp stdio --db-backend sqlite --db-name ./data.db

# HTTP transport
dbmcp http --db-backend mysql --db-user root --db-name mydb --host 0.0.0.0 --port 9001

Using environment variables

DB_BACKEND=mysql DB_USER=root DB_NAME=mydb dbmcp stdio

Configuration ⚙️

Configuration is loaded with clear precedence:

CLI flags > environment variables > defaults

Environment variables are typically set by your MCP client (via env or envFile in the server config).

Subcommands

Subcommand	Description
`stdio`	Run in stdio mode
`http`	Run in HTTP/SSE mode
`version`	Print version information and exit

A subcommand is required — running dbmcp with no subcommand prints usage help and exits with a non-zero status.

Database Options (shared across subcommands)

Flag	Env Variable	Default	Description
`--db-backend`	`DB_BACKEND`	(required)	`mysql`, `mariadb`, `postgres`, or `sqlite`
`--db-host`	`DB_HOST`	`localhost`	Database host
`--db-port`	`DB_PORT`	backend default	`3306` (MySQL/MariaDB), `5432` (PostgreSQL)
`--db-user`	`DB_USER`	backend default	`root` (MySQL/MariaDB), `postgres` (PostgreSQL)
`--db-password`	`DB_PASSWORD`	(empty)	Database password
`--db-name`	`DB_NAME`	(empty)	Database name or SQLite file path
`--db-charset`	`DB_CHARSET`		Character set (MySQL/MariaDB only)

SSL/TLS Options

Flag	Env Variable	Default	Description
`--db-ssl`	`DB_SSL`	`false`	Enable SSL
`--db-ssl-ca`	`DB_SSL_CA`		CA certificate path
`--db-ssl-cert`	`DB_SSL_CERT`		Client certificate path
`--db-ssl-key`	`DB_SSL_KEY`		Client key path
`--db-ssl-verify-cert`	`DB_SSL_VERIFY_CERT`	`true`	Verify server certificate

Server Options

Flag	Env Variable	Default	Description
`--db-read-only`	`DB_READ_ONLY`	`true`	Block write queries
`--db-max-pool-size`	`DB_MAX_POOL_SIZE`	`5`	Max connection pool size (min: 1)
`--db-connection-timeout`	`DB_CONNECTION_TIMEOUT`	(unset)	Connection timeout in seconds (min: 1)
`--db-query-timeout`	`DB_QUERY_TIMEOUT`	`30`	Query execution timeout in seconds
`--db-page-size`	`DB_PAGE_SIZE`	`100`	Max items per paginated tool response (range 1–500)

Logging Options

Flag	Env Variable	Default	Description
`--log-level`	`LOG_LEVEL`	`info`	Log level (trace/debug/info/warn/error)

HTTP-only Options (only available with `http` subcommand)

Flag	Default	Description
`--host`	`127.0.0.1`	Bind host
`--port`	`9001`	Bind port
`--allowed-origins`	localhost variants	Allowed browser origins (comma-separated). Drives both CORS preflight and server-side Origin rejection.
`--allowed-hosts`	`localhost,127.0.0.1,::1`	Trusted Host headers (comma-separated). Enforced server-side; HTTP/2 `:authority` is honored.

MCP Tools 🧩

listDatabases

Lists accessible databases, paginated via cursor / nextCursor. See Cursor Pagination for iteration details. Not available for SQLite.

listTables

Lists tables in a database, paginated via cursor / nextCursor. See Cursor Pagination for iteration details.

Parameters: database (defaults to the active database; SQLite has no database parameter), cursor, search, detailed.

search is an optional case-insensitive LIKE/ILIKE pattern with % (any sequence) and _ (single character) as wildcards — pass users% to match names beginning with users, or %order% for substring matching. A bare word with no wildcards matches only an exact table name.

detailed (default false) switches the response shape:

Brief (default) — tables is a sorted JSON array of bare table-name strings.
Detailed (detailed: true) — tables is a JSON object keyed by table name; each value carries the table's schema, kind, owner, comment, columns[], constraints[], indexes[], and triggers[]. One call returns both the table list and the per-table metadata.

listViews

Lists views in a database, paginated via cursor / nextCursor. Available on MySQL/MariaDB, PostgreSQL (public schema), and SQLite. Parameters: database (defaults to the active database; SQLite has no database parameter), cursor, search, detailed. SQLite returns the brief shape only — search and detailed are not accepted there.

search is an optional case-insensitive LIKE/ILIKE pattern with % (any sequence) and _ (single character) as wildcards. The search value must remain identical across paginated calls for cursor continuity.

detailed (default false) switches the response shape:

Brief (default) — views is a sorted JSON array of bare view-name strings. View names are unique per schema, so no duplicates appear.
Detailed (detailed: true) — views is a JSON object keyed by bare view name; each value carries the per-backend metadata payload. PostgreSQL exposes schema, owner, description, definition. MySQL/MariaDB exposes schema, definer, security, checkOption, updatable, characterSetClient, collationConnection, definition. See the listViews reference for source columns, enumerated value sets, and intentional omissions per backend.

See Cursor Pagination for iteration details.

listTriggers

Lists user-defined triggers on tables, paginated via cursor / nextCursor. Internal constraint and foreign-key triggers are excluded. Available on MySQL/MariaDB, PostgreSQL (public schema), and SQLite. Parameters: database (defaults to the active database; SQLite has no database parameter), cursor, search, detailed.

detailed (default false) switches the response shape:

Brief (default) — triggers is a sorted JSON array of bare trigger-name strings.
Detailed (detailed: true) — triggers is a JSON object keyed by trigger name; each value carries the per-backend metadata payload (timing, events, definition, and backend-specific extras like PostgreSQL status/functionName or MySQL/MariaDB session-context fields). See the listTriggers reference for the full per-backend field list.

See Cursor Pagination for iteration details.

listFunctions

Lists user-defined SQL functions, paginated via cursor / nextCursor. PostgreSQL excludes aggregates, window functions, and procedures; MySQL/MariaDB excludes loadable UDFs (mysql.func). Available on MySQL/MariaDB and PostgreSQL (public schema). Not available for SQLite. Parameters: database (defaults to the active database), cursor, search, detailed.

detailed (default false) switches the response shape:

Brief (default) — functions is a sorted JSON array of bare function-name strings. PostgreSQL overloads appear once per overload (duplicate name strings are expected).
Detailed (detailed: true) — functions is a JSON object keyed by function signature; each value carries the per-backend metadata payload (language, arguments, return type, definition, and backend-specific extras such as PostgreSQL volatility/strict/parallelSafety or MySQL/MariaDB session-context fields). PostgreSQL keys are name(arguments) (overloads disambiguate); MySQL/MariaDB keys are bare names (no overloading). See the listFunctions reference for the full per-backend field list.

See Cursor Pagination for iteration details.

listProcedures

Lists user-defined stored procedures, paginated via cursor / nextCursor. Available on MySQL/MariaDB and PostgreSQL (public schema, PostgreSQL 11+). Not available for SQLite. Parameters: database (defaults to the active database), cursor, search, detailed.

detailed (default false) switches the response shape:

Brief (default) — procedures is a sorted JSON array of bare procedure-name strings. PostgreSQL overloads appear once per overload (duplicate name strings are expected).
Detailed (detailed: true) — procedures is a JSON object keyed by procedure signature; each value carries the per-backend metadata payload (language, arguments, security, definition, and backend-specific extras such as PostgreSQL owner or MySQL/MariaDB deterministic/sqlDataAccess/session-context fields). PostgreSQL keys are name(arguments) (overloads disambiguate; zero-arg procedures key as name()); MySQL/MariaDB keys are bare names (no overloading). See the listProcedures reference for the full per-backend field list.

See Cursor Pagination for iteration details.

listMaterializedViews

Lists materialized views in the public schema, paginated via cursor / nextCursor. PostgreSQL only — not available for MySQL/MariaDB or SQLite. Parameters: database (defaults to the active database), cursor, search, detailed.

search is an optional case-insensitive ILIKE pattern with % (any sequence) and _ (single character) as wildcards. SQL meta-characters (', ;, --) are bound as parameter values and never interpolated. The search value must remain identical across paginated calls for cursor continuity.

detailed (default false) switches the response shape:

Brief (default) — materializedViews is a sorted JSON array of bare matview-name strings. Matview names are unique per schema, so no duplicates appear.
Detailed (detailed: true) — materializedViews is a JSON object keyed by bare matview name; each value carries schema, owner, description (or null when no COMMENT ON MATERIALIZED VIEW), definition (the SELECT body verbatim from pg_matviews.definition), populated (false for matviews created WITH NO DATA and never refreshed), and indexed (true when at least one index exists; REFRESH MATERIALIZED VIEW CONCURRENTLY additionally requires a unique index). Detailed mode deliberately omits column metadata, tablespace, storage parameters, and unique-index detection — recoverable via definition, listTables(detailed=true), or readQuery against pg_indexes. See the listMaterializedViews reference for source columns and operational semantics.

See Cursor Pagination for iteration details.

readQuery

Executes a read-only SQL query (SELECT, SHOW, DESCRIBE, USE, EXPLAIN). Always enforces SQL validation as defence-in-depth. Parameters: query, database, cursor. SELECT results paginate via cursor / nextCursor; SHOW, DESCRIBE, USE, and EXPLAIN return a single page and ignore cursor. See Cursor Pagination for iteration details.

writeQuery

Executes a write SQL query (INSERT, UPDATE, DELETE, CREATE, ALTER, DROP). Only available when read-only mode is disabled. Parameters: query, database.

createDatabase

Creates a database if it doesn't exist. Only available when read-only mode is disabled. Not available for SQLite. Parameters: database.

dropDatabase

Drops an existing database. Refuses to drop the currently connected database. Only available when read-only mode is disabled. Not available for SQLite. Parameters: database.

dropTable

Drops a table from a database. If the table has foreign key dependents, the database error is surfaced to the user. On PostgreSQL, a cascade parameter is available to force the drop with CASCADE. Only available when read-only mode is disabled. Parameters: database, table, cascade (PostgreSQL only).

explainQuery

Returns the execution plan for a SQL query. Supports an optional analyze parameter for actual execution statistics (PostgreSQL and MySQL/MariaDB). In read-only mode, EXPLAIN ANALYZE is only allowed for read-only statements since it actually executes the query. SQLite uses EXPLAIN QUERY PLAN (no ANALYZE support). Always available regardless of read-only mode. Parameters: query, database, analyze (PostgreSQL/MySQL only).

Security 🔒

Read-only mode (default) — write tools hidden from AI assistant; readQuery enforces AST-based SQL validation
Single-statement enforcement — multi-statement injection blocked at parse level
Dangerous function blocking — LOAD_FILE(), INTO OUTFILE, INTO DUMPFILE detected in the AST
Identifier validation — database/table names validated against control characters and empty strings
Origin + Host allowlists — server-side rejection (403) plus CORS preflight; configurable for HTTP transport
SSL/TLS — configured via individual DB_SSL_* variables
PII redaction (opt-in, off by default) — when enabled, query tool output passes through a regex-based redactor that rewrites detected PII spans across 46 built-in entity types spanning seven categories: personal (email), financial (cards, IBAN, UK bank accounts, sort and US ABA routing codes, CVV), government IDs (SSN, ITIN, EIN, UK/US passports, NHS, NINO, SIN, VAT), contact (phone), network (IP, URL, MAC), digital identity (API keys, JWTs, PEM private keys, password hashes), and crypto wallets. Toggle: --pii / PII_ENABLE. Operator: --pii-operator / PII_OPERATOR — one of replace (default, entity-aware placeholders like <EMAIL_ADDRESS>), mask (length-preserving *), redact (drop), hash (SHA-256 hex). Optional subset via --pii-categories / PII_CATEGORIES (comma-separated, e.g. financial,government); unset enables all built-ins. Scope: query tool output payloads only. See PII configuration for the full surface.
ML/NER redaction (opt-in at runtime, off by default) — adds PERSON, LOCATION, ORGANIZATION, NATIONALITY_RELIGION_POLITICS, and FACILITY detection that regex cannot catch, enabled via the --pii-ner / PII_NER_ENABLE toggle plus a user-supplied model directory. Which entities are produced depends on the model's labels (CoNLL models give person/location/organization; OntoNotes-class models add NRP and facility). Inference uses ONNX Runtime (model directory holds config.json, tokenizer.json, model.onnx; recommended: the MIT-licensed dslim/bert-base-NER exported to ONNX, int8-quantized for speed). Fail-closed: a model that cannot load aborts startup and an inference error fails the request — never a silent fallback. Respects --pii-categories. English for v1.
Credential redaction — database password is never shown in logs or debug output

Testing 🧪

# Unit tests
cargo test --workspace --lib --bins

# Integration tests (requires Docker)
./tests/run.sh

# Filter by engine
./tests/run.sh --filter mariadb
./tests/run.sh --filter mysql
./tests/run.sh --filter postgres
./tests/run.sh --filter sqlite

# With MCP Inspector
npx @modelcontextprotocol/inspector ./target/release/dbmcp stdio

# HTTP mode testing
curl -X POST http://localhost:9001/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0.1"}}}'

Project Structure 🗂️

This is a Cargo workspace with the following crates:

Crate	Path	Description
`dbmcp`	`.` (root)	Main binary — CLI, transports, database backends
`dbmcp-sql`	`crates/backend/`	Shared error types, validation, and identifier utilities
`dbmcp-config`	`crates/config/`	Configuration structs and CLI argument mapping
`dbmcp-server`	`crates/server/`	Shared MCP tool implementations and server info
`dbmcp-mysql`	`crates/mysql/`	MySQL/MariaDB backend handler and operations
`dbmcp-postgres`	`crates/postgres/`	PostgreSQL backend handler and operations
`dbmcp-sqlite`	`crates/sqlite/`	SQLite backend handler and operations
`sqlx-json`	`crates/sqlx-json/`	Type-safe row-to-JSON conversion for sqlx (`RowExt` trait)

Development 🧰

cargo build              # Development build
cargo build --release    # Release build (~7 MB)
cargo test               # Run tests
cargo clippy --workspace --tests -- -D warnings  # Lint
cargo fmt                # Format
cargo doc --no-deps      # Build documentation

License 📄

This project is licensed under the MIT License — see the LICENSE file for details.

Available Tools

6 tools

explainQueryExplain QueryA

Read-onlyIdempotent

Return the execution plan for a SQL query to diagnose performance. Use this tool instead of running EXPLAIN directly through readQuery — it provides structured output via EXPLAIN QUERY PLAN.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The SQL query to explain.

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes	Result rows, each a JSON object keyed by a column name.

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds value by specifying the output format (JSON array of EXPLAIN QUERY PLAN rows) and explaining how it works under the hood. No contradictions.

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 efficiently structured with clear sections (main purpose, usecase, when_not_to_use, examples, what_it_returns), no wasted words, and key information front-loaded.

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 simple tool (1 param, output schema present, annotations complete), the description fully covers purpose, usage, return format, and context for selecting among siblings.

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 100% for the single 'query' parameter. The description's example section reinforces correct parameter usage (e.g., 'explainQuery(query="SELECT ...")'), adding context beyond the schema description.

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 clearly states the tool returns execution plans to diagnose performance, with a specific verb ('explain') and resource ('SQL query'). It distinguishes from siblings like readQuery by noting it provides structured output via EXPLAIN QUERY PLAN.

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?

The 'usecase' and 'when_not_to_use' sections explicitly state when to use (slow queries, understanding scans/indexes, index decisions) and when not (running queries via readQuery/writeQuery, checking schemas via getTableSchema), with examples.

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

getTableSchemaGet Table SchemaA

Read-onlyIdempotent

Get column definitions and foreign key relationships for a table. Requires table — call listTables first.

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes	The table name to inspect. Use `listTables` first to see available tables.

Output Schema

ParametersJSON Schema

Name	Required	Description
`columns`	Yes	Column definitions keyed by column name.
`table`	Yes	Name of the inspected table.

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds value by detailing what the tool returns (column types, nullable, keys, defaults, foreign keys) and the exact structure, which is beyond the annotations.

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 well-structured with separate sections (usecase, examples, what_it_returns) and is front-loaded with the main purpose. Every sentence is informative and no redundant content exists.

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 output schema exists (as indicated by context signals), the description covers all necessary aspects: purpose, usage prerequisites, parameter example, and return structure. It is complete and leaves no ambiguity.

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?

The sole parameter 'table' is fully described in the input schema with coverage at 100%. The description reinforces the prerequisite 'use listTables first' and provides concrete examples of usage, adding more context than the schema alone.

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 clearly states 'Get column definitions and foreign key relationships for a table', using a specific verb and resource. It distinguishes itself from sibling tools like listTables (which lists tables) and explainQuery, making its purpose unambiguous.

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 guidance is provided: 'ALWAYS call this before writing queries' and 'Requires `table` — call `listTables` first.' The <usecase> section and examples further clarify when and how to use the tool, including what to do before invoking it.

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

listTablesList TablesA

Read-onlyIdempotent

List all tables in the connected SQLite database. Use this tool to discover what tables are available before using other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`nextCursor`	No	Opaque cursor pointing to the next page. Absent when this is the final page.
`tables`	Yes	Sorted list of table names for this page.

TDQS

A4.7/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint, idempotentHint), the description adds that the result is a sorted JSON array of table names and describes pagination behavior with nextCursor. This is valuable context not captured by annotations.

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 well-structured with front-loaded main sentence and separate sections for use cases, examples, return value, and pagination. Every section adds value without unnecessary repetition.

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?

The description fully covers the tool's behavior for its simplicity: it lists tables, returns sorted array, and supports pagination. Given the presence of an output schema and no parameters, the description is complete.

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?

The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter semantics; it correctly omits parameter details. The baseline score for zero parameters is 4.

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 clearly states 'List all tables in the connected SQLite database.' The verb 'list' and resource 'tables' are specific. The examples and usage guidelines differentiate it from siblings like getTableSchema, making the purpose unambiguous.

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?

The description includes a <usecase> section explicitly stating when to call the tool (e.g., ALWAYS call this tool FIRST when exploring tables) and provides examples of correct and incorrect usage, demonstrating when to use alternatives like getTableSchema.

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

listTriggersList TriggersA

Read-onlyIdempotent

List all triggers in the connected SQLite database.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`nextCursor`	No	Opaque cursor pointing to the next page. Absent when this is the final page.
`triggers`	Yes	Sorted list of trigger names for this page.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already show readOnly, destructive, idempotent hints. Description adds pagination behavior and return format (sorted JSON array of trigger name strings), which adds value beyond annotations.

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?

The description is well-structured with sections, but somewhat verbose with usecase and examples. It is front-loaded with main purpose.

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 no parameters and output schema exists, description explains return format (sorted JSON array) and pagination. It covers purpose, usage, and output completely.

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?

No parameters are defined, so baseline is 4. The description does not need to add parameter info, and it doesn't attempt to.

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 clearly states 'List all triggers in the connected SQLite database.' It uses a specific verb and resource, and distinguishes from sibling tools like listTables and listViews.

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?

The usecase section explicitly lists when to use: investigating side-effects, auditing coverage, user asking. Examples include correct and incorrect uses, with alternative tool for getting trigger body.

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

listViewsList ViewsA

Read-onlyIdempotent

List all views in the connected SQLite database.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`nextCursor`	No	Opaque cursor pointing to the next page. Absent when this is the final page.
`views`	Yes	Sorted list of view names for this page.

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds pagination details and return format, providing complete behavioral picture without contradiction.

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?

Well-structured with clear sections (usecase, examples, what_it_returns, pagination). Core statement is front-loaded, each sentence provides value, no redundancy.

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 simple no-parameter tool with output schema, description covers return format (sorted JSON array of view name strings) and pagination, making it fully complete.

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?

Tool has zero parameters and schema coverage is 100%. With no parameters, the description doesn't need to add parameter info; baseline 4 is appropriate.

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 clearly states 'List all views' with specific verb and resource. Use cases and examples distinguish it from siblings like getTableSchema and listTables, making purpose unambiguous.

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?

Explicitly provides when to use (exploring views, verifying existence) and when not to (see columns → getTableSchema). Examples with checkmarks and crosses give clear guidance.

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

readQueryRead QueryA

Read-onlyIdempotent

Execute a read-only SQL query. Allowed statements: SELECT, EXPLAIN.

ParametersJSON Schema

Name	Required	Description	Default
`cursor`	No	Opaque pagination cursor. Omit (or pass `null`) for the first page. On subsequent calls, pass the `nextCursor` returned by the previous response verbatim. Cursors are opaque — do not parse, modify, or persist. Ignored for `EXPLAIN` statements.
`query`	Yes	The SQL query to execute.

Output Schema

ParametersJSON Schema

Name	Required	Description
`nextCursor`	No	Opaque cursor pointing to the next page. Absent when this is the final page, when the result fits in one page, or when the statement is a non-`SELECT` kind that does not paginate (e.g. `SHOW`, `EXPLAIN`).
`rows`	Yes	Result rows, each a JSON object keyed by a column name.

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying allowed statements, describing the return format (<what_it_returns>), explaining pagination behavior (<pagination>) including that EXPLAIN ignores cursor, and showing examples. No contradiction with annotations.

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 well-structured with clear sections using XML-like tags (usecase, when_not_to_use, examples, what_it_returns, pagination). It is concise but comprehensive, with no redundant information. Every sentence adds value.

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 complexity of the tool (SQL queries with pagination), the description covers all necessary aspects: allowed statements, usage guidance, examples, return structure, and pagination details. The presence of an output schema further reduces the need to describe return values in depth.

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 100% with both cursor and query described in the input schema. The description adds extra context: the pagination section explains cursor usage in detail, and examples illustrate valid queries. While the schema already provides good baseline, the description complements it effectively.

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 clearly states 'Execute a read-only SQL query. Allowed statements: SELECT, EXPLAIN.' It uses a specific verb and resource, and distinguishes from siblings by referencing writeQuery, explainQuery, listTables, and getTableSchema in the when_not_to_use section.

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?

The description includes explicit <usecase> and <when_not_to_use> sections listing when to use the tool and when not to, with clear references to sibling tools. It also provides examples of correct and incorrect usage, making it easy for an agent to decide when to invoke this tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.13.2May 29, 2026
- AddedexplainQuery
- AddedgetTableSchema
- AddedlistTables
- AddedlistTriggers
- AddedlistViews
- AddedreadQuery
6 tool updatesv0.12.0May 22, 2026
- RemovedexplainQuery
- RemovedgetTableSchema
- RemovedlistTables
- RemovedlistTriggers
- RemovedlistViews
- RemovedreadQuery
6 tool updatesv0.11.0May 11, 2026
- AddedexplainQuery
- AddedgetTableSchema
- AddedlistTables
- AddedlistTriggers
- AddedlistViews
- AddedreadQuery
6 tool updatesv0.10.4May 11, 2026
- RemovedexplainQuery
- RemovedgetTableSchema
- RemovedlistTables
- RemovedlistTriggers
- RemovedlistViews
- RemovedreadQuery
6 tool updatesv0.8.0Apr 29, 2026
- First observedexplainQuery
- First observedgetTableSchema
- First observedlistTables
- First observedlistTriggers
- First observedlistViews
- First observedreadQuery

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a distinct and clearly defined purpose: listing different database objects (tables, views, triggers), retrieving schema details, executing read queries, and explaining query plans. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent camelCase verb_noun pattern (listTables, getTableSchema, readQuery, explainQuery). The naming is predictable and intuitive.

Tool Count5/5

With 6 tools, the server covers core database introspection and query operations without being overly large or too sparse. The count is appropriate for its domain.

Completeness2/5

The tool surface lacks a writeQuery tool for data modifications (INSERT, UPDATE, DELETE), which is explicitly referenced in readQuery's guidance. Additionally, DDL operations are absent, making the set incomplete for full database management.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

remote-mcp-serverOAuth
io.coupler
Coupler.io remote MCP server
Data Platforms App Automation Developer Tools
2
Second server!
com.fenetresurciel.verylongmcp
A non functional MCP server (yet)
Developer Tools
2
mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233
mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247

Related MCP Servers

DBHub
Databases Developer Tools Code Execution
bytebase
A
license
Not graded
quality
A
maintenance
Universal database MCP server connecting to MySQL, PostgreSQL, SQLite, DuckDB and etc.
Updated 5 days ago (2026-09-02 03:06 UTC)
25
3,456
MIT
CentralMind/Gateway
Databases RAG Systems Developer Tools
centralmind
A
license
Not graded
quality
C
maintenance
MCP-Server from your Database optimized for LLMs and AI-Agents. Supports PostgreSQL, MySQL, ClickHouse, Snowflake, MSSQL, BigQuery, Oracle Database, SQLite, ElasticSearch, DuckDB
Updated a year ago (2025-07-18 16:15 UTC)
547
Apache 2.0
MCP Toolbox for Databases
Databases Developer Tools
googleapis
A
license
Not graded
quality
A
maintenance
Open source MCP server specializing in easy, fast, and secure tools for Databases.
Updated a day ago (2026-09-05 20:12 UTC)
16,318
Apache 2.0
mcp-server-sqlite
Databases Developer Tools
ofershap
A
license
A
quality
D
maintenance
MCP server for SQLite — query databases, inspect schemas, explain queries, and export data from your IDE.
Updated 6 months ago (2026-03-10 09:22 UTC)
5
188
3
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/haymon-ai/dbmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Database MCP

Features ✨

Install 📦

Quick Start 🚀

Using .mcp.json (recommended)

Using CLI flags

Using environment variables

Configuration ⚙️

Subcommands

Database Options (shared across subcommands)

SSL/TLS Options

Server Options

Logging Options

HTTP-only Options (only available with http subcommand)

MCP Tools 🧩

listDatabases

listTables

listViews

listTriggers

listFunctions

listProcedures

listMaterializedViews

readQuery

writeQuery

createDatabase

dropDatabase

dropTable

explainQuery

Security 🔒

Testing 🧪

Project Structure 🗂️

Development 🧰

License 📄

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

Using `.mcp.json` (recommended)

HTTP-only Options (only available with `http` subcommand)