MongoDB That Works - MCP Server

Server Quality Checklist

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

Latest release: v0.1.8
Disambiguation5/5
Each tool targets a distinct MongoDB operation: find vs findOne are clearly differentiated (multiple vs single document), and aggregate, count, distinct, listCollections, insertOne, updateOne, deleteOne, and getSchema have no overlapping responsibilities. The descriptions clarify the purpose of each, leaving no ambiguity for an agent.
Naming Consistency5/5
All tool names follow a consistent lowerCamelCase convention with a verb-first pattern (find, findOne, aggregate, count, distinct, listCollections, insertOne, updateOne, deleteOne, getSchema). The style is uniform and predictable, making it easy to infer tool behavior from the name.
Tool Count5/5
With 10 tools, the server is well-scoped for a MongoDB interface. It covers querying, aggregation, schema inspection, and basic CRUD operations without unnecessary bloat. Each tool serves a clear purpose, and the count is ideal for an MCP server of this domain.
Completeness4/5
The tool surface covers the core CRUD operations (insertOne, updateOne, deleteOne, find, findOne) and includes useful extras like aggregate, count, distinct, and getSchema. However, it lacks bulk operations (insertMany, updateMany, deleteMany) and collection management (createCollection, dropCollection), which are common in MongoDB workflows. These are minor gaps that an agent can work around by composing single-document calls, but they are noticeable.
Average 3.5/5 across 10 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on September 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. However, the description adds no extra behavioral context—no mention of return value, error behavior if no document matches, or consequences of the upsert option. It contributes nothing beyond the schema and annotations.
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?
A single, clear sentence with no redundant words. It is appropriately sized for a simple tool and front-loads the core purpose.
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?
For a mutation tool with destructiveHint, this is under-specified. There is no output schema, so the description should explain what the tool returns (e.g., modified count, updated document) and how it handles non-matching filters or upsert behavior. The tool also has nested objects, but the schema covers those. Overall, the description leaves important operational details unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (collection, filter, update, upsert) are documented in the schema. The description adds no parameter details, but the baseline of 3 applies because the schema carries the full load.
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?
States a specific verb (Update) and resource (a single document in a MongoDB collection). It clearly differentiates from read siblings (find, findOne) and delete (deleteOne) by its action, though it doesn't explicitly contrast with insertOne or mention that it targets exactly one document.
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 versus alternatives. It doesn't mention when to prefer updateOne over insertOne (if document may not exist), or over bulk update operations. The sibling list implies context, but the description provides no explicit routing.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior, and the description is consistent with these. However, the description adds no extra behavioral context such as return type, potential performance implications, or pipeline limitations, which would be useful beyond the annotations.
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 with no filler, directly stating the core functionality. It is front-loaded with the action and resource, making it immediately clear what the tool does.
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?
Given the simplicity of the tool and the presence of annotations and complete schema, the description is adequate but not rich. It does not mention return values or explain pipeline structure, but for an aggregation tool this is not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters (collection, pipeline, limit) with 100% coverage, so the description adds no additional meaning. The baseline is 3, and no extra semantic detail is provided.
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 (run) and the resource (an aggregation pipeline on a MongoDB collection). It distinguishes from siblings like find by focusing on the pipeline execution, though it doesn't explicitly contrast with find or other read tools.
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 given on when to use aggregation versus alternatives such as find, distinct, or count. The description does not specify scenarios where an aggregation pipeline is preferred or mention any 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?
The annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint), but the description adds no additional behavioral context. There is no mention of what happens if multiple documents match, whether a null result is returned when no document is found, or any error semantics.
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 with no redundant filler. It is appropriately sized for a simple read tool.
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?
The complete schema and annotations make the tool minimally usable, but the description leaves unspecified the return contract and behavior for non-matches or multiple matches. Since there is no output schema, a brief note about the returned document or null would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all three parameters (filter, collection, projection), so the schema itself documents the parameters. The description adds no further parameter-specific meaning, so the baseline score 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 uses the specific verb 'Find' and specifies the resource as 'a single document in a MongoDB collection.' The word 'single' clearly distinguishes it from the sibling tool find, making the tool's scope immediately obvious.
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?
There is no guidance on when to use findOne versus the sibling find, aggregate, or count tools, and no exclusions or conditions are provided. The intended use-case is only implied by the word 'single.'
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?
Annotations already communicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, and the description adds no behavior beyond restating the insert operation. It does not disclose return value behavior, duplicate-insert consequences, or any required permissions, so it provides little value beyond the annotations.
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?
A single, concise sentence that is front-loaded and contains no filler. Every word contributes to the core meaning.
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 two-parameter tool with full schema coverage and annotations present, the description is minimally adequate. However, there is no mention of the return value or what happens on repeated insertions, and since there is no output schema, the description could usefully provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description mentions 'collection' and 'document' only as part of the sentence and adds no extra semantic detail beyond what the schema provides.
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 a specific verb ('insert') and a specific resource ('a single document into a MongoDB collection'), making the core operation clear. It is distinguishable from siblings like updateOne and deleteOne, though it does not explicitly name or contrast them.
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 word 'insert' implies this tool is for adding new documents rather than updating or deleting them, so usage is indirectly conveyed. However, there is no explicit guidance about when to prefer this over updateOne/deleteOne or any prerequisites such as needing an existing collection.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context, such as the return format (an array of distinct values) or how the optional filter interacts with the query. With annotations present, the bar is lower, but the description still fails to enrich the agent's understanding of what happens at runtime.
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, focused sentence with zero filler. It front-loads the core purpose and is appropriately sized for a simple tool.
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?
There is no output schema, so the description should specify what the tool returns. It only says 'Get distinct values', which does not clarify that the result is an array, nor does it mention that the optional filter parameter can be used to restrict the query. The filter object is described in the schema but the description never hints at its role. This leaves the agent uncertain about output structure and usage nuances, making the definition incomplete for a tool with a nested object parameter and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (field, filter, collection) are individually described in the schema. The description adds no extra meaning beyond what the schema already provides; it merely restates the purpose. The baseline of 3 applies because the schema does the heavy lifting.
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 states a specific verb ('Get'), a clear resource ('distinct values for a field in a MongoDB collection'), and the operation is unambiguous. It distinguishes from siblings like find/findOne (which return documents) and aggregate (which handles complex pipelines) by focusing on unique values.
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?
There is no guidance on when to use this tool versus alternatives such as aggregate or find. The description does not mention any exclusions, prerequisites, or conditions that would help an agent choose between distinct and other query tools. This is a single declarative sentence with no comparative context.
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?
Annotations already convey destructive and non-read-only behavior. The description adds only the 'single document' scope and does not disclose additional behavioral traits such as irreversibility, behavior when multiple documents match, or response contents.
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 with no filler. Every word contributes to identifying the operation.
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 basic two-parameter CRUD tool this is minimally adequate, but there is no output schema and the description does not mention what happens if the filter matches multiple documents or what result the caller receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so both parameters are already documented. The description adds no extra meaning about how the filter should be formed or how collection name semantics behave.
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 ('Delete') and resource ('a single document from a MongoDB collection'). It is distinct from the sibling read/update tools, though it mostly expands the tool name without adding a differentiating scope condition.
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 this tool is used when exactly one document should be removed, but it gives no explicit guidance about when to prefer it over alternatives such as updateOne or findOne. There are no stated exclusions or conditions.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds no behavioral detail such as return format or pagination, but it does not contradict annotations.
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 with no waste. It is front-loaded with the core purpose and does not repeat schema details.
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?
The description is minimal but adequate for a simple read operation given that the schema covers all parameters. However, it does not mention that it returns multiple documents or that it supports filtering/sorting, which could be relevant given the number of parameters and siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all six parameters, so the schema documents their purpose. The description adds no extra parameter context beyond what is already in the schema.
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 finds documents in a MongoDB collection, specifying the verb and resource. It distinguishes from siblings like findOne (single document) and aggregate (pipeline) by the generic 'find' action.
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 versus alternatives like findOne, aggregate, or count. The description does not mention exclusions or conditions for choosing it over siblings, leaving 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds that it enumerates collections, but does not clarify behavior such as whether system collections are included or how the optional filter affects results. No contradiction with annotations.
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?
A single sentence with no filler, front-loading the action and resource. It is as concise as possible while stating the core purpose.
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 read-only tool with a single optional parameter, the description is mostly adequate. However, the filter parameter's semantics remain vague, and with no output schema the agent gets little detail about what a successful result looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the filter parameter is documented as 'Optional filter for collections.' The description adds no additional meaning about the filter's shape, allowed keys, or filtering behavior.
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 ('List'), the resource ('collections'), and the scope ('all in the database'). It distinguishes from document-level siblings like find and count, though it does not explicitly name an alternative.
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 intended use is implied: enumerate collections rather than documents. However, there is no explicit when-to-use guidance, no exclusion of document-level tools, and no mention of how this relates to getSchema.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds little about behavior beyond the count semantics (e.g., it does not state that an omitted filter counts all documents), but it does not contradict the annotations.
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 8-word sentence with the key action and resource front-loaded. There is no filler or redundant restatement of the schema.
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 simple count tool with a 100%-described schema and read-only annotations, the description is nearly sufficient. It does not explicitly state the return value, but 'Count' strongly implies a numeric result, making the omission minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both 'collection' and 'filter'. The description references collection but adds no parameter detail beyond what the schema provides, so baseline 3 is appropriate.
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 names a specific verb ('Count'), a resource ('documents in a MongoDB collection'), and the operation is immediately distinguishable from sibling read tools like find, findOne, distinct, and aggregate. The word 'Count' makes the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is for counting documents in a collection, which is the relevant context for selecting it over find/aggregate. It does not explicitly name alternatives or state when not to use it, but the operation itself provides enough contextual guidance for a simple count.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that it returns field names with types, which is part of its behavior, but doesn't disclose that it samples documents (implied by sampleSize param) or that results are approximate. No contradiction, but no additional behavioral context beyond the purpose.
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, compact sentence that front-loads the main action ('Analyze collection structure') and the outcome ('return field names with types'). No redundant words, and it is immediately scannable by an agent.
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 simple read-only analysis tool with two well-documented parameters, the description is sufficient. It states the return content (field names with types) and the tool's purpose. It could mention that results are based on sampling (given the sampleSize parameter), but that is inferable. No output schema exists, so the description covers the essential return information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: both 'collection' and 'sampleSize' have descriptive text. The description does not add any parameter-specific details beyond what the schema provides. Since the schema already documents the parameters adequately, the baseline of 3 is appropriate.
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 purpose: analyze collection structure and return field names with types. This distinguishes it from siblings like find (returns documents), aggregate (returns computed results), and listCollections (lists collections). The verb 'analyze' is specific and the resource 'collection structure' is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for schema introspection rather than data retrieval. While it doesn't explicitly name alternatives or state when not to use it, the contrast with sibling tools is clear enough for an agent to select it appropriately. A mention of 'use this instead of find when you need structure' would make it a 5.
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

MongoDB That Works - MCP Server MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![MongoDB That Works - MCP Server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/sourabhshegane/mongodb-mcp-that-works/badges/card.svg)](https://glama.ai/mcp/servers/sourabhshegane/mongodb-mcp-that-works)

Score Badge

Copy to your README.md:

[![MongoDB That Works - MCP Server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/sourabhshegane/mongodb-mcp-that-works/badges/score.svg)](https://glama.ai/mcp/servers/sourabhshegane/mongodb-mcp-that-works)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![MongoDB That Works - MCP Server MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fsourabhshegane%2Fmongodb-mcp-that-works%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/sourabhshegane/mongodb-mcp-that-works)

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/sourabhshegane/mongodb-mcp-that-works'

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