Which integrations are available for this server?

Allows execution of queries against MongoDB databases with support for connection management and secure credential handling Provides secure query execution against MySQL databases with connection configuration and management Enables secure interaction with PostgreSQL databases including connection management and query execution Uses SQLite as the configuration database to store and manage connection details for other database systems

How do I use Custom MCP Database Server?

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., "@Custom MCP Database Server show me the top 5 customers by total purchases from the sales database" 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.

Custom MCP Database Server

by renanlido

Overview Schema Related Servers Score Discussions

Python

Local

Custom MCP Database

mcp-name: io.github.renanlido/custom-mcp-database

An MCP server that lets AI agents run alias-based queries against PostgreSQL, MySQL, MongoDB and Oracle — without ever exposing credentials to the model. Connections are configured once and stored locally; the agent only ever references them by alias.

Works with Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, Gemini CLI, and any other MCP client (all use the same stdio launch command).

Quickstart

There are two roles, on purpose. Keeping them separate is what stops your DB password from ever reaching the model.

You (once, in your terminal) — install the credentials

The agent never installs credentials. You do, with the CLI. The secret stays on your machine and is never sent to the model.

Easiest way — the guided wizard (asks type, host, user, and how to supply the secret; optionally tests the connection):

uvx custom-mcp-database setup

Or do it in one line (you'll be prompted for the password — hidden input):

uvx custom-mcp-database add-db --alias prod_ro --type postgres \
  --host db.internal --port 5432 --user reporting --dbname app

uvx custom-mcp-database list-aliases   # confirm it's there

The agent (always) — uses it by alias

Point your MCP client at the server (see Install), then just ask:

"Using prod_ro, run SELECT count(*) FROM orders."

The agent calls db_execute_query with the alias prod_ro — never a host, user, or password. It physically cannot see the credentials; they live in your local config, resolved only inside the server process at query time.

Why the agent can't add the DB: an MCP tool's arguments are produced and read by the LLM. If the agent typed your password into an add tool, that password would land in the model's context, the provider, and the logs. So credential setup is a human/CLI step by design. (Need an agent to wire connections in an automated pipeline? See MCP_DB_ALLOW_ADMIN_TOOLS in SECURITY.md — even then it only accepts a reference to a secret, e.g. an env-var name, never the secret itself.)

Writes are off by default (read-only). To allow them for a task: export MCP_DB_READONLY=0 MCP_DB_ALLOW_WRITES=1.

Related MCP server: anydb-mcp

Install

The server runs over stdio. The universal launch command is uvx custom-mcp-database run (requires uv; the package is fetched from PyPI on first run).

Claude Code

# Direct (published package)
claude mcp add custom-mcp-database -- uvx custom-mcp-database run

# Or install the full plugin from this repo's marketplace
/plugin marketplace add renanlido/custom-mcp-database
/plugin install custom-mcp-database@renanlido-mcp

Claude Desktop

Two options:

One-click bundle — build the .mcpb (mcpb pack) and open it in Claude Desktop. See Distribution.
Manual config — add the snippet from examples/mcp-clients/claude-desktop.json to claude_desktop_config.json.

Other clients

Copy the matching snippet — all use the same command/args, only the file and key differ:

Client	Config file	Key	Snippet
Cursor	`~/.cursor/mcp.json`	`mcpServers`	cursor.json
VS Code	`.vscode/mcp.json`	`servers`	vscode.json
Windsurf	`~/.codeium/windsurf/mcp_config.json`	`mcpServers`	windsurf.json
Gemini CLI	`~/.gemini/settings.json`	`mcpServers`	gemini-cli.json

Full client matrix and a local-checkout variant: examples/mcp-clients/README.md.

Configure connections

Configure connections from your terminal with the CLI — never through the agent. A connection's password is a real secret; if it were passed as an MCP tool argument it would enter the model's context (and the provider, transcripts, and logs). So the credential-management tools are off the MCP surface by default; provisioning is a human/CLI task. The agent only lists and uses aliases.

Omit --password/--uri to be prompted securely (hidden input, not stored in shell history). Even better, keep the secret out of the config file entirely with --password-env / --password-file (resolved at connection time):

# PostgreSQL — prompted for the password (recommended)
uvx custom-mcp-database add-db --alias pg --type postgres \
  --host localhost --port 5432 --user me --dbname app

# MySQL — password taken from an env var at connect time (nothing secret on disk)
MYSQL_PW=... uvx custom-mcp-database add-db --alias my --type mysql \
  --host localhost --port 3306 --user root --dbname app --password-env MYSQL_PW

# Oracle — password read from a file (e.g. a mounted secret)
uvx custom-mcp-database add-db --alias ora --type oracle \
  --host db.example.com --port 1521 --user system --dbname ORCLPDB1 \
  --password-file /run/secrets/ora_pw

# MongoDB — full URI from a file (the URI embeds credentials)
uvx custom-mcp-database add-db --alias mongo --type mongo \
  --dbname app --uri-file /run/secrets/mongo_uri

uvx custom-mcp-database list-aliases
uvx custom-mcp-database remove-db --alias pg

Config location (override with MCP_DB_CONFIG): $XDG_CONFIG_HOME/custom-mcp-database/mcp_config.sqlite3 (default ~/.config/custom-mcp-database/mcp_config.sqlite3, 0600).

If you pass a literal --password/--uri, it is stored as plaintext JSON in that SQLite file. Prefer --password-env/--password-file (or --uri-env/--uri-file) so only a reference is stored. Either way, keep the file secret (it is 0600, gitignored, not encrypted).

MCP tools

Tool	Purpose
`db_list_aliases`	List configured aliases and types
`db_execute_query`	Run SQL or a MongoDB JSON filter
`db_list_collections`	List MongoDB collections
`db_security_status`	Report the active security policy

db_add_database / db_remove_database are not exposed over MCP by default — manage connections with the CLI. To opt into exposing them (the add tool only accepts secrets by reference, never a literal password), set MCP_DB_ALLOW_ADMIN_TOOLS=1.

db_execute_query notes: SQL runs as given with parameterized binds (add your own LIMIT); MongoDB takes a JSON filter + collection, caps results at 10 (--limit), rejects empty filters, and coerces 24-char hex strings to ObjectId.

Security

This server handles real credentials and production data, so it ships deny-by-default:

Read-only by default. Only SELECT-class SQL runs. Writes/DDL require explicit opt-in.
No stacked statements (;-injection blocked), single statement per call.
MongoDB server-side JavaScript blocked ($where, $function, $accumulator, mapReduce, …).
Identifiers validated (oracle_schema can't be used for injection).
Results capped at MCP_DB_MAX_ROWS (default 1000); secrets redacted from errors.
Credential store is 0600 plaintext SQLite — keep the host disk encrypted.

Check the live posture: custom-mcp-database security-status (or the db_security_status tool).

Enable writes for a specific task (then turn it back off):

export MCP_DB_READONLY=0
export MCP_DB_ALLOW_WRITES=1     # INSERT/UPDATE/DELETE
# export MCP_DB_ALLOW_DDL=1      # only if you really need CREATE/DROP/ALTER/...

Read the full protocol — least-privilege DB roles, TLS, prompt-injection handling, vulnerability reporting — in SECURITY.md. The app-layer guards are defense-in-depth; the authoritative control is a least-privilege database account.

Develop

uv sync                 # create .venv and install deps
make run                # run the server (stdio)
make lint               # ruff
make build              # sdist + wheel into dist/

Inspect tools interactively:

uv run mcp dev src/custom_mcp_database/server.py

Distribution

This repo ships ready-to-publish metadata for every major channel. All of it is published automatically on push to main (see below):

Channel	File	Published by
PyPI	`pyproject.toml`	`release.yml` (push to main)
MCP Registry	`server.json`	`release.yml` (push to main)
Claude Code plugin	`.claude-plugin/plugin.json`, `.mcp.json`	available on GitHub push
Claude Code marketplace	`.claude-plugin/marketplace.json`	available on GitHub push
Claude Desktop bundle	`manifest.json`	`release.yml` attaches `.mcpb` to the Release

Automated release — just push to `main`

Releases are fully automated. On every push to main, .github/workflows/release.yml:

Picks the next semantic version from your commits since the last tag (feat: → minor, BREAKING CHANGE/type!: → major, anything else → patch; add [skip release] to a commit message to skip).
Writes that version into pyproject.toml and syncs it into every artifact (server.json, manifest.json, plugin + marketplace) via scripts/sync_version.py — version lives in one place, no hand-bumping.
Builds, commits chore(release): vX [skip ci], tags vX, pushes.
Publishes to PyPI (Trusted Publishing/OIDC), then the MCP Registry (GitHub OIDC).
Packs the .mcpb and cuts a GitHub Release with the wheel + bundle attached.

The release commit carries [skip ci], so it does not re-trigger the workflow.

One-time setup (can't be automated — needs your accounts):

Create a PyPI Trusted Publisher for renanlido/custom-mcp-database, workflow release.yml.
Allow GitHub Actions to push to main (repo → Settings → Actions → Read and write permissions; if main is a protected branch, allow the actions bot to bypass or use a PAT).

The MCP Registry namespace is io.github.renanlido/custom-mcp-database (GitHub-validated).

Local manual escape hatch: make build (syncs version + builds) then uv publish.

License

MIT

Available Tools

4 tools

db_execute_queryA

Destructive

Run a query against a configured database.

SQL (postgres/mysql/oracle): pass the SQL string in query and optional bind values in params (use the driver's placeholder style; Oracle uses :name). Add your own LIMIT/WHERE to keep results small.

MongoDB: pass a JSON filter object in query and the collection name. 24-char hex strings are coerced to ObjectId; empty filters are rejected; results are capped at limit documents (default 10).

Returns: {"data": [...], "row_count": int} (plus "error" on a rejected empty Mongo filter)

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`params`	No
`collection`	No
`oracle_schema`	No
`database_alias`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior4/5

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

Beyond annotations (destructiveHint=true), it discloses behavior like empty Mongo filter rejection, result capping, and Oracle placeholder style, but lacks details on auth or rate limits.

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 front-loaded purpose and bullet-style details for different DB types; no redundant sentences.

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?

Covers 6 parameters, required/optional, return format, and error cases; output schema exists but description still adds value with row_count and error details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully explains parameters: query type per DB, params, collection, limit, oracle_schema, and database_alias.

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 it runs queries against configured databases, distinguishes between SQL and MongoDB usage, and aligns with sibling tools.

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?

Provides explicit guidance for SQL (add LIMIT/WHERE, use driver placeholder style) and MongoDB (JSON filter, collection name, empty filter rejection, result cap), helping agents formulate correct queries.

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

db_list_aliasesA

Read-onlyIdempotent

List every configured database alias and its type.

Returns: {"aliases": [{"alias": str, "type": "postgres|mysql|mongo|oracle"}, ...]}

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds the return format structure, but no additional behavioral traits beyond what annotations imply.

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: first defines purpose, second shows return. No wasted words, front-loaded with key information.

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 likely output schema, the description completely covers what the tool does and returns.

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 exist (0 params, schema coverage 100%). Baseline of 4 applies; the description does not need to add parameter meaning.

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 action ('List every configured database alias') and the result ('its type'). It distinguishes from siblings like db_list_collections (lists collections) and db_execute_query (executes queries).

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?

No guidance on when to use this tool vs alternatives (e.g., db_list_collections). For a simple listing tool, it's somewhat self-explanatory, but explicit context is missing.

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

db_list_collectionsA

Read-onlyIdempotent

List all collections for a configured MongoDB alias.

Returns: {"collections": [str, ...]}

ParametersJSON Schema

Name	Required	Description	Default
`database_alias`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

Annotations provide readOnlyHint=true and destructiveHint=false, so description doesn't need to restate safety. Adds return format but lacks details on error cases or permissions.

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?

Extremely concise: one sentence for purpose plus return type. No wasted words, front-loaded with key action.

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?

Sufficient for a simple list tool with output schema. Lacks mention of error behavior if alias is invalid, but acceptable given tool simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage. Description only mentions 'configured MongoDB alias' without specifying what the parameter represents or its format/expectations.

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 the verb 'List' and resource 'collections for a configured MongoDB alias'. Distinguishes from sibling tools like db_list_aliases (lists aliases) and db_execute_query (executes queries).

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?

Implied usage context (use when needing collections for an alias) but no explicit when-to-use or when-not-to-use guidance versus siblings.

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

db_security_statusA

Read-onlyIdempotent

Report the active security policy.

Returns: {"readonly": bool, "allow_writes": bool, "allow_ddl": bool, "max_rows": int, "mongo_javascript_blocked": bool}

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the exact return fields (readonly, allow_writes, allow_ddl, etc.), giving the agent concrete behavioral expectations beyond the abstract hints.

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 extremely concise: one line for the purpose and a code block for the return format. Every word earns its place, and the structure front-loads the core action then gives details.

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, clear annotations, and an output schema in the description, the tool is fully specified. An agent can understand what it does, that it's safe, and what it returns without further context.

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 schema coverage is 100%. The description does not need to add parameter semantics, and the baseline score of 4 applies as no compensation is necessary.

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 'Report the active security policy' and provides the return format, making the purpose unambiguous. It distinguishes itself from sibling tools like db_list_aliases, db_list_collections, and db_execute_query, which deal with listing or querying data, not security status.

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 for checking security status but does not explicitly state when to use it versus alternatives. No guidance on when not to use or conditions is provided, leaving it to the agent to infer.

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.

4 tool updatesv0.6.2Jul 30, 2026
- First observeddb_execute_query
- First observeddb_list_aliases
- First observeddb_list_collections
- First observeddb_security_status

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct function: listing aliases, listing MongoDB collections, executing queries, and reporting security status. No overlap or ambiguity.

Naming Consistency4/5

All tools follow a 'db_' prefix and mostly verb_noun pattern (db_list_aliases, db_list_collections, db_execute_query), though db_security_status is noun_noun, creating a minor inconsistency.

Tool Count4/5

With 4 tools, the set is small but well-scoped for a basic database query utility. It does not feel excessive or obviously insufficient for its stated purpose.

Completeness2/5

The tool set lacks essential operations like creating or modifying aliases, listing tables for SQL databases, and managing schema. The single query tool covers multiple DB types but misses common CRUD operations, leaving notable gaps.

Maintenance

ActivityStale

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

QueryBearOAuth
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
agentlock
io.github.Olum289
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Security Agent Orchestration
2
Veto — SQL Safety & Cost Oracle A
com.vetosql
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Databases Security Autonomous Agents
32
nexusOAuth
com.civic
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Agent Orchestration Developer Tools App Automation
2

Related MCP Servers

askdb
mgorabbani
A
license
Not graded
quality
B
maintenance
Self-hosted MCP server that bridges your MongoDB or PostgreSQL database to AI agents, with sandbox isolation and field-level control.
Updated 2 months ago (2026-06-23 06:51 UTC)
73
MIT
anydb-mcp
Databases Developer Tools
officialalexeev
A
license
Not graded
quality
D
maintenance
Zero-config MCP server that empowers AI agents to safely query SQL and NoSQL databases like PostgreSQL, MySQL, SQLite, MongoDB, and Redis.
Updated 5 months ago (2026-04-13 16:07 UTC)
24
1
MIT
mcp-enterprise-starter
Databases Developer Tools
InkByteStudio
A
license
A
quality
D
maintenance
A production-grade MCP server that gives AI agents safe, authenticated access to a PostgreSQL database.
Updated 6 months ago (2026-03-13 20:53 UTC)
3
MIT
db-access-mcp
Databases Cloud Platforms
Rheopyrin
A
license
A
quality
A
maintenance
An MCP server that gives AI agents access to configured databases (PostgreSQL, MySQL, Redshift, SQL Server) with SSH/AWS SSM tunnels, pluggable secret providers, and strict per-instance isolation.
Updated 2 months ago (2026-07-13 13:31 UTC)
10
79
MIT

Appeared in Searches

Connecting to Oracle DB and summarizing table details with schema, relationships, and associated components

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/renanlido/custom-mcp-database'

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

Custom MCP Database

Quickstart

You (once, in your terminal) — install the credentials

The agent (always) — uses it by alias

Install

Claude Code

Claude Desktop

Other clients

Configure connections

MCP tools

Security

Develop

Distribution

Automated release — just push to main

License

Available Tools

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

Automated release — just push to `main`