# ai.haymon/dbmcp (oci · ghcr.io/haymon-ai/dbmcp)

Database MCP server for MySQL, MariaDB, PostgreSQL & SQLite with PII redaction and write-prevention

- Trust score: 40/100 (low)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-22

## Components

- oci · `ghcr.io/haymon-ai/dbmcp`: 40/100 (this document), [markdown](https://verifymcp.io/servers/ai-haymon-dbmcp/ghcr-io-haymon-ai-dbmcp.md), [page](https://verifymcp.io/servers/ai-haymon-dbmcp/ghcr-io-haymon-ai-dbmcp)

## Channel facts

- Registry: `oci`
- Package: `ghcr.io/haymon-ai/dbmcp`
- Version: `0.15.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-22.

- **Supply Chain Security**: 0/100
  - No malware scan is available for this kind of package: the supply-chain vendors we use do not cover it. This is a permanent gap in our coverage, not a finding about the package.
  - Known CVEs could not be checked: this image's dependency list comes from an SBOM its publisher attached, which nothing verifies, so we will not report it as a clean result.
  - Install-script risk not yet assessed.
  - Dependency health could not be checked: this image's dependency list comes from an SBOM its publisher attached. It names packages and versions but not whether each is deprecated, still maintained or linked to its source, so there is nothing we can fairly grade.
- **Provenance & Transparency**: 48/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 0 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 60/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 5355 tokens (~669/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "readQuery" implies "execute" and declares readOnlyHint instead, contradicting what its own name says it does.
  - An AI judge read all 9 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the ai.haymon/dbmcp MCP server?

ai.haymon/dbmcp runs locally as a container image, launched with docker run --rm -i ghcr.io/haymon-ai/dbmcp:0.15.1. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add ai-haymon-dbmcp -- docker run --rm -i ghcr.io/haymon-ai/dbmcp:0.15.1
```

### Cursor

```json
{
  "mcpServers": {
    "ai-haymon-dbmcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/haymon-ai/dbmcp:0.15.1"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "ai-haymon-dbmcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/haymon-ai/dbmcp:0.15.1"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add ai-haymon-dbmcp -- docker run --rm -i ghcr.io/haymon-ai/dbmcp:0.15.1
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ai-haymon-dbmcp": {
      "type": "local",
      "command": [
        "docker",
        "run",
        "--rm",
        "-i",
        "ghcr.io/haymon-ai/dbmcp:0.15.1"
      ],
      "enabled": true
    }
  }
}
```

### Hermes

```yaml
mcp_servers:
  ai-haymon-dbmcp:
    command: "docker"
    args: ["run", "--rm", "-i", "ghcr.io/haymon-ai/dbmcp:0.15.1"]
```

### Netclaw

```json
{
  "McpServers": {
    "ai-haymon-dbmcp": {
      "Transport": "stdio",
      "Command": "docker",
      "Arguments": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/haymon-ai/dbmcp:0.15.1"
      ]
    }
  }
}
```

### Other

```json
{
  "mcpServers": {
    "ai-haymon-dbmcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/haymon-ai/dbmcp:0.15.1"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-22 (score 40, 0)

- [security regression] Stability: 0.20 → unverified
- [security regression] Tool safety: pass → unverified
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional] First check of Schema quality: unverified
- [functional] Package version: 0.15.0 → 0.15.1

### 2026-10-21 (score 40, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-19 (score 39, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-17 (score 38, +1)

- [functional improvement] Stability: unverified → 0.07
- [functional] Package version: 0.14.0 → 0.15.0

### 2026-10-15 (score 37)

First indexed and scored.

## MCP tools (8)

### `explainQuery` (~354 tokens)

Explain Query

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.

\<usecase>
Use when:
\- A query runs slowly and you need to understand why
\- Investigating performance bottlenecks
\- Planning index creation to optimize queries
\- Analyzing join methods, table scan strategies, and sort operations
\</usecase>

\<when_not_to_use>
\- Running actual queries → use readQuery or writeQuery
\- Checking table structure → use listTables(detailed=true)
\</when_not_to_use>

\<examples>
✓ "Why is my SELECT on orders slow?" → explainQuery(query="SELECT ...")
✓ "Should I add an index?" → explainQuery with analyze=true
✗ "Run this SELECT" → use readQuery
\</examples>

\<safety>
Set `analyze` to true for actual execution statistics (EXPLAIN ANALYZE).
IMPORTANT: EXPLAIN ANALYZE actually executes the query! In read-only mode, only read-only statements are allowed with analyze.
When analyze is false, returns EXPLAIN FORMAT=JSON output without executing.
Only a single SQL statement is accepted.
\</safety>

\<what_it_returns>
A JSON array of execution plan rows showing access methods, join types, row estimates, and costs.
\</what_it_returns>

Input parameters:

- `analyze` (boolean): If true, use EXPLAIN ANALYZE for actual execution statistics. In read-only mode, only allowed for read-only statements. Defaults to false.
- `database` (string|null): Database to explain against. Defaults to the active database.
- `query` (string, required): The SQL query to explain.

Output parameters:

- `rows` (array): Result rows, each a JSON object keyed by a column name.

### `listDatabases` (~183 tokens)

List Databases

List all accessible databases on the connected server. Use this tool to discover what databases are available before using other tools.

\<usecase>
ALWAYS call this tool FIRST when:
\- You need to explore what databases exist on the server
\- You need a database name for listTables or query tools
\- The user asks what data is available
\</usecase>

\<examples>
✓ "What databases are on this server?"
✓ "Show me what's available" → call listDatabases first
\</examples>

\<what_it_returns>
A sorted JSON array of database name strings.
\</what_it_returns>

\<pagination>
Paginated. Pass the prior response's `nextCursor` as `cursor` to fetch the next page.
\</pagination>

Input parameters:

- `cursor` (string|null): Opaque cursor from a prior response's `nextCursor`; omit for the first page.

Output parameters:

- `databases` (array): Sorted list of database names for this page.
- `nextCursor` (string|null): Opaque cursor pointing to the next page. Absent when this is the final page.

### `listFunctions` (~969 tokens)

List Functions

List user-defined SQL functions in a database, optionally filtered and/or with full metadata. Loadable UDFs (`mysql.func`) and stored procedures are excluded.

\<usecase>
Use when:
\- Auditing stored functions across a database (brief mode, default).
\- Searching for a function by partial name (pass `search`).
\- Inspecting a function's language, signature, return type, determinism, SQL-data-access classification, security mode, definer, comment, session context, and full reconstructed `CREATE FUNCTION` text before reasoning about correctness or invocation safety (pass `detailed: true`). Detailed mode supersedes ad-hoc `readQuery` against `information_schema.ROUTINES` / `information_schema.PARAMETERS`.
\</usecase>

\<parameters>
\- `database` — Database to target. Defaults to the active database.
\- `cursor` — Opaque pagination cursor; echo the prior response's `nextCursor`.
\- `search` — Case-insensitive filter on function names via `LIKE`. `%` matches any sequence; `_` matches a single character.
\- `detailed` — When `true`, returns full metadata objects keyed by function name instead of bare name strings. Default `false`.
\</parameters>

\<examples>
✓ "What functions are in the mydb database?" → listFunctions(database="mydb")
✓ "Find the order-total calculation" → listFunctions(search="order")
✓ "What does calc_order_total do?" → listFunctions(search="calc_order_total", detailed=true)
✗ "List stored procedures" → use listProcedures instead
✗ "List loadable UDFs from mysql.func" → not supported; only routines in information_schema.ROUTINES are returned
\</examples>

\<what_it_returns>
Brief mode (default): a sorted JSON array of function-name strings, e.g. `["calc_order_subtotal", "calc_order_total", "double_it"]`.
Detailed mode: a JSON object keyed by bare function name (MySQL/MariaDB do not allow function overloading, so no signature suffix is needed); each value carries `schema`, `language` (typically `"SQL"`; MariaDB external-language functions report the external language…

Input parameters:

- `cursor` (string|null): Opaque cursor from a prior response's `nextCursor`; omit for the first page.
- `database` (string|null): Database to list functions from. Defaults to the active database.
- `detailed` (boolean): When `true`, each returned entry is a full metadata object (schema, language, arguments, returnType, deterministic, sqlDataAccess, security, definer, description, definition, sqlMode, characterSetCli…
- `search` (string|null): Optional case-insensitive filter on function names. The input is used within a `LIKE` clause: `%` matches any sequence of characters and `_` matches any single character.

Output parameters:

- `entries`: Page of matching entries. Shape depends on the request's `detailed` flag.
- `nextCursor` (string|null): Opaque cursor pointing to the next page. Absent when this is the final page.

### `listProcedures` (~1081 tokens)

List Procedures

List user-defined stored procedures in a database, optionally filtered and/or with full metadata. Stored functions and loadable UDFs (`mysql.func`) are excluded.

\<usecase>
Use when:
\- Auditing stored procedures across a database (brief mode, default).
\- Searching for a procedure by partial name (pass `search`).
\- Inspecting a procedure's language, parameter list (with `IN`/`OUT`/`INOUT` modes), determinism, SQL-data-access classification, security mode, definer, comment, session context, and full reconstructed `CREATE PROCEDURE` text before reasoning about correctness or invocation safety (pass `detailed: true`). Detailed mode supersedes ad-hoc `readQuery` against `information_schema.ROUTINES` / `information_schema.PARAMETERS`.
\</usecase>

\<parameters>
\- `database` — Database to target. Defaults to the active database.
\- `cursor` — Opaque pagination cursor; echo the prior response's `nextCursor`.
\- `search` — Case-insensitive filter on procedure names via `LIKE`. `%` matches any sequence; `_` matches a single character.
\- `detailed` — When `true`, returns full metadata objects keyed by procedure name instead of bare name strings. Default `false`.
\</parameters>

\<examples>
✓ "What procedures are in the mydb database?" → listProcedures(database="mydb")
✓ "Find the order archival routine" → listProcedures(search="archive")
✓ "What does archive_order do?" → listProcedures(search="archive_order", detailed=true)
✗ "List functions" → use listFunctions instead
✗ "List loadable UDFs from mysql.func" → not supported; only routines in information_schema.ROUTINES are returned
\</examples>

\<what_it_returns>
Brief mode (default): a sorted JSON array of procedure-name strings, e.g. `["archive_order", "archive_order_history", "purge_order_archive", "touch_post"]`.
Detailed mode: a JSON object keyed by bare procedure name (MySQL/MariaDB do not allow procedure overloading, so no signature suffix is needed); each value carries `schema`, `language` (typically `"SQL"`; MariaDB externa…

Input parameters:

- `cursor` (string|null): Opaque cursor from a prior response's `nextCursor`; omit for the first page.
- `database` (string|null): Database to list procedures from. Defaults to the active database.
- `detailed` (boolean): When `true`, each returned entry is a full metadata object (schema, language, arguments with IN/OUT/INOUT mode tokens, deterministic, sqlDataAccess, security, definer, description, definition, sqlMod…
- `search` (string|null): Optional case-insensitive filter on procedure names. The input is used within a `LIKE` clause: `%` matches any sequence of characters and `_` matches any single character.

Output parameters:

- `entries`: Page of matching entries. Shape depends on the request's `detailed` flag.
- `nextCursor` (string|null): Opaque cursor pointing to the next page. Absent when this is the final page.

### `listTables` (~554 tokens)

List Tables

List tables in a database, optionally filtered and/or with full metadata.

\<usecase>
Use when:
\- Exploring a database to find relevant tables (brief mode, default).
\- Searching for a table by partial name (pass `search`).
\- Inspecting a table's columns, constraints, indexes, and triggers before writing a query (pass `detailed: true`). This supersedes the legacy `getTableSchema` tool.
\</usecase>

\<parameters>
\- `database` — Database to target. Defaults to the active database.
\- `cursor` — Opaque pagination cursor; echo the prior response's `nextCursor`.
\- `search` — Case-insensitive filter on table names via `LIKE`. `%` matches any sequence; `_` matches a single character.
\- `detailed` — When `true`, returns full metadata objects keyed by table name instead of bare name strings. Default `false`.
\</parameters>

\<examples>
✓ "What tables are in mydb?" → listTables(database="mydb")
✓ "Find the orders table" → listTables(search="order")
✓ "What columns does orders have?" → listTables(search="orders", detailed=true)
\</examples>

\<what_it_returns>
Brief mode (default): a sorted JSON array of table-name strings, e.g. `["customers", "orders"]`.
Detailed mode: a JSON object keyed by table name; each value carries `schema`, `kind`, `owner`, `comment`, `columns`, `constraints`, `indexes`, and `triggers` (the name is the key and is not repeated inside the value). Keys iterate in the same alphabetical order brief mode uses. Example: `{"orders": {"schema": "mydb", "kind": "TABLE", …}}`.
\</what_it_returns>

\<pagination>
Paginated. Pass the prior response's `nextCursor` as `cursor` to fetch the next page. The `search` filter must stay the same across pages for cursor continuity.
\</pagination>

Input parameters:

- `cursor` (string|null): Opaque cursor from a prior response's `nextCursor`; omit for the first page.
- `database` (string|null): Database to list tables from. Defaults to the active database.
- `detailed` (boolean): When `true`, each returned entry is a full metadata object (columns, constraints, indexes, triggers, owner, comment, kind); when `false` or omitted, each entry is the bare table-name string.
- `search` (string|null): Optional case-insensitive filter on table names. The input is used within a `LIKE` clause: `%` matches any sequence of characters and `_` matches any single character.

Output parameters:

- `entries`: Page of matching entries. Shape depends on the request's `detailed` flag.
- `nextCursor` (string|null): Opaque cursor pointing to the next page. Absent when this is the final page.

### `listTriggers` (~719 tokens)

List Triggers

List user-defined triggers in a database, optionally filtered and/or with full metadata.

\<usecase>
Use when:
\- Auditing trigger coverage across a database (brief mode, default).
\- Searching for a trigger by partial name (pass `search`).
\- Inspecting a trigger's timing, event, activation level, full `CREATE TRIGGER` text, and the session context active at trigger-creation time before reasoning about side-effects (pass `detailed: true`). Detailed mode supersedes ad-hoc `readQuery` against `information_schema.TRIGGERS`.
\</usecase>

\<parameters>
\- `database` — Database to target. Defaults to the active database.
\- `cursor` — Opaque pagination cursor; echo the prior response's `nextCursor`.
\- `search` — Case-insensitive filter on trigger names via `LIKE`. `%` matches any sequence; `_` matches a single character.
\- `detailed` — When `true`, returns full metadata objects keyed by trigger name instead of bare name strings. Default `false`.
\</parameters>

\<examples>
✓ "What triggers are in the mydb database?" → listTriggers(database="mydb")
✓ "Find the audit triggers" → listTriggers(search="audit")
✓ "What does orders_audit_after_insert do?" → listTriggers(search="orders_audit_after_insert", detailed=true)
✗ "Show me a trigger's body" → use detailed mode; the `definition` field carries the full `CREATE TRIGGER` text
\</examples>

\<what_it_returns>
Brief mode (default): a sorted JSON array of trigger-name strings, e.g. `["customers_audit_after_insert", "orders_audit_after_insert"]`.
Detailed mode: a JSON object keyed by trigger name; each value carries `schema`, `table`, `timing` (BEFORE/AFTER), `events` (single-element array — `INSERT`, `UPDATE`, or `DELETE`), `activationLevel` (always `ROW` on MySQL/MariaDB), `definition` (the canonical `CREATE TRIGGER` text including `DEFINER=` in `` `user`@`host` `` form), `sqlMode`, `characterSetClient`, `collationConnection`, and `databaseCollation`. The Postgres-only `status` and `functionName` fields are intentionally absent (no per-…

Input parameters:

- `cursor` (string|null): Opaque cursor from a prior response's `nextCursor`; omit for the first page.
- `database` (string|null): Database to list triggers from. Defaults to the active database.
- `detailed` (boolean): When `true`, each returned entry is a full metadata object (schema, table, timing, events, activationLevel, definition, plus backend-specific fields); when `false` or omitted, each entry is the bare…
- `search` (string|null): Optional case-insensitive filter on trigger names. The input is used within a `LIKE` clause: `%` matches any sequence of characters and `_` matches any single character.

Output parameters:

- `entries`: Page of matching entries. Shape depends on the request's `detailed` flag.
- `nextCursor` (string|null): Opaque cursor pointing to the next page. Absent when this is the final page.

### `listViews` (~907 tokens)

List Views

List user-defined views in a database, optionally filtered and/or with full metadata. Base tables and system-schema views are excluded.

\<usecase>
Use when:
\- Auditing views across a database (brief mode, default).
\- Searching for a view by partial name (pass `search`).
\- Inspecting a view's definer, security mode, check-option level, updatable flag, session character set/collation, and full SELECT body before querying it (pass `detailed: true`). Detailed mode supersedes ad-hoc `readQuery` against `information_schema.VIEWS`.
\</usecase>

\<parameters>
\- `database` — Database to target. Defaults to the active database.
\- `cursor` — Opaque pagination cursor; echo the prior response's `nextCursor`.
\- `search` — Case-insensitive filter on view names via `LIKE`. `%` matches any sequence; `_` matches a single character.
\- `detailed` — When `true`, returns full metadata objects keyed by view name instead of bare name strings. Default `false`.
\</parameters>

\<examples>
✓ "What views are in the mydb database?" → listViews(database="mydb")
✓ "Find the active-users view" → listViews(search="active")
✓ "What does active_users select?" → listViews(search="active_users", detailed=true)
✗ "Show me the columns of a view" → use listTables with `detailed: true` instead
✗ "List materialized views" → MySQL/MariaDB have no materialized-view concept
\</examples>

\<what_it_returns>
Brief mode (default): a sorted JSON array of view-name strings, e.g. `["active_orders", "active_users", "published_posts"]`.
Detailed mode: a JSON object keyed by bare view name; each value carries `schema`, `definer` (`user@host`), `security` (`INVOKER` or `DEFINER`), `checkOption` (`NONE`, `CASCADED`, or `LOCAL`), `updatable` (boolean), `characterSetClient`, `collationConnection`, and `definition` (the SELECT body verbatim from `information_schema.VIEWS.VIEW_DEFINITION`, with no `CREATE VIEW` wrapper). The view name is the map key only — it is not repeated inside the value.

Versus the Postgres `listViews` deta…

Input parameters:

- `cursor` (string|null): Opaque cursor from a prior response's `nextCursor`; omit for the first page.
- `database` (string|null): Database to list views from. Defaults to the active database.
- `detailed` (boolean): When `true`, each returned entry is a full metadata object (schema, definer, security, checkOption, updatable, characterSetClient, collationConnection, definition); when `false` or omitted, each entr…
- `search` (string|null): Optional case-insensitive filter on view names. The input is used within a `LIKE` clause: `%` matches any sequence of characters and `_` matches any single character.

Output parameters:

- `entries`: Page of matching entries. Shape depends on the request's `detailed` flag.
- `nextCursor` (string|null): Opaque cursor pointing to the next page. Absent when this is the final page.

### `readQuery` (~366 tokens)

Read Query

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

\<usecase>
Use when:
\- Querying data from tables (SELECT with WHERE, JOIN, GROUP BY, etc.)
\- Aggregations: COUNT, SUM, AVG, GROUP BY, HAVING
\- Listing server variables or status (SHOW)
\- Viewing table structure (DESCRIBE)
\- Switching database context (USE)
\</usecase>

\<when_not_to_use>
\- Data changes (INSERT, UPDATE, DELETE) → use writeQuery
\- Query performance analysis → use explainQuery
\- Discovering tables or columns → use listTables (pass detailed=true for column-level metadata)
\</when_not_to_use>

\<examples>
✓ "SELECT * FROM users WHERE status = 'active'"
✓ "SELECT COUNT(*) FROM orders GROUP BY region"
✓ "SHOW TABLES" or "DESCRIBE users"
✗ "INSERT INTO users ..." → use writeQuery
✗ "EXPLAIN SELECT ..." → use explainQuery for structured analysis
\</examples>

\<what_it_returns>
A JSON array of row objects, each keyed by column name.
\</what_it_returns>

\<pagination>
\`SELECT` results are paginated. Pass the prior response's `nextCursor` as `cursor` to fetch the next page. `SHOW`, `DESCRIBE`, `USE`, and `EXPLAIN` return a single page and ignore `cursor`.
\</pagination>

Input parameters:

- `cursor` (string|null): Opaque cursor from a prior response's `nextCursor`; omit for the first page.
- `database` (string|null): Database to run the query against. Defaults to the active database.
- `query` (string, required): The SQL query to execute.

Output parameters:

- `nextCursor` (string|null): 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`, `EXPLA…
- `rows` (array): Result rows, each a JSON object keyed by a column name.

## Diagnostics

Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/ai-haymon-dbmcp/ghcr-io-haymon-ai-dbmcp#diagnostics

## Score history

- 2026-10-22: 40
- 2026-10-21: 40
- 2026-10-20: 39
- 2026-10-19: 39
- 2026-10-18: 38
- 2026-10-17: 38
- 2026-10-16: 37
- 2026-10-15: 37

## Common questions

### What is the ai.haymon/dbmcp MCP server?

ai.haymon/dbmcp is an MCP server listed in the public MCP registry as ai.haymon/dbmcp. Database MCP server for MySQL, MariaDB, PostgreSQL & SQLite with PII redaction and write-prevention. This page covers its container image (ghcr.io/haymon-ai/dbmcp).

### Is the ai.haymon/dbmcp MCP server safe to use?

ai.haymon/dbmcp scores 40 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the ai.haymon/dbmcp MCP server expose?

ai.haymon/dbmcp exposes 8 tools: explainQuery, listDatabases, listFunctions, listProcedures, listTables, and 3 more. Their descriptions and schemas cost roughly 5,133 tokens of context every time the server is loaded.

### Is the ai.haymon/dbmcp MCP server still maintained?

ai.haymon/dbmcp is still listed as active in the MCP registry. We last reached this channel on 22 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the ai.haymon/dbmcp MCP server under?

ai.haymon/dbmcp declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- GitHub Container Registry: https://ghcr.io/haymon-ai/dbmcp
- Repository: https://github.com/haymon-ai/dbmcp
- Website: https://dbmcp.haymon.ai/
- Changelog RSS feed: https://verifymcp.io/servers/ai-haymon-dbmcp/ghcr-io-haymon-ai-dbmcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/ai-haymon-dbmcp/ghcr-io-haymon-ai-dbmcp.json
- HTML version of this page: https://verifymcp.io/servers/ai-haymon-dbmcp/ghcr-io-haymon-ai-dbmcp