Which integrations are available for this server?

Provides tools for interacting with MongoDB databases, including listing collections, fetching schemas, and performing CRUD operations (insert, update, delete, find) on documents.

How do I use MongoDB MCP?

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., "@MongoDB MCP show me the users collection 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.

MongoDB MCP

by vishnuweb-a

Overview Schema Related Servers Score Discussions

Python

Local

MongoDB MCP

A MongoDB Model Context Protocol (MCP) Server that allows AI agents and MCP clients to interact with MongoDB databases through standardized tools.

Features

List all collections
Discover collection schemas
Fetch collection data
Query documents
Insert documents
Update documents
Delete documents
MongoDB Atlas support
Local MongoDB support
MCP stdio transport support

Installation

Related MCP server: MongoDB MCP Server

Using pip

pip install mongo-mcp

Using uv

uv add mongo-mcp

Prerequisites

Python 3.10+
MongoDB Local Instance or MongoDB Atlas Cluster

Examples:

mongodb://localhost:27017

mongodb+srv://username:password@cluster.mongodb.net

Configuration

MongoDB MCP uses environment variables to connect to your database.

Create a .env file:

MONGODB_URI=mongodb://localhost:27017
DATABASE_NAME=shipbihar

Environment Variables

Variable	Description	Required
MONGODB_URI	MongoDB connection string	Yes
DATABASE_NAME	Database name	Yes

Running the MCP Server

mongo_mcp

python -m mongo_mcp.main

The MCP server will start using stdio transport.

MCP Client Configuration

Example MCP configuration:

{
  "mcpServers": {
    "mongodb": {
      "command": "mongo_mcp",
      "env": {
        "MONGODB_URI": "mongodb://localhost:27017",
        "DATABASE_NAME": "shipbihar"
      }
    }
  }
}

Available Tools

all_collections

Returns all collections in the configured database.

Example Output:

[
  "users",
  "orders",
  "shipments"
]

fetch_collection_schema

Returns an inferred schema from a sample document.

Example:

{
  "_id": "ObjectId",
  "name": "str",
  "email": "str",
  "createdAt": "datetime"
}

fetch_collection_data

Returns documents from a collection.

Parameters:

{
  "collection_name": "users",
  "limit": 100
}

find_document

Find a document using a MongoDB query.

Example:

{
  "collection_name": "users",
  "query": {
    "email": "john@example.com"
  }
}

insert_document

Insert a document.

Example:

{
  "collection_name": "users",
  "document": {
    "name": "John",
    "email": "john@example.com"
  }
}

update_document

Update matching documents.

Example:

{
  "collection_name": "users",
  "filter_query": {
    "email": "john@example.com"
  },
  "update_data": {
    "role": "admin"
  }
}

delete_document

Delete matching documents.

Example:

{
  "collection_name": "users",
  "filter_query": {
    "email": "john@example.com"
  }
}

Common Errors

Error: DATABASE_NAME is None

Error:

TypeError: name must be an instance of str, not <class 'NoneType'>

Reason:

MongoDB MCP cannot find the DATABASE_NAME environment variable.

Solution:

Create a .env file:

MONGODB_URI=mongodb://localhost:27017
DATABASE_NAME=your_database_name

or export variables manually.

Windows PowerShell:

$env:MONGODB_URI="mongodb://localhost:27017"
$env:DATABASE_NAME="shipbihar"

Linux/macOS:

export MONGODB_URI="mongodb://localhost:27017"
export DATABASE_NAME="shipbihar"

Error: Connection Refused

Error:

ServerSelectionTimeoutError

Reason:

MongoDB server is not running.

Solution:

Start MongoDB:

mongod

or verify your Atlas connection string.

Error: Authentication Failed

Error:

Authentication failed

Reason:

Incorrect username or password.

Solution:

Verify your MongoDB credentials.

Security

Recommended:

Use dedicated database users
Restrict permissions when possible
Avoid connecting with admin credentials
Store secrets in environment variables

Do NOT:

Commit .env files to GitHub
Hardcode MongoDB passwords in code

Development

Clone the repository:

git clone <repository-url>
cd mongo-mcp

Create environment:

uv venv
source .venv/bin/activate

Install dependencies:

uv sync

Run locally:

python -m mongo_mcp.main

Roadmap

V1

Collection discovery
CRUD operations
Schema inspection

V2

Aggregation pipelines
Count documents
Regex search

V3

Natural language queries
Query optimization
Schema caching

License

MIT License

Author

Vishnu Bhardwaj

Built for AI Agents, MCP Clients, and MongoDB Developers.

mongo_agent_mcp

Available Tools

8 tools

all_collectionsA

Returns all collections in the database.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/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 of behavioral disclosure. It states a read-only action ('returns') which implies safety, but it does not mention ordering, pagination, inclusion of hidden or system collections, or error behavior. This is adequate for a simple listing tool but lacks richer context.

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 sentence that is front-loaded and free of extraneous information. Every word contributes to conveying the tool's purpose, making it highly concise and well-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?

For a tool with no parameters, no annotations, and no output schema, the description is reasonably complete: it states exactly what the tool returns. It could be enhanced by specifying the return format (e.g., list of collection names versus full collection metadata), but given the low complexity, the existing description is nearly sufficient.

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

Parameters4/5

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

The tool has zero parameters, and the schema confirms an empty properties object. With 100% schema description coverage and no parameters to explain, the description does not need to add parameter semantics; the baseline of 4 for zero-parameter tools applies.

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 'Returns all collections in the database' uses a specific verb ('returns') and a clear resource ('all collections') with a scope ('in the database'). It distinguishes itself from sibling tools like fetch_collection_schema or fetch_collection_data, which target a specific collection's schema or data, by focusing on the top-level enumeration of all collections.

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 its usage—when you need to list all collections—but does not explicitly state when to use it versus alternatives. It offers no exclusions or conditions, such as 'use this to discover collection names before querying with fetch_collection_data.' The usage context is clear but not elaborated.

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

count_documentsC

Count matching documents.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No
`collection_name`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that it counts matching documents. It does not explain whether this is a read-only operation, what the return format is (e.g., a number, an object), or whether there are limits or side effects. This leaves significant ambiguity for an AI agent, especially for a sibling tool that may have similar behavior.

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 concise sentence with no redundant words, which is structurally clean and front-loaded with the main verb. However, it is almost too terse; while it scores high on conciseness, the lack of additional structure (e.g., parameter hints) prevents a perfect score.

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

Completeness2/5

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

Given the tool's context (two parameters, no output schema, no annotations, and multiple sibling tools), the description is severely incomplete. It does not specify return values, parameter requirements, or how it differs from 'find_document' and 'fetch_collection_data'. An agent would have to guess at the tool's interface and behavior, making it inadequate for reliable invocation.

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?

The schema has 0% description coverage, so the description must compensate for parameter understanding, but it fails to do so. 'Matching documents' hints at the 'query' parameter but does not mention the required 'collection_name' or how the query object is structured. The description adds minimal meaning beyond the raw schema, leaving the agent without clarification on how to supply parameters.

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

Purpose4/5

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

The description 'Count matching documents' clearly states the tool's purpose with a specific verb ('count') and resource ('documents'), and implies a query filter ('matching'). It distinguishes from sibling tools like 'find_document' and 'fetch_collection_data' by focusing on counting rather than retrieving data, though it does not explicitly name alternatives.

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 such as 'find_document' or 'fetch_collection_data'. There is no mention of use cases (e.g., obtaining counts for pagination or aggregation) or exclusions (e.g., not for retrieving documents). The absence of this differentiation leaves the agent without clear selection criteria.

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

delete_documentC

Delete matching document.

ParametersJSON Schema

Name	Required	Description	Default
`filter_query`	Yes
`collection_name`	Yes

TDQS

C2.1/5.0

Behavior1/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It fails to clarify whether the tool deletes a single document or all documents matching the filter query, what happens on no match, whether the operation is reversible, permission requirements, or what response is returned. The ambiguous 'matching document' leaves critical safety behavior unspecified.

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

Conciseness2/5

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

The description is a single terse sentence with no fluff, but it is under-specified. It lacks essential details needed for safe and correct usage, so it is not appropriately sized. The phrase 'matching document' is ambiguous and does not earn its place over a more informative 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?

For a destructive tool with no annotations, no output schema, and zero schema description coverage, the description is severely incomplete. It does not explain return values, error behavior, scope of deletion, or any operational nuances. The 2-parameter tool needs much more context to be used correctly by an agent.

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?

Schema description coverage is 0%, and the description provides no parameter explanations. The schema shows collection_name and filter_query types but no semantics for filter_query structure or how it is used. 'Matching' is the only hint, but it does not clarify the filter query format, matching logic, or limits.

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

Purpose4/5

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

The description clearly states the action ('Delete') and resource ('matching document'), and 'matching' implies the filter_query parameter. It is distinguishable from siblings like find_document, update_document, and insert_document. However, it does not explicitly mention the collection context, relying on the schema parameter collection_name.

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 is provided on when to use this tool versus alternatives. The description does not mention when deletion is appropriate, prerequisites, or contrast with find_document or update_document. It simply states the action without context.

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

fetch_collection_dataC

Fetch documents from a collection.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`collection_name`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavior, but it only states the basic action. It does not clarify whether results are paginated, how many documents are returned, or any authorization requirements.

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, clear sentence without unnecessary words, which is efficient. However, it is arguably under-specified given the tool's scope, though the dimension specifically measures conciseness rather than completeness.

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

Completeness2/5

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

The tool has no output schema and no annotations, so the description must provide sufficient context for invocation. It does not state that 'limit' defaults to 100, whether all documents are returned, or how results are structured, making it incomplete for an agent.

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?

The schema has zero description coverage for its two parameters, and the description adds no information about 'limit' or 'collection_name' beyond their names. The tool description fails to compensate for the lack of schema descriptions.

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

Purpose4/5

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

The description states the tool's action ('Fetch') and resource ('documents from a collection'), clearly indicating its primary function. However, it does not distinguish from sibling tools like find_document or count_documents, making it clear but at a generic level.

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 offers no guidance on when to use this tool vs alternatives, such as find_document for specific queries or count_documents for counting. No exclusions or prerequisites are mentioned.

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

fetch_collection_schemaB

Returns inferred schema from a sample document.

ParametersJSON Schema

Name	Required	Description	Default
`collection_name`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

The description discloses that the schema is 'inferred' and based on 'a sample document', which hints at approximate or non-exhaustive results. However, since there are no annotations, the description carries the burden for safety and behavioral context, and it does not explicitly state that the operation is read-only or without side effects. The sample-based nature adds some transparency but lacks depth.

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, front-loaded sentence that states exactly what the tool does with no wasted words. It is highly concise and easy to parse.

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?

For a simple tool with one parameter, the description is adequate but not rich. It lacks context about when to prefer this over fetch_collection_data or other siblings, and it does not clarify whether the operation is safe or read-only. However, given the minimal input schema and no output schema, the description is not severely incomplete, though it leaves room for improvement.

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?

The schema description coverage is 0%, and the description does not mention the parameter at all. While the parameter name 'collection_name' is relatively self-explanatory given the tool name, the description provides no additional meaning or context, such as the format or expected values. With low coverage, the description should compensate but fails to do so.

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's function: it returns an inferred schema from a sample document. This distinguishes it from siblings like fetch_collection_data (which fetches data) and all_collections (which lists collections). The verb 'Returns' combined with the resource 'schema' makes the purpose unambiguous.

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

Usage 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 should be used specifically for schema inspection, nor does it note any exclusions or alternative tools. Usage is only implied by the tool name and description.

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

find_documentC

Find a single document.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`collection_name`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It only states that it finds a single document, but does not explain what happens if multiple documents match, if none match, or what the return structure looks like.

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

Conciseness3/5

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

The description is a single concise sentence, making it easy to parse. However, it is overly terse and omits essential context, so it is under-specified rather than appropriately concise.

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

Completeness2/5

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

Given the tool has 2 parameters, a nested query object, and no output schema, the description provides insufficient context for an agent to know how to invoke it correctly. It lacks parameter formats, return behavior, and usage examples.

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?

The schema has two parameters with no descriptions, and the description does not explain what query or collection_name mean or how they interact. With 0% schema coverage, the description should compensate, but it remains silent on parameter semantics.

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

Purpose4/5

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

The description uses the verb 'find' and identifies the resource as a single document, clearly indicating a retrieval operation. It distinguishes itself from collection-level tools by specifying 'single', but it does not explicitly differentiate from fetch_collection_data or explain the query parameter's role.

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 like fetch_collection_data or count_documents. There is no mention of conditions, prerequisites, or exclusions.

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

insert_documentC

Insert a document.

ParametersJSON Schema

Name	Required	Description	Default
`document`	Yes
`collection_name`	Yes

TDQS

C2.3/5.0

Behavior1/5

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

With no annotations, the description carries the full burden of disclosing behavior. It only says 'Insert a document' and reveals nothing about return values, error handling, auto-generated IDs, or whether it overwrites existing documents. This is a significant gap for a mutation tool.

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

Conciseness3/5

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

The description is extremely concise with no wasted words, but it is under-specified. It is a single sentence that states the action, yet it doesn't earn its place by adding value beyond the name. It is not verbose, but lacks substance.

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?

Given that this is a CRUD tool with two required parameters, no annotations, and no output schema, the description is highly inadequate. It doesn't explain the collection context, document structure, behavior, or any edge cases. It is far from complete for an agent to use correctly.

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 description coverage is 0%, so the description must compensate, but it does not mention the parameters at all. The parameter names 'collection_name' and 'document' are somewhat self-explanatory, but no additional meaning or format details are provided, leaving room for misuse.

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

Purpose4/5

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

The description 'Insert a document' clearly identifies a specific verb and resource, making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like update_document or delete_document, though the verb itself provides distinction. It is not misleading but could be more specific about inserting into a collection.

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 doesn't mention prerequisites, when to use insert vs. update, or any conditions. The user must infer usage from the name alone.

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

update_documentC

Update matching document.

ParametersJSON Schema

Name	Required	Description	Default
`update_data`	Yes
`filter_query`	Yes
`collection_name`	Yes

TDQS

C2.2/5.0

Behavior1/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Update matching document,' which merely restates the tool's purpose. It does not state whether updates are partial or full replacements, whether multiple documents can be updated, if authentication is needed, or what the return value is.

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

Conciseness2/5

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

The description is very short (four words), but it is under-specified. It does not earn its place because it provides no information beyond what the tool name implies, and it fails to compensate for the lack of schema descriptions.

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?

For a mutation tool with 3 required parameters, no annotations, and no output schema, this description is completely inadequate. It fails to disclose merge vs replace behavior, return values, or any operational context.

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 description coverage is 0%, and the description adds minimal parameter meaning. 'matching' hints at filter_query usage, but it does not explain the format or semantics of update_data, filter_query, or collection_name. For a 3-param tool with no schema descriptions, this is insufficient.

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

Purpose4/5

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

The description states a clear action and resource: 'Update matching document.' It indicates an update operation on documents, but it does not differentiate from siblings like find_document or insert_document beyond the verb.

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 usage guidance is provided. The description does not explain when to use this tool vs alternatives like find_document, insert_document, or delete_document, nor any prerequisites for updating documents.

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.

8 tool updatesv0.1.0Jul 31, 2026
- First observedall_collections
- First observedcount_documents
- First observeddelete_document
- First observedfetch_collection_data
- First observedfetch_collection_schema
- First observedfind_document
- First observedinsert_document
- First observedupdate_document

Install Server

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

TDQS

B3/5.0

Disambiguation4/5

Most tools are clearly distinct: collection listing, schema inference, data fetching, single document find, count, insert, update, delete. The only potential overlap is between fetch_collection_data and find_document, but the former implies multiple documents while the latter explicitly targets a single document.

Naming Consistency3/5

The naming mixes patterns: 'all_collections' and 'fetch_collection_*' vs. 'find_document', 'count_documents', 'insert_document', etc. While verb-first naming is used for most, the prefixes 'all' and 'fetch_collection_' are inconsistent. Still readable and not chaotic.

Tool Count5/5

With 8 tools, the server covers the core MongoDB operations without unnecessary bloat. Each tool serves a clear purpose in the database workflow, from listing collections to CRUD operations and schema inspection.

Completeness4/5

The tool set provides comprehensive coverage for basic MongoDB interactions: listing collections, inspecting schemas, querying documents, counting, inserting, updating, and deleting. Missing advanced features like aggregation or indexing are not critical for a general-purpose MongoDB MCP server.

Maintenance

ActivityStale

ResponsivenessNo issues

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

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
Mercado PagoOAuth
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2

Related MCP Servers

MongoDB MCP Server for LLMs
Databases
rock913
A
license
Not graded
quality
D
maintenance
An MCP server that enables large language models to interact directly with MongoDB databases, allowing them to query collections, inspect schemas, and manage data through natural language.
Updated a year ago (2025-03-15 23:32 UTC)
47
MIT
MongoDB MCP Server
Databases Security
az-coder-123
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server for MongoDB operations, enabling AI assistants to interact with MongoDB databases through a standardized interface.
Updated 5 months ago (2026-03-22 16:19 UTC)
28
4
MIT
mongodb-mcp
Databases Observability
VitalyOstanin
A
license
Not graded
quality
A
maintenance
MCP server for comprehensive MongoDB integration, enabling database operations, document management, schema analysis, and query tools.
Updated 13 days ago (2026-08-24 03:07 UTC)
21
MIT
MongoDB MCP
Databases Search Developer Tools
raviraj-ntp
A
license
Not graded
quality
B
maintenance
Feature-rich MCP server for MongoDB with multi-connection support, enabling users to interact with multiple MongoDB clusters simultaneously, perform CRUD operations, run aggregations, diagnostics, and more, all through natural language.
Updated 2 months ago (2026-07-09 18:12 UTC)
16
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/vishnuweb-a/mongo_agent_mcp'

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