Skip to main content
Glama
manpreet2000

MCP Database Server

by manpreet2000

MCP Database Server

A Model Context Protocol (MCP) server implementation that allows Large Language Models (LLMs) to interact with various databases through natural language. Currently supports MongoDB, with plans to support:

  • PostgreSQL

  • CockroachDB

  • Redis

  • And more...

Features

  • Database operations through natural language

  • Currently supports MongoDB with features:

    • List all collections

    • Query documents with filtering and projection

    • Insert documents

    • Delete documents

    • Aggregate pipeline operations

  • Future support for other databases:

    • PostgreSQL: SQL queries, table operations

    • CockroachDB: Distributed SQL operations

    • Redis: Key-value operations, caching

Related MCP server: MongoDB

Prerequisites

  • Node.js v20.12.2 or higher

  • Database (currently MongoDB, other databases coming soon)

  • Claude Desktop Application

Installation

  1. Clone the repository:

git clone https://github.com/manpreet2000/mcp-database-server.git
cd mcp-database-server
  1. Install dependencies:

npm install
  1. Build the TypeScript code:

npm run build

Configuration

To get started, you need to configure your database connection in your Claude Desktop configuration file:

MacOS

~/Library/Application\ Support/Claude/claude_desktop_config.json

Windows

%APPDATA%/Claude/claude_desktop_config.json

Add the following configuration to your claude_desktop_config.json:

{
  "mcpServers": {
    "database": {
      "command": "/path/to/node",
      "args": ["/path/to/mcp-database/dist/index.js"],
      "env": {
        "MONGODB_URI": "your-mongodb-connection-string"
      }
    }
  }
}

Replace:

  • /path/to/node with your Node.js executable path or just use node

  • /path/to/mcp-database with the absolute path to this repository

  • your-mongodb-connection-string with your MongoDB connection URL

Usage Examples

MongoDB Examples

  1. List all collections in your database:

Can you show me all the collections in my database?
  1. Get specific records from a collection:

Give me 2 records from the chargers collection
  1. Query with filters:

Show me all documents in the users collection where status is active
  1. Insert a document:

Add a new user to the users collection with name John and email john@example.com
  1. Delete a document:

Remove the user with email john@example.com from the users collection
  1. Aggregate data:

Show me the total count of users by status in the users collection

Available Tools

1. getCollections

Lists all collections in the connected database.

2. getCollection

Retrieves documents from a collection with optional query parameters:

  • collectionName: Name of the collection

  • limit: Maximum number of documents to return (default: 10, max: 1000)

  • query: MongoDB query object

  • projection: Fields to include/exclude

3. insertOne

Inserts a single document into a collection:

  • collectionName: Name of the collection

  • document: Document object to insert

4. deleteOne

Deletes a single document from a collection:

  • collectionName: Name of the collection

  • query: Query to match the document to delete

5. aggregate

Executes an aggregation pipeline:

  • collectionName: Name of the collection

  • pipeline: Array of aggregation stages

  • options: Optional aggregation options

Future Database Support

PostgreSQL

  • SQL query execution

  • Table operations

  • Schema management

  • Transaction support

CockroachDB

  • Distributed SQL operations

  • Multi-region support

  • Transaction management

  • Schema operations

Redis

  • Key-value operations

  • Caching mechanisms

  • Pub/sub operations

  • Data structure operations

Security

  • Never commit your database connection strings to version control

  • Use environment variables for sensitive information

  • Follow database-specific security best practices

Contributing

Contributions are welcome! Please feel free to submit a Pull Request. For major changes, please open an issue first to discuss what you would like to change.

License

MIT License - See LICENSE for details

Available Tools

5 tools
aggregateD
ParametersJSON Schema
NameRequiredDescriptionDefault
collectionNameYes
pipelineYes
optionsNo

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

deleteOneD
ParametersJSON Schema
NameRequiredDescriptionDefault
collectionNameYes
queryYes

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getCollectionD
ParametersJSON Schema
NameRequiredDescriptionDefault
collectionNameYes
limitNo
queryNo
projectionNo

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getCollectionsD
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

insertOneD
ParametersJSON Schema
NameRequiredDescriptionDefault
collectionNameYes
documentYes

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

  1. 5 tool updates
    • First observedaggregate
    • First observeddeleteOne
    • First observedgetCollection
    • First observedgetCollections
    • First observedinsertOne

TDQS

D1.5/5.0
Disambiguation4/5

The tools have distinct purposes: aggregate, deleteOne, getCollection, getCollections, and insertOne each target different database operations. However, getCollection and getCollections could potentially be confused due to similar naming and lack of descriptions clarifying their exact differences.

Naming Consistency2/5

Naming is inconsistent with mixed conventions: getCollection and getCollections use camelCase, while deleteOne and insertOne use camelCase with different verb styles, and aggregate stands alone. There is no predictable pattern across all tools.

Tool Count3/5

With 5 tools, the count is reasonable for a database server, but it feels borderline thin for covering full CRUD operations and database management. Key operations like update or query filtering are missing, making the set feel incomplete.

Completeness2/5

The tool set has significant gaps for a database server: it lacks update operations, query filtering tools, and transaction management. While basic insert, delete, and get operations are present, the surface is incomplete for typical database workflows, likely causing agent failures.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    F
    maintenance
    A Model Context Protocol (MCP) server that enables LLMs to interact directly with MongoDB databases. Query collections, inspect schemas, and manage data seamlessly through natural language.
    47
    175
    MIT
  • A
    license
    B
    quality
    A
    maintenance
    A Model Context Protocol server that provides access to MongoDB databases. This server enables LLMs to inspect collection schemas and execute read-only queries.
    8
    356
    284
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables LLMs to interact directly with MongoDB databases, allowing users to query collections, inspect schemas, and manage data through natural language.
    47
    2
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables LLMs to interact directly with MongoDB databases, allowing users to query collections, inspect schemas, and manage data through natural language.
    47
    MIT

Latest Blog Posts

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/manpreet2000/mcp-database-server'

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