Which integrations are available for this server?

Provides a read-only interface to PostgreSQL databases, allowing schema exploration, table description, DDL retrieval, index and relationship inspection, and safe read-only SQL queries.

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@db-mcp show me the tables in the public schema" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

db-mcp

by eklemen

Overview Schema Related Servers Score Discussions

TypeScript

Remote

db-mcp — Read-Only Database MCP Server

A Model Context Protocol server that lets AI assistants safely explore a PostgreSQL database — schema, tables, columns, relationships, indexes, constraints, DDL, and sample data — without ever modifying it.

Safety model

Read-only is enforced at three independent layers, so a failure in any one layer is still caught by the others:

Least-privilege database role. You connect with a role that only has CONNECT / USAGE / SELECT. The database itself rejects anything else.
Read-only transaction. Every query runs inside BEGIN TRANSACTION READ ONLY on a session forced to default_transaction_read_only = on with a statement_timeout. The query is always rolled back.
Application-level validation. Arbitrary SQL (the run_readonly_query tool) is parsed with libpg-query — the real PostgreSQL parser compiled to wasm — and rejected unless it is a single read-only statement. This catches multi-statement input, DDL/DML, EXPLAIN ANALYZE, SELECT INTO, and data-modifying CTEs (WITH x AS (INSERT ... RETURNING ...) SELECT ...).

Additional guards: a maximum query length, a hard row cap on every result, a sample-row cap (default 50), and secrets are never logged (config is redacted before any diagnostic output).

Related MCP server: postgres-mcp-readonly

Tools

Tool	Description
`list_databases`	Databases the read-only role can connect to.
`list_schemas`	Schemas visible to the role (system schemas excluded).
`list_tables`	Tables/views in a schema: type, row estimate, comment.
`describe_table`	Columns, PK, FKs, unique/check constraints, indexes.
`get_table_ddl`	Reconstructed `CREATE TABLE` DDL (+ indexes).
`get_relationships`	Foreign keys, referenced tables, cardinality hint.
`get_indexes`	Index names, columns, order, uniqueness, type, predicate.
`sample_rows`	A small sample of rows (capped at 50).
`run_readonly_query`	Validated read-only SQL; returns columns, rows, timing.
`search_schema`	Search names + comments across tables/columns/constraints/indexes.

Requirements

Node.js >= 18.17
A reachable PostgreSQL database and a read-only role (see below).

Setup

npm install
npm run build

Create a least-privilege read-only role

Run as a superuser or the database owner:

CREATE ROLE readonly_user LOGIN PASSWORD 'CHANGE_ME';
GRANT CONNECT ON DATABASE your_db TO readonly_user;
GRANT USAGE ON SCHEMA public TO readonly_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly_user;
-- Optional extra safety:
ALTER ROLE readonly_user SET default_transaction_read_only = on;

Configure

Copy .env.example and fill in your connection. Configuration is read from the environment (no .env is loaded automatically — export the vars, or have your MCP client pass them in its env block).

Variable	Default	Purpose
`DATABASE_URL`	—	Full connection string (wins over `PG*`).
`PGHOST` / `PGPORT` / `PGDATABASE` / `PGUSER` / `PGPASSWORD`	—	Discrete connection settings.
`PGSSLMODE`	`disable`	`require`/`verify-*` enable TLS.
`DB_MCP_DRIVER`	`postgres`	Database driver.
`DB_MCP_MAX_ROWS`	`1000`	Hard cap for `run_readonly_query`.
`DB_MCP_SAMPLE_MAX_ROWS`	`50`	Hard cap for `sample_rows`.
`DB_MCP_STATEMENT_TIMEOUT_MS`	`5000`	Per-statement timeout.
`DB_MCP_MAX_QUERY_LENGTH`	`10000`	Reject longer queries.
`DB_MCP_DEFAULT_SCHEMA`	`public`	Schema used when omitted.

Running locally

export DATABASE_URL="postgres://readonly_user:***@localhost:5432/your_db"
npm start

The server speaks MCP over stdio. To poke at it interactively, use the MCP Inspector:

npx @modelcontextprotocol/inspector node dist/server.js

Connecting from Claude Code

Add an entry to your MCP config (e.g. .mcp.json in your project, or the global Claude Code config):

{
  "mcpServers": {
    "db-mcp": {
      "command": "node",
      "args": ["/absolute/path/to/db-mcp/dist/server.js"],
      "env": {
        "DATABASE_URL": "postgres://readonly_user:***@localhost:5432/your_db"
      }
    }
  }
}

Then ask Claude to, e.g., "list the tables in the public schema" or "show me the DDL for the orders table".

Tests

npm test

Tests are pure unit tests (no live database required): exhaustive SQL-validation cases (allowed reads vs. rejected mutations and bypass attempts), identifier quoting, DDL reconstruction, and config parsing/redaction.

Extending to other databases

Tools depend only on the DatabaseDriver interface (src/db/driver.ts). To add MySQL, SQLite, or Snowflake:

Implement DatabaseDriver for the new engine under src/db/<engine>/.
Register it in createDriver (src/db/factory.ts).
Provide an engine-appropriate read-only enforcement (read-only role + read-only session/transaction) and SQL validation.

Project layout

src/
  server.ts                 MCP server setup + stdio transport
  config.ts                 env parsing + secret redaction
  errors.ts                 typed error classes
  types.ts                  shared result types
  validation/
    validateReadOnly.ts     libpg-query-based read-only enforcement
  db/
    driver.ts               DatabaseDriver interface
    factory.ts              driver selection
    postgres/
      pool.ts               read-only pool, transactions, row-capped cursor
      identifiers.ts        safe identifier quoting
      introspection.ts      catalog/information_schema queries
      ddl.ts                CREATE TABLE reconstruction (pure)
      PostgresDriver.ts     DatabaseDriver implementation
  tools/                    one module per MCP tool + registry
tests/                      pure unit tests

Available Tools

10 tools

describe_tableA

Describe a table: columns (type, nullability, default, comment), primary key, foreign keys, unique constraints, check constraints, and indexes.

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes	Table or view name.
`schema`	No	Schema name. Defaults to the server's default schema.

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses output content but does not state that operation is read-only, permissions required, or error behavior if table missing. Adequate but not fully transparent.

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?

Single sentence covering all listed outputs. Concise but could benefit from structured list for clarity. No wasted words, but front-loading is minimal.

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

Completeness3/5

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

No output schema, so description should compensate. Lists outputs but lacks detail on structure (e.g., format of constraints, indexes). Moderately complete for a describe tool but could specify return format explicitly.

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 coverage is 100% and description does not add extra parameter meaning beyond schema. Baseline 3 given coverage; no added value for parameters themselves, only output 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?

Tool name 'describe_table' and description clearly state verb 'describe' and resource 'table'. Lists specific outputs (columns, primary key, foreign keys, etc.) which distinguishes it from siblings like get_indexes (only indexes) and get_relationships (only foreign keys).

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?

No explicit when-to-use or when-not-to-use guidance. Implies use for comprehensive table structure, but does not mention alternatives or exclude usage for simple tasks. Lacks context on when to prefer this over get_indexes or get_relationships.

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

get_indexesA

List indexes on a table: name, access method (btree/gin/gist/...), uniqueness, whether it backs the primary key, ordered columns with sort direction and NULLS ordering, and any partial-index predicate.

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes	Table name.
`schema`	No	Schema name. Defaults to the server's default schema.

TDQS

A3.9/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 transparently describes the tool as listing indexes (a read-only operation) and lists the exact fields returned. It does not disclose any side effects or permissions, but the read-only nature is clear.

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 a single sentence that is front-loaded with the core purpose and efficiently enumerates the returned attributes. It is concise but the enumeration could be slightly more structured.

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?

Given the tool's simplicity (2 parameters, no output schema), the description adequately covers what the tool does and what it returns. It lacks detail on the output format but is sufficient for an AI agent to understand its function.

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 coverage is 100%, so the description adds no additional meaning to the parameters beyond what the schema already provides. The description focuses on output, not input parameters.

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 lists indexes on a table and enumerates the specific details returned (name, access method, uniqueness, primary key backing, columns with sort direction, partial-index predicate). This distinguishes it from sibling tools like describe_table and get_relationships.

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?

The description explains what the tool does but does not provide guidance on when to use it versus alternatives like describe_table or get_relationships. No explicit when-not-to-use or prerequisite information is given.

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

get_relationshipsA

List foreign-key relationships with constraint names, referenced tables/columns, ON UPDATE/DELETE actions, and a cardinality hint (1:1 when the FK columns are uniquely constrained locally, otherwise many:1). Optionally filter by schema and/or table.

ParametersJSON Schema

Name	Required	Description	Default
`table`	No	Restrict to foreign keys defined on this table.
`schema`	No	Restrict to this schema. If omitted, scans all non-system schemas.

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the cardinality hint logic ('1:1 when FK columns are uniquely constrained locally') and the returned fields. It does not explicitly state read-only nature, but the action of listing relationships is indicative of a safe read operation.

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 two sentences, front-loading the main purpose and returned data in the first sentence, and filtering options in the second. No wasted words.

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?

Given no output schema, the description explicitly lists all returned fields (constraint names, referenced tables/columns, actions, cardinality hint). It mentions optional filters. It does not specify default behavior when no schema filter is applied, though that is covered in the schema description. Overall sufficiently complete for this tool's complexity.

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%, with clear descriptions for both parameters. The tool description adds a general note about optional filtering but does not provide additional meaning beyond what the schema already conveys. Baseline of 3 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?

Description starts with a clear verb ('List') and specific resource ('foreign-key relationships'). It enumerates the exact information returned (constraint names, referenced tables/columns, actions, cardinality hint) and distinguishes from sibling tools like 'describe_table' or 'get_indexes' by focusing solely on relationships.

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?

The description explains what the tool does but does not explicitly state when to use it versus alternatives. It mentions optional filtering by schema/table, implying typical use cases, but lacks direct comparisons to siblings like 'describe_table' or 'get_indexes'.

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

get_table_ddlA

Return the reconstructed CREATE TABLE DDL for a table (PostgreSQL has no SHOW CREATE TABLE, so this is the closest supported reconstruction from the catalog, including constraints and indexes).

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes	Table name.
`schema`	No	Schema name. Defaults to the server's default schema.

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses that the DDL is reconstructed from the catalog and includes constraints/indexes, which is helpful. However, it does not mention if the operation is read-only, any permissions needed, or potential performance implications, leaving some behavioral gaps.

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 a single concise sentence with a parenthetical that adds context. It is front-loaded with the main action, and every part is informative with no filler.

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

Completeness3/5

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

Given no output schema, the description could specify the return format (e.g., a string of SQL). It explains the reconstruction approach and includes constraints/indexes, but lacks details on output structure, error conditions, or example usage, leaving the agent somewhat uncertain about what to expect.

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 coverage is 100% and parameter descriptions in the schema are clear. The description adds no additional meaning to the parameters beyond what is in the schema, so baseline 3 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 the tool returns the reconstructed CREATE TABLE DDL, including constraints and indexes. It distinguishes itself from siblings like describe_table or get_indexes by focusing on DDL reconstruction, and the parenthetical context about PostgreSQL lacking SHOW CREATE TABLE adds specificity.

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?

The description implies use when DDL is needed, and notes it's the closest supported reconstruction due to PostgreSQL limitations. However, it does not explicitly guide when to use this vs alternatives like describe_table or get_indexes, nor does it mention when not to use it.

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

list_databasesA

List databases the read-only user can connect to, with owner and comment when available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/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 tool is read-only ('read-only user'), but does not elaborate on other behaviors like performance, sorting, or potential errors. This is adequate for a simple listing tool.

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 a single, concise sentence that front-loads the core purpose and additional details. Every word adds value, with 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 tool with no parameters and no output schema, the description is complete: it specifies what is listed (databases user can connect to) and what information is provided (owner and comment when available). No further context is needed.

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?

There are no parameters, so the description does not need to add parameter information. The baseline score of 4 applies as the schema coverage is 100% and no parameter explanation is needed.

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 verb 'List' and the resource 'databases', specifying the scope ('the read-only user can connect to') and additional information returned ('with owner and comment when available'). This distinguishes it from sibling tools like list_schemas and list_tables.

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?

No explicit guidance on when to use this tool versus alternatives, but the description implies it is for listing accessible databases. Since no parameters or conditions are given, the usage context is straightforward.

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

list_schemasA

List schemas (namespaces) the read-only user can access. Excludes system schemas (pg_*, information_schema).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations; description explicitly states exclusions of system schemas and read-only access, providing necessary behavioral context 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?

Two sentences, front-loaded with action, no wasted words.

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 zero-parameter, no-output-schema tool, description is complete. Explains scope and exclusions sufficiently.

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; description adds meaning by explaining what schemas are included (user-accessible, excluding system). Baseline for zero params 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?

Clearly states it lists schemas accessible by read-only user, excludes system schemas. Distinguishes from sibling tools like list_databases and list_tables.

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?

Implicitly clear when to use: to see accessible schemas. No explicit when-not or alternatives, but context makes it obvious.

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

list_tablesA

List tables and views in a schema. Returns name, type (table/view/materialized view/foreign table), a planner row estimate when available, and any comment. Defaults to the configured default schema.

ParametersJSON Schema

Name	Required	Description	Default
`schema`	No	Schema to list tables from. Defaults to the server's default schema.

TDQS

A4/5.0

Behavior4/5

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

No annotations present, so description carries full burden. Discloses what is returned (including row estimate when available) and default schema. Could mention performance implications for large schemas, but adequate.

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?

Two concise sentences covering purpose, returned fields, and default behavior. No extraneous information.

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 one optional parameter and no output schema, description covers essential behavior. Could mention ordering or pagination if applicable, but not necessary for clarity.

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?

Input schema has 100% coverage with a clear parameter description. Description adds minimal extra value beyond schema (only reaffirms default). Baseline 3 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?

Description clearly states the tool lists tables and views in a schema, specifying returned fields (name, type, row estimate, comment) and default schema behavior. Differentiates from siblings like list_schemas and describe_table.

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?

Does not explicitly state when to use vs alternatives, but usage is implied. Could better guide agent by mentioning when to use describe_table for specific tables or search_schema for searching.

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

run_readonly_queryA

Execute a single read-only SQL query (SELECT / EXPLAIN-without-ANALYZE / SHOW). The query is validated with a real PostgreSQL parser and rejected if it contains any write, DDL, data-modifying CTE, multiple statements, or other side effect. Results are capped at the server row maximum. Returns columns, rows, row count, execution time, and a truncation flag.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The read-only SQL query to execute.
`limit`	No	Maximum rows to return. Capped at the server row maximum.

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description fully covers behavior: query validation, rejection of side effects, result capping, and return fields (columns, rows, count, time, truncation). 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?

Two sentences, front-loaded with the core action, followed by necessary detail. Every sentence adds value without 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?

Despite no output schema, the description enumerates return fields. It covers all user needs for a read-only query tool: allowed queries, validation behavior, result limits, and output structure.

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 coverage is 100%, baseline 3. The description repeats the schema's explanation for limit but adds context about validation for the sql parameter. It does not significantly enhance understanding beyond the schema.

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 single read-only SQL query' and specifies allowed types: SELECT, EXPLAIN-without-ANALYZE, SHOW. This distinguishes it from sibling tools like describe_table or list_tables, which are specific operations.

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 description provides explicit validation rules and rejection conditions, but does not explicitly contrast with sibling tools or state when to prefer this tool over them. The context is implied but not spelled out.

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

sample_rowsA

Return a small sample of rows from a table. The limit is capped at the server's hard maximum (default 50) regardless of the requested value.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Number of rows to return. Capped at the server sample maximum.
`table`	Yes	Table name.
`schema`	No	Schema name. Defaults to the server's default schema.

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the burden of disclosing behavior. It explicitly states that the limit is capped at a server maximum (default 50), which is important for the agent to know. It does not detail authentication or side effects, but for a read-only sampling tool, this is sufficient.

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?

Two sentences, front-loaded with the purpose, followed by a behavioral detail. No unnecessary words; 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?

For a simple tool with 3 parameters and no output schema, the description is complete. It covers what the tool does, the key behavior (limit cap), and default schema. No critical information 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 100%, so parameters are already documented. The description adds the default value (50) for the limit parameter, which is helpful but not extensive. Baseline is 3, and the added value is marginal.

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 a sample of rows from a table, using a specific verb and resource. It differentiates from sibling tools like list_tables (listing tables) and describe_table (schema info), which serve different purposes.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it's suitable for quick previews or that run_readonly_query might be better for custom queries. The only directive is about the limit cap, not usage context.

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

search_schemaA

Search across the schema for a term (case-insensitive substring). Matches table names, column names, table/column comments, constraint names, and index names. Optionally restrict to a single schema.

ParametersJSON Schema

Name	Required	Description	Default
`term`	Yes	Substring to search for (case-insensitive).
`schema`	No	Restrict the search to this schema. If omitted, searches all non-system schemas.

TDQS

A4/5.0

Behavior3/5

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

Annotations are absent, so the description carries the full burden. It discloses case-insensitive substring matching and the scope of search (non-system schemas by default). However, it does not mention result ordering, pagination, or limitations like maximum term length or performance impact.

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 two concise sentences. The first sentence states the core action and case-insensitivity, the second lists match targets and optional restriction. Every part earns its place, with no redundancy.

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 simple 2-parameter tool with no output schema, the description covers the search functionality well. It could optionally mention that results include the object type or location, but overall it is sufficiently complete for an agent to understand the tool's behavior.

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?

While schema coverage is 100% with descriptions for both parameters, the description adds value by explaining what the term searches across (table names, column names, etc.), which is not in the schema. This enriches the meaning beyond the parameter descriptions 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 the verb 'search' and the resource 'schema', and specifies what is matched (table names, column names, comments, constraints, indexes). It distinguishes itself from sibling tools like list_tables or describe_table by focusing on a broad search across schema metadata.

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?

The description implies usage (searching for a term across schema objects) but lacks explicit guidance on when to use it versus alternatives or when not to use it. No exclusions or context-aware recommendations are provided.

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

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: describing table structure, fetching indexes, listing foreign keys, retrieving DDL, enumerating databases/schemas/tables, running queries, sampling rows, and searching schema metadata. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case (e.g., describe_table, list_schemas, run_readonly_query). The verbs accurately describe the action (describe, get, list, run, sample, search), and there are no mixed naming conventions.

Tool Count5/5

With 10 tools, the server is well-scoped for database introspection and read-only queries. Each tool addresses a distinct need without redundancy or excessive granularity, fitting the typical range of 3-15 tools for a focused domain.

Completeness4/5

The tool set covers core CRUD-like operations for database metadata (create via DDL retrieval, read via descriptions and queries, and listing). Minor gaps exist, such as missing explicit tools for table size estimation or listing extensions, but most common exploration workflows are supported.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

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

data
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2
mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247
PGAuditor
com.mcpgatepro
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Databases Monitoring Observability
1
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2

Related MCP Servers

mcp-postgres
Databases Developer Tools
gbfeliped
A
license
Not graded
quality
C
maintenance
Read-only PostgreSQL MCP server that enables running SELECT queries, listing tables and schemas, and describing columns, with built-in protection against writes and malicious SQL attacks.
Updated 3 months ago (2026-06-18 14:32 UTC)
751
MIT
postgres-mcp-readonly
Databases Developer Tools
mahin1995
A
license
A
quality
D
maintenance
A secure, read-only PostgreSQL MCP server that provides safe database introspection and querying capabilities.
Updated 4 months ago (2026-05-04 16:20 UTC)
14
15
MIT
PostgreSQL MCP
Databases Developer Tools
vallaksa
A
license
Not graded
quality
B
maintenance
Read-only MCP server for PostgreSQL, enabling schema discovery, table metadata, and safe SELECT queries via READ ONLY transactions.
Updated 2 months ago (2026-07-10 05:40 UTC)
27
MIT
slcg
Databases Developer Tools
aadhyathmik
A
license
Not graded
quality
C
maintenance
Provides a read-only PostgreSQL MCP server with schema introspection. Enforces least-privilege database roles to prevent any writes, even from malicious SQL.
Updated a month ago (2026-08-05 06:44 UTC)
MIT

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/eklemen/db-mcp'

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