MongoDB MCP

by vishnuweb-a

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 2.7/5 across 8 of 8 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mongo_agent_mcp MCP server](https://glama.ai/mcp/servers/vishnuweb-a/mongo_agent_mcp/badges/card.svg)](https://glama.ai/mcp/servers/vishnuweb-a/mongo_agent_mcp)

Score Badge

Copy to your README.md:

[![mongo_agent_mcp MCP server](https://glama.ai/mcp/servers/vishnuweb-a/mongo_agent_mcp/badges/score.svg)](https://glama.ai/mcp/servers/vishnuweb-a/mongo_agent_mcp)

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