MongoDB MCP Server
OfficialMongoDB MCP 서버
MongoDB 데이터베이스 및 MongoDB Atlas와 상호 작용하기 위한 모델 컨텍스트 프로토콜 서버입니다.
📚 목차
Related MCP server: MongoDB MCP Server for LLMs
필수 조건
Node.js(v20.10.0 이상)
지엑스피1
MongoDB 연결 문자열이나 Atlas API 자격 증명이 구성되지 않으면 서버가 시작되지 않습니다 .
서비스 계정 Atlas API 자격 증명은 Atlas 도구를 사용하는 데 필요합니다. MongoDB Atlas에서 서비스 계정을 생성하고 해당 자격 증명을 사용하여 인증할 수 있습니다. 자세한 내용은 Atlas API 액세스를 참조하세요.
MongoDB 연결 문자열이 있으면 이를 사용하여 MongoDB 인스턴스에 직접 연결할 수 있습니다.
설정
빠른 시작
대부분의 MCP 클라이언트는 MCP 서버를 추가하기 위해 구성 파일을 만들거나 수정해야 합니다.
참고: 구성 파일 구문은 클라이언트마다 다를 수 있습니다. 최신 예상 구문은 다음 링크를 참조하세요.
옵션 1: 연결 문자열 인수
인수를 통해 연결 문자열을 전달할 수 있으며, 유효한 사용자 이름과 비밀번호를 사용해야 합니다.
{
"mcpServers": {
"MongoDB": {
"command": "npx",
"args": [
"-y",
"mongodb-mcp-server",
"--connectionString",
"mongodb://localhost:27017/myDatabase"
]
}
}
}참고: 연결 문자열은 로컬 인스턴스든 Atlas 클러스터든 모든 MongoDB 클러스터에 연결하도록 구성할 수 있습니다.
옵션 2: Atlas API 자격 증명 인수
Atlas API 서비스 계정 자격 증명을 사용하세요. Atlas API 액세스 섹션의 모든 단계를 따라야 합니다.
{
"mcpServers": {
"MongoDB": {
"command": "npx",
"args": [
"-y",
"mongodb-mcp-server",
"--apiClientId",
"your-atlas-service-accounts-client-id",
"--apiClientSecret",
"your-atlas-service-accounts-client-secret"
]
}
}
}옵션 3: 명령 인수를 사용하는 독립 실행형 서비스
npx 명령을 사용하여 서버를 시작합니다.
npx -y mongodb-mcp-server --apiClientId="your-atlas-service-accounts-client-id" --apiClientSecret="your-atlas-service-accounts-client-secret"인수의 전체 목록은 구성 옵션을 참조하세요.
Atlas 서비스 계정 자격 증명을 구성하려면 Atlas API 액세스 를 참조하세요.
옵션 4: 환경 변수를 사용하는 독립 실행형 서비스
npx -y mongodb-mcp-server구성 파일에서 환경 변수를 사용하거나 환경 변수를 설정하고 npx를 통해 서버를 실행할 수 있습니다.
🛠️ 지원 도구
도구 목록
MongoDB Atlas 도구
atlas-list-orgs- MongoDB Atlas 조직 목록atlas-list-projects- MongoDB Atlas 프로젝트 목록atlas-create-project- 새로운 MongoDB Atlas 프로젝트를 생성합니다.atlas-list-clusters- MongoDB Atlas 클러스터 목록atlas-inspect-cluster- 특정 MongoDB Atlas 클러스터 검사atlas-create-free-cluster- 무료 MongoDB Atlas 클러스터 만들기atlas-connect-cluster- MongoDB Atlas 클러스터에 연결합니다.atlas-inspect-access-list- MongoDB Atlas 클러스터에 액세스하여 IP/CIDR 범위를 검사합니다.atlas-create-access-list- MongoDB Atlas 클러스터에 대한 IP/CIDR 액세스 목록 구성atlas-list-db-users- MongoDB Atlas 데이터베이스 사용자 목록atlas-create-db-user- MongoDB Atlas 데이터베이스 사용자를 생성합니다.atlas-list-alerts- 프로젝트에 대한 MongoDB Atlas 알림 목록
참고: Atlas 도구는 구성 섹션에서 자격 증명을 설정한 경우에만 사용할 수 있습니다.
MongoDB 데이터베이스 도구
connect- MongoDB 인스턴스에 연결find- MongoDB 컬렉션에 대해 find 쿼리를 실행합니다.aggregate- MongoDB 컬렉션에 대한 집계 실행count- MongoDB 컬렉션에 있는 문서 수를 가져옵니다.insert-one- MongoDB 컬렉션에 단일 문서 삽입insert-many- MongoDB 컬렉션에 여러 문서 삽입create-index- MongoDB 컬렉션에 대한 인덱스를 생성합니다.update-one- MongoDB 컬렉션의 단일 문서 업데이트update-many- MongoDB 컬렉션의 여러 문서 업데이트rename-collection- MongoDB 컬렉션 이름 바꾸기delete-one- MongoDB 컬렉션에서 단일 문서 삭제delete-many- MongoDB 컬렉션에서 여러 문서 삭제drop-collection- MongoDB 데이터베이스에서 컬렉션 제거drop-database- MongoDB 데이터베이스 제거list-databases- MongoDB 연결에 대한 모든 데이터베이스 나열list-collections- 주어진 데이터베이스에 대한 모든 컬렉션을 나열합니다.collection-indexes- 컬렉션의 인덱스를 설명합니다.collection-schema- 컬렉션의 스키마를 설명합니다.collection-storage-size- 컬렉션 크기를 MB 단위로 가져옵니다.db-stats- MongoDB 데이터베이스에 대한 통계를 반환합니다.
구성
MongoDB MCP 서버는 여러 가지 방법을 사용하여 구성할 수 있으며, 우선순위는 다음과 같습니다(가장 높은 것부터 가장 낮은 것까지):
명령줄 인수
환경 변수
구성 옵션
옵션 | 설명 |
| 인증을 위한 Atlas API 클라이언트 ID |
| 인증을 위한 Atlas API 클라이언트 비밀번호 |
| 직접 데이터베이스 연결을 위한 MongoDB 연결 문자열(선택 사항 사용자는 모든 도구 호출 시 이를 알리도록 선택할 수 있음) |
| 로그를 저장할 폴더 |
| 비활성화될 도구 이름, 작업 유형 및/또는 도구 범주의 배열 |
| true로 설정하면 읽기 및 메타데이터 작업 유형만 허용되고 생성/업데이트/삭제 작업은 비활성화됩니다. |
| 비활성화로 설정하면 원격 측정 수집이 비활성화됩니다. |
로그 경로
기본 로그 위치는 다음과 같습니다.
윈도우:
%LOCALAPPDATA%\mongodb\mongodb-mcp\.app-logsmacOS/Linux:
~/.mongodb/mongodb-mcp/.app-logs
장애인 도구
disabledTools 옵션을 사용하여 특정 도구 또는 도구 범주를 비활성화할 수 있습니다. 이 옵션은 문자열 배열을 허용하며, 각 문자열은 도구 이름, 작업 유형 또는 범주일 수 있습니다.
배열이 구성되는 방식은 사용하는 구성 방법의 유형에 따라 달라집니다.
환경 변수 를 구성하려면 쉼표로 구분된 문자열을 사용하세요:
export MDB_MCP_DISABLED_TOOLS="create,update,delete,atlas,collectionSchema".명령줄 인수 구성의 경우 공백으로 구분된 문자열을 사용하세요:
--disabledTools create update delete atlas collectionSchema.
도구의 종류:
atlas- MongoDB Atlas 도구(클러스터 목록, 클러스터 생성 등)mongodb- 찾기, 집계 등의 MongoDB 데이터베이스 도구
작업 유형:
create- 클러스터 생성, 문서 삽입 등과 같이 리소스를 생성하는 도구입니다.update- 문서 업데이트, 컬렉션 이름 변경 등 리소스를 업데이트하는 도구입니다.delete- 문서 삭제, 컬렉션 삭제 등 리소스를 삭제하는 도구입니다.read- 찾기, 집계, 클러스터 나열 등과 같이 리소스를 읽는 도구입니다.metadata- 목록 데이터베이스, 목록 컬렉션, 컬렉션 스키마 등과 같은 메타데이터를 읽는 도구입니다.
읽기 전용 모드
readOnly 구성 옵션을 사용하면 MCP 서버가 "읽기" 및 "메타데이터" 작업 유형을 가진 도구만 사용하도록 제한할 수 있습니다. 이 옵션을 활성화하면 "생성", "업데이트" 또는 "삭제" 작업 유형을 가진 모든 도구가 서버에 등록되지 않습니다.
이 기능은 데이터나 인프라를 수정하지 않고도 분석을 위해 MongoDB 데이터에 대한 액세스를 제공하려는 경우에 유용합니다.
다음을 사용하여 읽기 전용 모드를 활성화할 수 있습니다.
환경 변수 :
export MDB_MCP_READ_ONLY=true명령줄 인수 :
--readOnly
읽기 전용 모드가 활성화되어 있으면 이 제한으로 인해 어떤 도구가 등록되지 않았는지 알려주는 메시지가 서버 로그에 표시됩니다.
원격 측정
telemetry 구성 옵션을 사용하면 원격 측정 데이터 수집을 비활성화할 수 있습니다. 활성화하면 MCP 서버가 사용 데이터를 수집하여 MongoDB로 전송합니다.
다음을 사용하여 원격 측정을 비활성화할 수 있습니다.
환경 변수 :
export MDB_MCP_TELEMETRY=disabled명령줄 인수 :
--telemetry disabledDO_NOT_TRACK 환경 변수 :
export DO_NOT_TRACK=1
Atlas API 액세스
Atlas API 도구를 사용하려면 MongoDB Atlas에 서비스 계정을 만들어야 합니다.
서비스 계정 만들기:
cloud.mongodb.com 에서 MongoDB Atlas에 로그인하세요.
액세스 관리자 > 조직 액세스로 이동합니다.
새로 추가 > 애플리케이션 > 서비스 계정을 클릭합니다.
서비스 계정의 이름, 설명 및 만료일을 입력하세요(예: "MCP, MCP 서버 액세스, 7일").
적절한 권한을 선택하세요(전체 액세스의 경우 조직 소유자 사용)
"만들기"를 클릭하세요
서비스 계정에 대해 자세히 알아보려면 MongoDB Atlas 문서를 확인하세요.
클라이언트 자격 증명 저장:
생성 후 클라이언트 ID와 클라이언트 비밀번호가 표시됩니다.
중요: 클라이언트 비밀번호는 다시 표시되지 않으므로 즉시 복사하여 저장하세요.
액세스 목록 항목 추가:
API 액세스 목록에 IP 주소를 추가하세요
MCP 서버 구성:
아래 구성 방법 중 하나를 사용하여
apiClientId및apiClientSecret설정하세요.
구성 방법
환경 변수
대문자로 옵션 이름을 붙이고 MDB_MCP_ 접두사를 붙여 환경 변수를 설정합니다. 뒤에 밑줄을 붙입니다.
# Set Atlas API credentials (via Service Accounts)
export MDB_MCP_API_CLIENT_ID="your-atlas-service-accounts-client-id"
export MDB_MCP_API_CLIENT_SECRET="your-atlas-service-accounts-client-secret"
# Set a custom MongoDB connection string
export MDB_MCP_CONNECTION_STRING="mongodb+srv://username:password@cluster.mongodb.net/myDatabase"
export MDB_MCP_LOG_PATH="/path/to/logs"
MCP 구성 파일 예제
환경 변수가 있는 연결 문자열
{
"mcpServers": {
"MongoDB": {
"command": "npx",
"args": ["-y", "mongodb-mcp-server"],
"env": {
"MDB_MCP_CONNECTION_STRING": "mongodb+srv://username:password@cluster.mongodb.net/myDatabase"
}
}
}
}환경 변수가 포함된 Atlas API 자격 증명
{
"mcpServers": {
"MongoDB": {
"command": "npx",
"args": ["-y", "mongodb-mcp-server"],
"env": {
"MDB_MCP_API_CLIENT_ID": "your-atlas-service-accounts-client-id",
"MDB_MCP_API_CLIENT_SECRET": "your-atlas-service-accounts-client-secret"
}
}
}
}명령줄 인수
서버를 시작할 때 구성 옵션을 명령줄 인수로 전달합니다.
npx -y mongodb-mcp-server --apiClientId="your-atlas-service-accounts-client-id" --apiClientSecret="your-atlas-service-accounts-client-secret" --connectionString="mongodb+srv://username:password@cluster.mongodb.net/myDatabase" --logPath=/path/to/logsMCP 구성 파일 예제
명령줄 인수가 있는 연결 문자열
{
"mcpServers": {
"MongoDB": {
"command": "npx",
"args": [
"-y",
"mongodb-mcp-server",
"--connectionString",
"mongodb+srv://username:password@cluster.mongodb.net/myDatabase"
]
}
}
}명령줄 인수가 포함된 Atlas API 자격 증명
{
"mcpServers": {
"MongoDB": {
"command": "npx",
"args": [
"-y",
"mongodb-mcp-server",
"--apiClientId",
"your-atlas-service-accounts-client-id",
"--apiClientSecret",
"your-atlas-service-accounts-client-secret"
]
}
}
}🤝 기여하기
기여하고 싶으신가요? 좋습니다! 코드 기여, 표준, 새 도구 추가 및 문제 해결 정보에 대한 지침은 기여 가이드를 참조하세요.
Available Tools
28 toolsaggregateARead-only
Run an aggregation against a MongoDB collection
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name | |
| pipeline | Yes | An array of aggregation stages to execute. If the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage of the pipeline (or the first stage of a `$unionWith` sub-pipeline only when explicitly combining unrelated result sets — for hybrid full-text + vector search, use `$rankFusion` or `$scoreFusion` instead, see below). If the user has asked for lexical/Atlas search, use `$search` instead of `$text`. ### Usage Rules for `$vectorSearch` - **Index Type Detection:** Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed'). - **Classic Vector Search (type: 'vector'):** Use 'queryVector' with embeddings as an array of numbers. - **Auto-Embed Vector Search (type: 'autoEmbed'):** Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes. - **Unset embeddings:** Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**. - **Pre-filtering:** If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index. NEVER include fields in $vectorSearch.filter that are not part of the vector index. - **Post-filtering:** For all remaining filters, add a $match stage after $vectorSearch. - If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields. - If no requested filters are valid prefilters, omit the filter key from $vectorSearch. ### Usage Rules for `$search` - Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name. - The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the appropriate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/ ### Usage Rules for `$rankFusion` and `$scoreFusion` (Hybrid Search) Use these stages when the user wants to combine full-text (`$search`) and vector (`$vectorSearch`) retrieval into a single fused result set. **Prefer native fusion over a `$unionWith` + `$group` workaround** — the workaround averages incompatible score scales and produces wrong rankings. **Which stage to use:** - `$rankFusion` (MongoDB 8.0+) — Reciprocal Rank Fusion. The recommended default. Normalizes scores across incompatible scales automatically. No score tuning needed. - `$scoreFusion` (MongoDB 8.2+) — Score-based fusion. Use when the user needs explicit per-pipeline weights, score normalisation (sigmoid / minMaxScaler), or a custom combination expression. **Construction rules:** - `$rankFusion` / `$scoreFusion` MUST be the first stage of the top-level pipeline. - Sub-pipelines go inside `input.pipelines` as a named map (not an array). Each name must be non-empty, must not start with `$`, and must not contain `.` or null bytes. - Allowed stages inside sub-pipelines: `$search`, `$vectorSearch`, `$match`, `$sort`, `$geoNear`, `$skip`, `$limit`. `$project` and `$unset` are NOT allowed inside sub-pipelines. - Do field shaping (`$project` / `$unset`) only AFTER the fusion stage, at the root. - Both a vectorSearch (or autoEmbed) index AND a search (lexical) index must exist on the collection. Use the collection-indexes tool to confirm both before running a hybrid query. - Add a `$limit` stage after the fusion stage to cap the final result set. - Add `$unset` at the end to remove embedding fields and avoid context bloat. ### Usage Rules for `$rerank` (Native Reranking) Use this stage when the user wants to reorder a set of candidate documents using a cross-encoder reranker model. **Construction rules:** - `$rerank` can be any stage in the pipeline on an Atlas cluster running MongoDB 8.3 or higher. - It is recommended to use `$rerank` after a sorted pipeline, e.g. `$search`, `$vectorSearch`, `$rankFusion`, `$scoreFusion`, or [`$match`, `$sort`]. - $rerank must be enabled via the Native Reranking Project Setting - Set `numDocsToRerank` as the number of documents passed into `$rerank`. This will also limit the number of documents returned by `$rerank` - Set `path` as a field name or an array of field names that exist in all documents. Use `$match` or `$set` before `$rerank` to validate no fields are missing. - Add `$addFields` after `$rerank` to retrieve the reranker score. **`$rerank` example (recommended default):** ```javascript [ { $match: { description: { $exists: true }, name: { $exists: true } } }, { $sort: { lastUpdated: -1 } }, { $rerank: { query: { text: "query text including instructions" }, model: "rerank-2.5", numDocsToRerank: 100, path: ["description", "name"] } }, { $addFields: { rerankScore: { $meta: "score" } } } ] ``` | |
| collection | Yes | Collection name | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. | |
| responseBytesLimit | No | The maximum number of bytes to return in the response. This value is capped by the server's configured maximum and cannot be exceeded. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | The total number of documents returned by the aggregation pipeline |
| documents | Yes | The documents returned by the aggregation pipeline |
| appliedLimits | Yes | The limits applied to the aggregation pipeline |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description itself adds no additional behavioral context, though the schema's pipeline description does disclose mandatory $unset stages and response size limits, which are not in annotations. The description alone is transparent but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is concise but minimal, while the pipeline parameter description is extremely long (several hundred words), albeit well-organized with section headers and an example. Some instructions are repeated (e.g., 'use the collection-indexes tool') and the length may challenge readability, though it is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, and the pipeline description covers advanced features (vector search, hybrid fusion, reranking) and mentions responseBytesLimit. However, the tool-level description lacks a high-level overview of what aggregation can do or when to prefer it over simpler tools, leaving some context to the AI agent's prior knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The pipeline parameter description is exceptionally detailed, covering $vectorSearch with classic and auto-embed variants, $search, $rankFusion, $scoreFusion, $rerank, pre/post-filtering rules, and mandatory $unset. This goes far beyond the basic schema and provides essential operational guidance for complex aggregations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run an aggregation against a MongoDB collection' uses a specific verb+resource and clearly distinguishes from the sibling tool 'aggregate-db' by explicitly targeting a collection. It unambiguously communicates the core operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like 'find' or 'count', and no exclusions are mentioned. The extensive pipeline rules in the schema cover how to build an aggregation but not when to choose this tool over siblings, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aggregate-dbCRead-only
Run an aggregation against a MongoDB database
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name | |
| pipeline | Yes | An array of aggregation stages to execute. The first stage must be a database-level aggregation stage (one of `$changeStream`, `$currentOp`, `$documents`, `$listLocalSessions`, `$queryStats`). https://www.mongodb.com/docs/manual/reference/mql/aggregation-stages/#db.aggregate---stages | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. | |
| responseBytesLimit | No | The maximum number of bytes to return in the response. This value is capped by the server's configured maximum and cannot be exceeded. |
Output Schema
| Name | Required | Description |
|---|---|---|
| documents | Yes | The documents returned by the aggregation pipeline |
| appliedLimits | Yes | The limits applied to the aggregation pipeline |
| aggResultsCount | No | The total number of documents returned by the aggregation pipeline |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds no additional behavioral context such as side effects, permissions, output format, or performance implications. With annotations present, the description is neutral but does not enrich understanding beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the tool's purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool invoking arbitrary MongoDB aggregation pipelines, the description lacks context about database-level vs collection-level operations, when to use it, or the requirement for the first stage. The sibling tool 'aggregate' creates ambiguity. The schema and output schema provide technical detail, but the description fails to orient the agent adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters, so the schema carries the parameter documentation. The description itself does not mention any parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an aggregation against a MongoDB database, providing a specific verb and resource. However, it does not differentiate from the sibling tool 'aggregate', which likely refers to a collection-level aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives such as 'aggregate'. The schema mentions the pipeline must start with database-level stages, but this is not in the tool description and does not constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-connect-clusterARead-only
Connect to MongoDB Atlas cluster and get back a connectionId to pass to the other MongoDB tools. Each call establishes a new, independent connection — multiple connections can be active at the same time.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | Atlas project ID | |
| clusterName | Yes | Atlas cluster name | |
| connectionType | No | Type of connection (standard, private, or privateEndpoint) to an Atlas cluster | standard |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| connectionId | Yes | |
| addedCurrentIp | Yes | |
| sharedTierTier | No | |
| sharedTierAlerts | No | |
| createdTemporaryUser | Yes | |
| sharedTierAlertsDetected | No | |
| temporaryUserClarification | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, while the description adds behavioral context by stating each call establishes a new independent connection and that multiple connections can be active simultaneously. This adds value beyond the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two sentences that front-load the core action and return value. There is no filler or redundant repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, return value, and the key behavioral nuance of independent connections. Given the presence of an output schema and annotations, this is enough for a simple connect tool. It lacks details on cleanup or connection limits, but these are not critical for an initial selection decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have complete descriptions in the schema, so the description does not need to elaborate on them. The baseline of 3 is appropriate because the schema covers parameter semantics fully, and the description adds no extra parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool connects to a MongoDB Atlas cluster and returns a connectionId for use with other MongoDB tools, identifying the specific action and resource. It does not explicitly distinguish this from the sibling 'connect' tool, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description frames usage through the connectionId flow for other tools and notes that every call creates a new independent connection. It provides clear context but does not mention alternatives or exclusions, such as when to use 'connect' or 'disconnect'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-get-performance-advisorARead-only
Get MongoDB Atlas performance advisor recommendations and suggestions, which includes the operations: suggested indexes, drop index suggestions, schema suggestions, and a sample of the most recent (max 50) slow query logs
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Date to get slow query logs since. Must be a string in ISO 8601 format. Only relevant for the slowQueryLogs operation. | |
| projectId | Yes | Atlas project ID to get performance advisor recommendations. The project ID is a hexadecimal identifier of 24 characters. If the user has only specified the name, use the `atlas-list-projects` tool to retrieve the user's projects with their ids. | |
| namespaces | No | Namespaces to get slow query logs. Only relevant for the slowQueryLogs operation. | |
| operations | No | Operations to get performance advisor recommendations | |
| clusterName | Yes | Atlas cluster name to get performance advisor recommendations |
Output Schema
| Name | Required | Description |
|---|---|---|
| projectId | Yes | |
| clusterName | Yes | |
| slowQueryLogs | No | |
| suggestedIndexes | No | |
| schemaSuggestions | No | |
| dropIndexSuggestions | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by specifying that it returns a sample of the most recent slow query logs (max 50) and listing the types of recommendations, which gives insight into response content 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It efficiently conveys the tool's purpose and main included features, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters) and the presence of an output schema, the description does not need to explain return values. The description, combined with the schema's parameter documentation, provides sufficient context for an agent to invoke the tool correctly. A minor gap is that the description doesn't mention parameter interdependencies (e.g., 'since' only relevant for slowQueryLogs), but the schema covers this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning each parameter is documented in the schema. The description does not add further meaning to the parameters themselves, so the baseline score of 3 applies. The description's mention of 'operations' aligns with the schema's operation enum, but no additional semantic detail is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('MongoDB Atlas performance advisor recommendations and suggestions'), and enumerates the specific operations included (suggested indexes, drop index suggestions, schema suggestions, slow query logs). This distinguishes it from all sibling tools, none of which cover performance advisor functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. However, the schema descriptions for parameters (e.g., projectId suggests using atlas-list-projects if only name is known) offer some contextual usage hints, but the tool description itself lacks this. Usage context is only implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-inspect-access-listARead-only
Inspect Ip/CIDR ranges with access to your MongoDB Atlas clusters.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | Atlas project ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| entries | Yes | |
| projectId | Yes | |
| totalCount | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context (e.g., authentication requirements, rate limits, or side effects) beyond what the annotations already convey. It only restates the inspect action, which is consistent with the read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence that delivers the core purpose without unnecessary words. It is efficient and easy to parse, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present) and strong annotations, the description is nearly complete. It could have explicitly mentioned that it lists the access list entries, but the current phrasing along with the output schema sufficiently conveys the expected behavior. Minor ambiguity exists in the phrase 'with access to your MongoDB Atlas clusters,' but it does not hinder usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter (projectId) with full description coverage (100%), and the description does not add any additional meaning about the parameter. Since schema coverage is high, the baseline of 3 applies; the description contributes no extra parameter-level insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Inspect') and a well-defined resource ('Ip/CIDR ranges with access to your MongoDB Atlas clusters'), which aligns with its name. This distinguishes it from sibling tools like atlas-inspect-cluster, which targets cluster configuration rather than access lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting access list entries but does not provide explicit context for when to choose this tool over alternatives such as atlas-inspect-cluster. There is no mention of exclusions or sibling comparisons, leaving the agent to infer the tool's role from its name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-inspect-clusterBRead-only
Inspect metadata of a MongoDB Atlas cluster
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | Atlas project ID | |
| clusterName | Yes | Atlas cluster name |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| state | Yes | |
| paused | Yes | |
| region | No | |
| provider | No | |
| instanceSize | Yes | |
| instanceType | Yes | |
| mongoDBVersion | Yes | |
| connectionStrings | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description 'Inspect metadata' aligns with the readOnlyHint and destructiveHint annotations, but adds no behavioral context beyond what the annotations already declare. It does not disclose additional details such as return format, limitations, or any special behaviors. Since it provides no new information beyond the structured annotations, it falls short of adding value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Inspect' and contains no redundant words. It is concise and effectively communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of readOnlyHint and destructiveHint annotations, full schema description coverage, and an output schema, the description is adequate for a simple metadata inspection tool. It could have explicitly contrasted with atlas-list-clusters to aid selection, but the structured data sufficiently covers the essential selection context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('Atlas project ID' and 'Atlas cluster name'), so the schema already provides sufficient semantics. The description does not add any additional parameter-level detail beyond what is already structured, but this is acceptable given the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Inspect' and clearly identifies the resource as 'metadata of a MongoDB Atlas cluster', specifying a single cluster scope. This distinguishes it from sibling tools like atlas-list-clusters and atlas-connect-cluster, which are not about inspecting detailed metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 exclusions, prerequisites, or scenarios where another tool would be more appropriate, leaving the agent to infer usage solely from the tool's name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-list-alertsARead-only
List triggered alerts for a MongoDB Atlas project. These are alerts Atlas has raised, not the alert configurations that define them. Defaults to OPEN alerts; set status to TRACKING or CLOSED to see others.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per page. | |
| status | No | Status of the alerts to return. Defaults to OPEN. TRACKING means the alert condition exists but hasn't persisted beyond the notification delay. OPEN means the alert condition currently exists. CLOSED means the alert has been resolved. | OPEN |
| pageNum | No | Page number. | |
| projectId | Yes | Atlas project ID to list alerts for |
Output Schema
| Name | Required | Description |
|---|---|---|
| alerts | Yes | |
| status | Yes | |
| projectId | Yes | |
| totalCount | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds valuable context beyond that: it clarifies that the tool returns raised alerts rather than configurations, and explains the default status behavior. This is useful behavioral information an agent would not infer from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and directly follows with the key distinction and status guidance. Every sentence earns its place, with no redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list operation with a full schema and output schema. The description adequately covers the essential context—what alerts are returned, how to filter them, and the distinction from configurations—making it complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage with descriptions, including detailed enum semantics for status. The description echoes the default status but does not introduce any new parameter meaning beyond what the schema already contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action and resource: 'List triggered alerts for a MongoDB Atlas project.' The second sentence disambiguates from alert configurations, making the purpose specific and distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what is being listed (triggered alerts) and how to use the status parameter (defaults to OPEN; set to TRACKING or CLOSED for others). It does not explicitly name an alternative tool, but the distinction from configurations guides correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-list-clustersBRead-only
List MongoDB Atlas clusters
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Atlas project ID to filter clusters |
Output Schema
| Name | Required | Description |
|---|---|---|
| clusters | Yes | |
| projectId | No | |
| totalCount | Yes | |
| projectName | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond the tool name, such as optional filtering, output scope, pagination, or authentication requirements. It does not contradict annotations, but it contributes nothing new.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler or unnecessary detail. It is maximally concise, though it essentially restates the tool name without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 optional parameter, full schema coverage, output schema present, and read-only annotations), so the minimal description combined with structured fields is sufficient for basic invocation. It would benefit from explicitly noting that omitting projectId returns clusters across accessible projects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage and clearly describes the single projectId parameter ('Atlas project ID to filter clusters'). The description adds no parameter-level information, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('MongoDB Atlas clusters'), making the core operation clear. It does not mention the optional projectId filter that would scope results, so it lacks some specificity but is still distinctly about listing clusters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 over siblings such as atlas-inspect-cluster (for cluster details) or atlas-list-projects (for project IDs). The description provides zero context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-list-db-usersARead-only
List MongoDB Atlas database users
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | Atlas project ID to filter DB users |
Output Schema
| Name | Required | Description |
|---|---|---|
| users | Yes | |
| projectId | Yes | |
| totalCount | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no additional behavioral context such as pagination, return format, authentication needs, or rate limits. With annotations covering the safety profile, a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is immediately clear and front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema provided. The description is minimal but adequate when combined with the annotations and schema. It could explicitly mention that the listing is scoped to a project, but the schema already communicates this, so the overall context is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents projectId with a description and validation pattern, giving 100% schema coverage. The description does not mention parameters, but the schema carries the burden. Baseline 3 is appropriate since the description does not add extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('MongoDB Atlas database users'). It distinguishes itself from sibling tools like atlas-list-clusters, atlas-list-projects, and atlas-list-alerts by specifying the exact entity being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no exclusions, and no context about the required projectId. It merely states the action without any usage policy, leaving the agent to infer the appropriate context from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-list-orgsBRead-only
List MongoDB Atlas organizations
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of organizations to return per page. | |
| pageNum | No | Page number of organizations to return. |
Output Schema
| Name | Required | Description |
|---|---|---|
| totalCount | Yes | |
| organizations | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. However, the description adds no behavioral context beyond the basic 'list' action, such as pagination behavior or scope limitations. It does not contradict annotations, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose with zero superfluous words. It is appropriately sized for a simple list operation, though it could have added a bit more context without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with only two optional parameters well-documented in the schema, and the annotations cover safety. However, the description lacks any usage guidance or behavioral details, and while an output schema exists, additional context about when to use this tool versus alternatives would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (limit and pageNum) with constraints and defaults, achieving 100% schema coverage. The description does not add any extra meaning beyond what the schema already documents, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List MongoDB Atlas organizations' clearly states the verb (list) and the resource (MongoDB Atlas organizations), distinguishing it from sibling tools that operate on projects, clusters, alerts, etc. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention any exclusions or prerequisites. It simply states what the tool does, leaving the usage context entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-list-projectsBRead-only
List MongoDB Atlas projects.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of projects to return per page. | |
| orgId | No | Atlas organization ID to filter projects. If not provided, projects for all orgs are returned. | |
| pageNum | No | Page number of projects to return. |
Output Schema
| Name | Required | Description |
|---|---|---|
| orgId | No | |
| projects | Yes | |
| totalCount | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no additional behavioral context such as pagination behavior, rate limits, or response structure. It essentially restates the tool name without enriching transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant words. It is efficiently front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with a rich schema and output schema, so the description does not need to explain return values. However, it lacks any mention of pagination defaults or org filtering behavior, leaving some contextual gaps that the schema only partially fills. Overall, it is minimally sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters (limit, orgId, pageNum) have detailed descriptions in the schema. The description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List MongoDB Atlas projects' uses a specific verb ('List') and resource ('MongoDB Atlas projects'), making the core purpose clear. However, it does not explicitly distinguish this from sibling tools like atlas-list-orgs or atlas-list-clusters, though the resource type itself provides differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention that orgId can filter projects or that results are paginated. There is no 'use this when' or mention of prerequisites, so the agent receives no direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
atlas-streams-discoverARead-only
Discover and inspect Atlas Stream Processing resources. Also use for 'why is my processor failing', 'what workspaces do I have', 'show processor stats', or 'check processor health'. Use 'list-workspaces' to see all workspaces in a project. Use inspect actions for details on a specific resource. Use 'diagnose-processor' for a combined health report including state, stats, connection health, and recent errors. Use 'get-networking' for PrivateLink and account details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per page for list actions. Default: 20. | |
| action | Yes | What to look up. Start with 'list-workspaces' to see available workspaces, then use inspect actions for details or 'diagnose-processor' for a health report. | |
| region | No | Cloud region. Only for 'get-networking': returns account details for the specified region. | |
| pageNum | No | Page number for list actions. Default: 1. | |
| projectId | Yes | Atlas project ID. Use atlas-list-projects to find project IDs if not available. | |
| resourceName | No | Connection or processor name. Required for 'inspect-connection', 'inspect-processor', and 'diagnose-processor'. | |
| cloudProvider | No | Cloud provider (AWS, AZURE, GCP). Only for 'get-networking': returns account details for the specified provider. | |
| workspaceName | No | Workspace name. Required for all actions except 'list-workspaces' and 'get-networking'. | |
| responseFormat | No | Response detail level. 'concise' returns names and states only. 'detailed' returns full configuration and stats. Default: 'concise' for list actions, 'detailed' for inspect/diagnose. |
Output Schema
| Name | Required | Description |
|---|---|---|
| dlq | No | |
| tier | No | |
| stats | No | |
| pipeline | No | |
| workspace | No | |
| connection | No | |
| processors | No | |
| workspaces | No | |
| connections | No | |
| privateLinks | No | |
| accountDetails | No | |
| processorState | No | |
| connectionHealth | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by explaining what the tool returns: diagnose-processor includes 'state, stats, connection health, and recent errors', and get-networking returns 'PrivateLink and account details.' This goes beyond the simple read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loaded with the primary purpose. The second sentence lists practical use cases, and the third maps specific actions to their outputs. Each sentence contributes value, though the quoted use cases add a bit of density without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 9 parameters and 8 distinct actions, the description covers the main action groups and provides a mental map for when to use each. The existence of an output schema means return-value details need not be in the description. It is complete enough for an agent to understand the tool's scope and select it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter documented in the input schema. The tool description itself does not add new parameter semantics beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair: 'Discover and inspect Atlas Stream Processing resources.' It then reinforces with concrete use cases like 'why is my processor failing' and 'what workspaces do I have', which clearly distinguishes it from sibling tools focused on other resource types. The scope is unmistakably Atlas Stream Processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit action-to-purpose mappings: 'Use list-workspaces to see all workspaces', 'Use inspect actions for details', 'Use diagnose-processor for a combined health report', and 'Use get-networking for PrivateLink and account details.' This gives clear context for when to use each action, though it does not explicitly cover when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
collection-indexesARead-only
Describe the indexes for a collection
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name | |
| collection | Yes | Collection name | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. |
Output Schema
| Name | Required | Description |
|---|---|---|
| searchIndexes | Yes | |
| classicIndexes | Yes | |
| searchIndexesCount | Yes | |
| classicIndexesCount | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral context beyond what the annotations already declare (readOnlyHint=true, destructiveHint=false). It is consistent with being a read-only operation, but lacks details about output structure or edge cases. With strong annotations, the bar is lower, but no extra context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence with no redundant information, front-loaded with the verb 'Describe'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only metadata inspection tool with a complete schema and output schema present, the description sufficiently conveys the tool's purpose. No critical information is missing for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (database, collection, connectionId), and the tool description does not add any parameter-specific meaning. With 100% schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Describe the indexes for a collection' uses a specific verb ('Describe') and identifies the resource (indexes for a collection). It is distinct from sibling tools like collection-schema and collection-storage-size, which cover different aspects of a collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 only states the tool's function without specifying prerequisites, exclusions, or alternative tools, resulting in no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
collection-schemaCRead-only
Describe the schema for a collection
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name | |
| collection | Yes | Collection name | |
| sampleSize | No | Number of documents to sample for schema inference | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. | |
| responseBytesLimit | No | The maximum number of bytes to return in the response. This value is capped by the server's configured maximum and cannot be exceeded. |
Output Schema
| Name | Required | Description |
|---|---|---|
| schema | Yes | |
| fieldsCount | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. However, the description adds no behavioral context such as document sampling, cost implications, or that the schema is inferred rather than authoritative. It essentially restates the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and is front-loaded, but it is so terse that it borders on under-specification. It is concise in length yet says little beyond the tool's name, making it only minimally valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is comprehensive and an output schema exists, but the description does not explain when to use this tool or that it infers schema by sampling documents. The sampleSize parameter hints at sampling, but the description itself provides no operational context, so completeness is adequate but lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 5 parameters, including sampleSize and responseBytesLimit, achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Describe' with the resource 'schema for a collection', clearly identifying a read-only introspection operation. It is distinguishable from sibling tools like collection-indexes or list-collections, though it stops short of mentioning that the schema is inferred from sampled documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor any exclusions or prerequisites. The description is purely definitional and leaves the agent to infer use cases from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
collection-storage-sizeBRead-only
Gets the size of the collection
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name | |
| collection | Yes | Collection name | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. |
Output Schema
| Name | Required | Description |
|---|---|---|
| size | Yes | |
| units | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as read-only and non-destructive. The description adds no behavioral context beyond that, such as units, performance implications, permission requirements, or whether the size includes indexes. It fails to disclose any nuances that could affect the agent's interpretation of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous text. It is front-loaded with the core purpose and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with clear annotations and a full parameter schema, and an output schema exists. However, the description leaves the meaning of 'size' ambiguous (e.g., storage vs. data vs. index size), which could lead to misinterpretation. The output schema may clarify returns, but the description itself is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter fully described in the input schema. The description adds no additional parameter semantics, which is acceptable given the schema already documents all three parameters (database, collection, connectionId) clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the size of a collection, using a specific verb and resource. It is distinct from sibling tools like count or collection-schema, though it does not explicitly differentiate itself or clarify what type of size (e.g., storage, data) is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like db-stats or count, nor any exclusions or prerequisites. The description simply states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connectARead-only
Connect to a MongoDB instance and get back a connectionId to pass to the other MongoDB tools. Each call establishes a new, independent connection — multiple connections can be active at the same time. A connection with the id "preconfigured" already exists for the connection string the server was configured with — there is no need to call this tool to use it.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionName | No | Optional short label for the connection (stored slugified with a short suffix, e.g. "staging" becomes staging-<suffix>). Shown in connection listings; helpful for telling multiple connections apart. | |
| connectionString | Yes | MongoDB connection string (in the mongodb:// or mongodb+srv:// format) |
Output Schema
| Name | Required | Description |
|---|---|---|
| connectionId | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: each call spawns a new independent connection and multiple can be active simultaneously. It also discloses the existence of a preconfigured connection. This goes beyond the readOnlyHint and openWorldHint annotations, though it does not detail connection cleanup or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: three sentences that front-load the primary purpose, then add behavioral details and the preconfigured exception. Every sentence contributes important information without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the presence of an output schema, and rich annotations, the description is largely complete. It explains the key behavior and the preconfigured shortcut. A minor gap is that it does not mention when to use disconnect or how connection IDs should be managed, but this is not essential for selecting the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add much parameter-specific meaning beyond the schema: connectionString is merely implied as the MongoDB URI, and connectionName is not mentioned in the description at all. The schema already provides adequate descriptions for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: connecting to a MongoDB instance and returning a connectionId for use with other MongoDB tools. It distinguishes this from siblings like list-connections and disconnect by focusing on the act of establishing a connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that a preconfigured connection exists and that there is no need to call this tool in that case, which serves as a when-not-to-use guideline. It also explains that each call creates an independent connection, implying use when a new, separate connection is desired. However, it does not discuss alternatives like atlas-connect-cluster or mention when to prefer those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
countARead-only
Gets the number of documents in a MongoDB collection using db.collection.count() and query as an optional filter parameter
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | A filter/query parameter. Allows users to filter the documents to count. Matches the syntax of the filter argument of db.collection.count(). | |
| database | Yes | Database name | |
| collection | Yes | Collection name | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | The number of documents in the collection |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing this as a safe read operation. The description adds the underlying method db.collection.count() and clarifies the query parameter, but does not disclose additional behavioral traits like performance implications or consistency guarantees. Given the annotations, the extra context is marginal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core functionality ('Gets the number of documents') and providing relevant detail about the method and filter. There is no unnecessary repetition or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the annotations covering safety, and the presence of an output schema, the description is complete. It explains the primary purpose and the optional filter, and does not leave critical gaps for a count operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description mentions query is an optional filter, which aligns with the schema but adds no new semantic information beyond what's already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts documents in a MongoDB collection, using a specific verb and resource. It differentiates from siblings like find and aggregate by focusing on count, and mentions the optional query filter. This fully clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (when you need a document count, optionally filtered), but does not explicitly mention alternatives or when not to use it. It lacks exclusion scenarios, so it falls short of a perfect score but is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
db-statsARead-only
Returns statistics that reflect the use state of a single database
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. |
Output Schema
| Name | Required | Description |
|---|---|---|
| stats | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'single database' scope and 'use state' semantics, but does not disclose details about return format or performance implications, providing minimal additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets directly to the point. Every word earns its place, with no redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters, rich annotations, and an output schema. The description covers the core purpose, and the output schema handles return value specifics. The only minor gap is the vague term 'use state', but overall the context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (database and connectionId) fully described in the schema. The description adds no parameter-specific information beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns statistics that reflect the use state of a single database', providing a specific verb and resource scope. This distinguishes it from sibling tools like list-databases or collection-storage-size, which operate at different levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusion criteria, or compare with sibling operations, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
disconnectCRead-only
Close a MongoDB connection and revoke its connectionId. Disconnecting the "preconfigured" connection only closes it — it reconnects automatically on next use because the server configuration still declares it.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The connectionId to disconnect. |
Output Schema
| Name | Required | Description |
|---|---|---|
| outcome | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations: readOnlyHint=true implies no state modification, but disconnecting and revoking a connectionId is a state-changing operation. The description does add context about auto-reconnect behavior, but the contradiction makes the behavioral transparency invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with a front-loaded verb and no filler. Every phrase earns its place, including the valuable preconfigured-connection caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although this is a simple one-parameter tool with an output schema, the description omits the return value and fails to clarify the inconsistency with readOnlyHint. It provides a useful behavioral note about auto-reconnect, but the contradictory annotation undermines overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, connectionId, is fully described in the schema (100% coverage), so the description adds no further parameter semantics. A baseline of 3 is appropriate because the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: closing a MongoDB connection and revoking its connectionId. It uses a specific verb and resource, and it is distinguishable from sibling tools like connect or list-connections, though it does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use disconnect versus alternatives, nor are exclusions or prerequisites mentioned. The caveat about the preconfigured connection is useful but not enough to orient an agent choosing among connection-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explainBRead-only
Returns statistics describing the execution of the winning plan chosen by the query optimizer for the evaluated method
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | The method and its arguments to run | |
| database | Yes | Database name | |
| verbosity | No | The verbosity of the explain plan, defaults to queryPlanner. If the user wants to know how fast is a query in execution time, use executionStats. It supports all verbosities as defined in the MongoDB Driver. | queryPlanner |
| collection | Yes | Collection name | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. |
Output Schema
| Name | Required | Description |
|---|---|---|
| method | Yes | |
| verbosity | Yes | |
| explainResult | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by clarifying that the tool returns optimizer plan statistics rather than the actual query results. Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. No contradiction exists, but the description does not disclose additional behavioral traits such as whether the query is actually executed or any cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words, front-loaded with the action 'Returns statistics,' and contains zero redundant or filler content. It is appropriately sized for a tool whose parameters are fully documented in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity of the input schema (nested method alternatives, vector search rules) and the presence of an output schema and safety annotations, the description is largely sufficient. It clearly states the tool's purpose, and the schema covers all method and parameter details. However, the lack of usage guidance is a notable gap, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for all five parameters, including the complex 'method' parameter and verbosity enum. The description itself adds no parameter-level detail, so it earns the baseline score of 3 for relying on the rich schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Returns statistics describing the execution of the winning plan chosen by the query optimizer for the evaluated method.' It clearly indicates this is an EXPLAIN-style tool for a given method. However, it does not explicitly distinguish itself from sibling tools like find or aggregate, though the nature of the output implies it is not the actual query execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 instead of find/aggregate/count for analyzing query performance, nor does it state any exclusions or prerequisites. The only hint is the tool name and the phrase 'for the evaluated method,' which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exportARead-only
Export a query or aggregation results in the specified EJSON format.
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name | |
| collection | Yes | Collection name | |
| exportTitle | Yes | A short description to uniquely identify the export. | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. | |
| exportTarget | Yes | The export target along with its arguments. | |
| jsonExportFormat | No | The format to be used when exporting collection data as EJSON with default being relaxed. relaxed: A string format that emphasizes readability and interoperability at the expense of type preservation. That is, conversion from relaxed format to BSON can lose type information. canonical: A string format that emphasizes type preservation at the expense of readability and interoperability. That is, conversion from canonical to BSON will generally preserve type information except in certain specific cases. | relaxed |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the EJSON format context, but it does not disclose what happens during export (e.g., whether results are returned as files, streamed, or stored) or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. It states the core function immediately and does not waste words, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex exportTarget parameter and no output schema, yet the description is only one sentence. It does not explain the export flow or return value (e.g., whether the tool returns a file, job ID, or stream URI), which is a significant gap given the tool's complexity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for all six parameters including the complex exportTarget structure. The description only mentions 'EJSON format', which is already captured by the jsonExportFormat parameter, so it adds no additional parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Export' and names the resource ('query or aggregation results') and the target format ('EJSON'), clearly distinguishing this tool from read-only siblings like find and aggregate. It immediately tells the agent what function the tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence implies the tool is for exporting query/aggregation results, but it gives no explicit guidance on when to prefer this over alternatives such as find/aggregate, nor any prerequisites or exclusions. The use case is inferable but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
findBRead-only
Run a find query against a MongoDB collection
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending). | |
| limit | No | The maximum number of documents to return | |
| filter | No | The query filter, matching the syntax of the query argument of db.collection.find() | |
| database | Yes | Database name | |
| collection | Yes | Collection name | |
| projection | No | The projection, matching the syntax of the projection argument of db.collection.find() | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. | |
| responseBytesLimit | No | The maximum number of bytes to return in the response. This value is capped by the server's configured maximum and cannot be exceeded. |
Output Schema
| Name | Required | Description |
|---|---|---|
| documents | Yes | The documents returned by the find query |
| appliedLimits | Yes | The limits applied to the find query |
| queryResultsCount | No | The total number of documents returned by the find query |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is safe. The description merely restates what a find query is, without adding specifics like pagination behavior, permission requirements, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is immediately clear and front-loaded, containing the essential action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema (100% parameter coverage), output schema, and annotations, the one-line description is minimally viable but lacks contextual guidance. It does not mention default limit, filtering capability, or relationship to other query tools, so an agent must rely entirely on schemas and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the schema carries the semantic load. The tool description itself does not elaborate on any parameters. Baseline 3 applies because the schema is comprehensive and the description adds no extra parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run a find query against a MongoDB collection' states a specific verb ('run'), resource ('MongoDB collection'), and operation ('find query'). This clearly distinguishes it from sibling tools like count and aggregate, which serve different retrieval purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 this is for retrieving documents, nor does it point to siblings like aggregate or count for other query types. Usage context is entirely implicit and left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-collectionsARead-only
List all collections for a given database
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. |
Output Schema
| Name | Required | Description |
|---|---|---|
| totalCount | Yes | |
| collections | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond 'for a given database' (which is already in the schema). It is consistent with annotations but does not disclose potential large result sets, pagination, or system collection inclusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of five words that conveys all essential information. It is front-loaded with the verb and resource, and every word earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema present, strong annotations), the description fully covers what the tool does. The output schema explains return values, and annotations cover side effects, so no additional context is necessary. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters 'database' and 'connectionId' are already well-documented. The description does not add any new meaning or format details beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all collections for a given database' uses a specific verb ('List'), resource ('collections'), and scope ('for a given database'), which clearly differentiates it from sibling tools like list-databases or list-connections. It fully states what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 list-databases for available databases or collection-schema for details. There is no mention of prerequisites (e.g., an active connection) or explicit exclusions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-connectionsARead-only
List the active MongoDB connections and their connectionIds. Use this to discover the "preconfigured" connection or to find a connectionId established earlier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| connections | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context by specifying it lists 'active' connections and introduces the concept of a 'preconfigured' connection, which goes beyond a generic read-only declaration. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The first states the core function, the second adds usage context. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and safe-read annotations, the description is complete. It explains the purpose, when to use it, and what to expect (connectionIds), making it fully sufficient for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. Per guidance, the baseline for 0 params is 4, and the description appropriately doesn't need to elaborate on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'active MongoDB connections and their connectionIds'. It clearly distinguishes from sibling tools like connect or disconnect by focusing on discovery of existing connections, including preconfigured ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use this to discover the preconfigured connection or to find a connectionId established earlier.' This gives clear context, though it doesn't explicitly mention when not to use it or name alternatives, which is acceptable for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-databasesARead-only
List all databases for a MongoDB connection
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. |
Output Schema
| Name | Required | Description |
|---|---|---|
| databases | Yes | |
| totalCount | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds little beyond the name, but it does confirm the operation is scoped to a connection without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, perfectly front-loaded sentence. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter, read-only tool with an output schema and clear annotations, the description is fully adequate. It states the core function, and the schema plus annotations cover the remaining context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for connectionId, including a thorough description. The tool description does not add parameter-level details, but the schema already carries the semantic weight, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all databases'), clearly scoped to 'a MongoDB connection'. This distinguishes it from sibling tools like list-collections, which targets collections within a database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: listing databases for a given connection. It does not explicitly mention alternatives or exclusions, but the context is unambiguous given the tool's name and the connectionId parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-knowledge-sourcesARead-only
List available data sources in the MongoDB Assistant knowledge base. Use this to explore available data sources or to find search filter parameters to use in search-knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'List' aligns with that. The description adds context about the tool's scope (knowledge base) and its connection to search-knowledge, which is useful behavioral information. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose. Every word earns its place, and the second sentence adds actionable guidance. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, a read-only annotation, and no output schema, the description is largely complete. It explains what the tool does and how it fits with search-knowledge. A potential gap is the lack of detail about the response format, but for a straightforward listing tool this is not a major deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline for zero params is 4. The description correctly implies no parameters are needed. Since the schema is empty, there is nothing to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available data sources in the MongoDB Assistant knowledge base. The verb 'List' and the specific resource ('data sources in the MongoDB Assistant knowledge base') make the purpose unambiguous. It also distinguishes itself from sibling listing tools by mentioning its role in supporting search-knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to explore available data sources or to find search filter parameters to use in search-knowledge.' This gives clear when-to-use guidance and even names the related tool. It does not provide explicit when-not-to-use or alternatives, but for a simple listing tool this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mongodb-logsARead-only
Returns the most recent logged mongod events
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | The type of logs to return. Global returns all recent log entries, while startupWarnings returns only warnings and errors from when the process started. | global |
| limit | No | The maximum number of log entries to return. | |
| connectionId | Yes | The connection to run the operation against. Use the id returned by one of the connect tools, or "preconfigured" to use the connection string the server was configured with. |
Output Schema
| Name | Required | Description |
|---|---|---|
| logs | Yes | |
| shownCount | Yes | |
| totalLinesWritten | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with these. It adds the 'most recent' scoping but doesn't detail ordering, pagination, or any other behavioral characteristics beyond what annotations already cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the core functionality without any extraneous words or repetition. It is perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple log retrieval tool, the description is adequate: it names the resource and the recency. The schema covers all parameters and the output schema exists, so the agent has enough information. It could be slightly more explicit about the connection requirement, but the schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (type, limit, connectionId) having meaningful descriptions including defaults, ranges, and enums. The tool description itself adds no parameter details, but the schema fully compensates, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'the most recent logged mongod events', using a specific verb ('Returns') and a well-defined resource. This distinguishes it from sibling tools like find or aggregate, which perform other database operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention any context or exclusions. It simply states what it does, leaving the agent to infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search-knowledgeARead-only
Search for information in the MongoDB Assistant knowledge base. This includes official documentation, curated expert guidance, and other resources provided by MongoDB. Supports filtering by data source and version.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of results to return | |
| query | Yes | A natural language query to search for in the MongoDB Assistant knowledge base. This should be a single question or a topic that is relevant to the user's MongoDB use case. | |
| dataSources | No | A list of one or more data sources to limit the search to. You can specify a specific version of a data source by providing the version label. If not provided, the latest version of all data sources will be searched. Available data sources and their versions can be listed by calling the list-knowledge-sources tool. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds context about the scope of the knowledge base and filtering capability, but does not disclose additional behavioral traits like return format, pagination, or potential limitations. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action ('Search for information in the MongoDB Assistant knowledge base'), followed by a concise scope expansion and capability note. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with three parameters and no output schema, the description adequately covers purpose, content scope, and filtering capability. It doesn't explain return values, but that seems acceptable for a search tool where results are expected. No significant gaps given the annotations and schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-explained (query, limit, dataSources). The description's mention of filtering by data source and version mirrors the schema's dataSources parameter but adds no extra meaning beyond what the schema already provides. The baseline of 3 applies since the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for information in the MongoDB Assistant knowledge base, explicitly listing the content types (official documentation, curated expert guidance, other resources). It distinguishes from sibling tools like find and aggregate by focusing on knowledge base resources rather than database operations, and mentions filtering by data source and version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context that this tool is for knowledge base searches, but does not explicitly state when to use it over alternatives or when not to use it. The schema mentions calling list-knowledge-sources to enumerate data sources, but the description itself lacks direct comparative guidance.
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.
28 tool updates
v2.0.0- Changed
aggregate5 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / properties / pipeline / descriptionPrevious value: -"An array of aggregation stages to execute.\nIf the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage of the pipeline, or the first stage of a `$unionWith` subpipeline.\nIf the user has asked for lexical/Atlas search, use `$search` instead of `$text`.\n### Usage Rules for `$vectorSearch`\n- **Index Type Detection:**\n Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed').\n- **Classic Vector Search (type: 'vector'):**\n Use 'queryVector' with embeddings as an array of numbers.\n- **Auto-Embed Vector Search (type: 'autoEmbed'):**\n Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes.\n- **Unset embeddings:**\n Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**.\n- **Pre-filtering:**\n If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index.\n NEVER include fields in $vectorSearch.filter that are not part of the vector index.\n- **Post-filtering:**\n For all remaining filters, add a $match stage after $vectorSearch.\n- If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields.\n- If no requested filters are valid prefilters, omit the filter key from $vectorSearch.\n\n### Usage Rules for `$search`\n- Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name.\n- The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the approprate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/\n"New value: +"An array of aggregation stages to execute.\n\nIf the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage\nof the pipeline (or the first stage of a `$unionWith` sub-pipeline only when explicitly\ncombining unrelated result sets — for hybrid full-text + vector search, use `$rankFusion`\nor `$scoreFusion` instead, see below).\n\nIf the user has asked for lexical/Atlas search, use `$search` instead of `$text`.\n### Usage Rules for `$vectorSearch`\n- **Index Type Detection:**\n Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed').\n- **Classic Vector Search (type: 'vector'):**\n Use 'queryVector' with embeddings as an array of numbers.\n- **Auto-Embed Vector Search (type: 'autoEmbed'):**\n Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes.\n- **Unset embeddings:**\n Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**.\n- **Pre-filtering:**\n If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index.\n NEVER include fields in $vectorSearch.filter that are not part of the vector index.\n- **Post-filtering:**\n For all remaining filters, add a $match stage after $vectorSearch.\n- If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields.\n- If no requested filters are valid prefilters, omit the filter key from $vectorSearch.\n\n### Usage Rules for `$search`\n- Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name.\n- The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the appropriate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/\n\n### Usage Rules for `$rankFusion` and `$scoreFusion` (Hybrid Search)\nUse these stages when the user wants to combine full-text (`$search`) and vector\n(`$vectorSearch`) retrieval into a single fused result set. **Prefer native\nfusion over a `$unionWith` + `$group` workaround** — the workaround averages\nincompatible score scales and produces wrong rankings.\n\n**Which stage to use:**\n- `$rankFusion` (MongoDB 8.0+) — Reciprocal Rank Fusion. The recommended default.\n Normalizes scores across incompatible scales automatically. No score tuning needed.\n- `$scoreFusion` (MongoDB 8.2+) — Score-based fusion. Use when the user needs explicit\n per-pipeline weights, score normalisation (sigmoid / minMaxScaler), or a custom\n combination expression.\n\n**Construction rules:**\n- `$rankFusion` / `$scoreFusion` MUST be the first stage of the top-level pipeline.\n- Sub-pipelines go inside `input.pipelines` as a named map (not an array). Each name\n must be non-empty, must not start with `$`, and must not contain `.` or null bytes.\n- Allowed stages inside sub-pipelines: `$search`, `$vectorSearch`, `$match`, `$sort`,\n `$geoNear`, `$skip`, `$limit`. `$project` and `$unset` are NOT allowed inside sub-pipelines.\n- Do field shaping (`$project` / `$unset`) only AFTER the fusion stage, at the root.\n- Both a vectorSearch (or autoEmbed) index AND a search (lexical) index must exist on\n the collection. Use the collection-indexes tool to confirm both before running a hybrid query.\n- Add a `$limit` stage after the fusion stage to cap the final result set.\n- Add `$unset` at the end to remove embedding fields and avoid context bloat.\n\n### Usage Rules for `$rerank` (Native Reranking)\nUse this stage when the user wants to reorder a set of candidate documents using a cross-encoder reranker model.\n\n**Construction rules:**\n- `$rerank` can be any stage in the pipeline on an Atlas cluster running MongoDB 8.3 or higher.\n- It is recommended to use `$rerank` after a sorted pipeline, e.g. `$search`, `$vectorSearch`, `$rankFusion`, `$scoreFusion`, or [`$match`, `$sort`].\n- $rerank must be enabled via the Native Reranking Project Setting\n- Set `numDocsToRerank` as the number of documents passed into `$rerank`. This will also limit the number of documents returned by `$rerank`\n- Set `path` as a field name or an array of field names that exist in all documents. Use `$match` or `$set` before `$rerank` to validate no fields are missing.\n- Add `$addFields` after `$rerank` to retrieve the reranker score.\n\n**`$rerank` example (recommended default):**\n```javascript\n[\n {\n $match: {\n description: { $exists: true },\n name: { $exists: true }\n }\n },\n {\n $sort: {\n lastUpdated: -1\n }\n },\n {\n $rerank: {\n query: {\n text: \"query text including instructions\"\n },\n model: \"rerank-2.5\",\n numDocsToRerank: 100,\n path: [\"description\", \"name\"]\n }\n },\n {\n $addFields: {\n rerankScore: { $meta: \"score\" }\n }\n }\n]\n```\n" - changed
Input schema / properties / responseBytesLimit / descriptionPrevious value: -"The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire aggregation result is required, use the \"export\" tool instead of increasing this limit."New value: +"The maximum number of bytes to return in the response. This value is capped by the server's configured maximum and cannot be exceeded." - changed
Input schema / requiredPrevious value: -[ - "database", - "collection", - "pipeline" -]New value: +[ + "connectionId", + "database", + "collection", + "pipeline" +]
- Changed
aggregate-db4 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / properties / responseBytesLimit / descriptionPrevious value: -"The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded."New value: +"The maximum number of bytes to return in the response. This value is capped by the server's configured maximum and cannot be exceeded." - changed
Input schema / requiredPrevious value: -[ - "database", - "pipeline" -]New value: +[ + "connectionId", + "database", + "pipeline" +]
- Changed
atlas-connect-cluster3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Output schema / properties / connectionIdAdded value: +{ + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "state", - "addedCurrentIp", - "createdTemporaryUser" -]New value: +[ + "connectionId", + "state", + "addedCurrentIp", + "createdTemporaryUser" +]
- Changed
atlas-get-performance-advisor1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
atlas-inspect-access-list1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
atlas-inspect-cluster1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
atlas-list-alerts1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
atlas-list-clusters1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
atlas-list-db-users1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
atlas-list-orgs3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / limitAdded value: +{ + "default": 10, + "description": "Max number of organizations to return per page.", + "maximum": 500, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / pageNumAdded value: +{ + "default": 1, + "description": "Page number of organizations to return.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" +}
- Changed
atlas-list-projects5 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / limitAdded value: +{ + "default": 10, + "description": "Max number of projects to return per page.", + "maximum": 500, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / pageNumAdded value: +{ + "default": 1, + "description": "Page number of projects to return.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" +} - removed
Output schema / properties / projects / items / properties / orgNameRemoved value: -{ - "type": "string" -} - changed
Output schema / properties / projects / items / requiredPrevious value: -[ - "name", - "orgId", - "orgName", - "created" -]New value: +[ + "name", + "orgId", + "created" +]
- Changed
atlas-streams-discover4 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / resourceName / maxLengthAdded value: +64 - added
Input schema / properties / resourceName / minLengthAdded value: +1 - added
Input schema / properties / resourceName / patternAdded value: +"^[a-zA-Z0-9_-]+$"
- Changed
collection-indexes3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "database", - "collection" -]New value: +[ + "connectionId", + "database", + "collection" +]
- Changed
collection-schema4 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / properties / responseBytesLimit / descriptionPrevious value: -"The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded."New value: +"The maximum number of bytes to return in the response. This value is capped by the server's configured maximum and cannot be exceeded." - changed
Input schema / requiredPrevious value: -[ - "database", - "collection" -]New value: +[ + "connectionId", + "database", + "collection" +]
- Changed
collection-storage-size3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "database", - "collection" -]New value: +[ + "connectionId", + "database", + "collection" +]
- Changed
connect5 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionNameAdded value: +{ + "description": "Optional short label for the connection (stored slugified with a short suffix, e.g. \"staging\" becomes staging-<suffix>). Shown in connection listings; helpful for telling multiple connections apart.", + "type": "string" +} - removed
Output schema / properties / connectedRemoved value: -{ - "type": "boolean" -} - added
Output schema / properties / connectionIdAdded value: +{ + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "connected" -]New value: +[ + "connectionId" +]
- Changed
count3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "database", - "collection" -]New value: +[ + "connectionId", + "database", + "collection" +]
- Changed
db-stats3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "database" -]New value: +[ + "connectionId", + "database" +]
- Added
disconnect - Changed
explain4 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / properties / method / items / oneOfPrevious value: -[ - { - "properties": { - "arguments": { - "properties": { - "pipeline": { - "description": "An array of aggregation stages to execute.\nIf the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage of the pipeline, or the first stage of a `$unionWith` subpipeline.\nIf the user has asked for lexical/Atlas search, use `$search` instead of `$text`.\n### Usage Rules for `$vectorSearch`\n- **Index Type Detection:**\n Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed').\n- **Classic Vector Search (type: 'vector'):**\n Use 'queryVector' with embeddings as an array of numbers.\n- **Auto-Embed Vector Search (type: 'autoEmbed'):**\n Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes.\n- **Unset embeddings:**\n Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**.\n- **Pre-filtering:**\n If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index.\n NEVER include fields in $vectorSearch.filter that are not part of the vector index.\n- **Post-filtering:**\n For all remaining filters, add a $match stage after $vectorSearch.\n- If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields.\n- If no requested filters are valid prefilters, omit the filter key from $vectorSearch.\n\n### Usage Rules for `$search`\n- Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name.\n- The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the approprate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/\n", - "items": { - "anyOf": [ - { - "properties": { - "$vectorSearch": { - "anyOf": [ - { - "description": "Classic vector search using 'queryVector'. Use this when the indexed field has a classic vector index (type: 'vector'). Note to LLM: Use the collection-indexes tool to verify the target field has a classic vector index before using 'queryVector'.", - "properties": { - "exact": { - "default": false, - "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", - "type": "boolean" - }, - "filter": { - "additionalProperties": {}, - "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", - "properties": {}, - "type": "object" - }, - "index": { - "description": "Name of the index, as retrieved from the `collection-indexes` tool.", - "type": "string" - }, - "limit": { - "default": 10, - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "numCandidates": { - "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "path": { - "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", - "type": "string" - }, - "queryVector": { - "description": "The vector embeddings to search for when using classic vector search indexes (type: 'vector'). Provide embeddings as an array of numbers. Use this for classic vector indexes. For auto-embed indexes (type: 'autoEmbed'), use 'query' instead.", - "items": { - "type": "number" - }, - "type": "array" - } - }, - "required": [ - "index", - "path", - "queryVector" - ], - "type": "object" - }, - { - "description": "Auto-embed vector search using 'query'. Use this when the indexed field has an auto-embed index (type: 'autoEmbed'). Note to LLM: Use the collection-indexes tool to verify the target field has an auto-embed index before using 'query'.", - "properties": { - "exact": { - "default": false, - "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", - "type": "boolean" - }, - "filter": { - "additionalProperties": {}, - "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", - "properties": {}, - "type": "object" - }, - "index": { - "description": "Name of the index, as retrieved from the `collection-indexes` tool.", - "type": "string" - }, - "limit": { - "default": 10, - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "model": { - "description": "The embedding model to use for generating embeddings from the query text. If not specified, defaults to the model configured in the auto-embed index definition.", - "enum": [ - "voyage-4", - "voyage-4-large", - "voyage-4-lite", - "voyage-code-3" - ], - "type": "string" - }, - "numCandidates": { - "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "path": { - "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", - "type": "string" - }, - "query": { - "description": "The query to search for when using auto-embed indexes (type: 'autoEmbed'). MongoDB will automatically generate embeddings for the text at query time. Use this for auto-embed indexes, not 'queryVector'.", - "properties": { - "text": { - "description": "The text query to search for.", - "type": "string" - } - }, - "required": [ - "text" - ], - "type": "object" - } - }, - "required": [ - "index", - "path", - "query" - ], - "type": "object" - } - ] - } - }, - "required": [ - "$vectorSearch" - ], - "type": "object" - }, - { - "additionalProperties": {}, - "properties": {}, - "type": "object" - } - ] - }, - "type": "array" - } - }, - "required": [ - "pipeline" - ], - "type": "object" - }, - "name": { - "const": "aggregate", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - }, - { - "properties": { - "arguments": { - "properties": { - "filter": { - "additionalProperties": {}, - "description": "The query filter, matching the syntax of the query argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "limit": { - "default": 10, - "description": "The maximum number of documents to return", - "type": "number" - }, - "projection": { - "additionalProperties": {}, - "description": "The projection, matching the syntax of the projection argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "sort": { - "additionalProperties": { - "anyOf": [ - { - "const": 1, - "type": "number" - }, - { - "const": -1, - "type": "number" - }, - { - "const": "asc", - "type": "string" - }, - { - "const": "desc", - "type": "string" - }, - { - "const": "ascending", - "type": "string" - }, - { - "const": "descending", - "type": "string" - }, - { - "properties": { - "$meta": { - "type": "string" - } - }, - "required": [ - "$meta" - ], - "type": "object" - } - ], - "description": "The sort key and its direction" - }, - "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", - "propertyNames": { - "type": "string" - }, - "type": "object" - } - }, - "type": "object" - }, - "name": { - "const": "find", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - }, - { - "properties": { - "arguments": { - "properties": { - "query": { - "additionalProperties": {}, - "description": "A filter/query parameter. Allows users to filter the documents to count. Matches the syntax of the filter argument of db.collection.count().", - "properties": {}, - "type": "object" - } - }, - "type": "object" - }, - "name": { - "const": "count", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - } -]New value: +[ + { + "properties": { + "arguments": { + "properties": { + "pipeline": { + "description": "An array of aggregation stages to execute.\n\nIf the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage\nof the pipeline (or the first stage of a `$unionWith` sub-pipeline only when explicitly\ncombining unrelated result sets — for hybrid full-text + vector search, use `$rankFusion`\nor `$scoreFusion` instead, see below).\n\nIf the user has asked for lexical/Atlas search, use `$search` instead of `$text`.\n### Usage Rules for `$vectorSearch`\n- **Index Type Detection:**\n Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed').\n- **Classic Vector Search (type: 'vector'):**\n Use 'queryVector' with embeddings as an array of numbers.\n- **Auto-Embed Vector Search (type: 'autoEmbed'):**\n Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes.\n- **Unset embeddings:**\n Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**.\n- **Pre-filtering:**\n If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index.\n NEVER include fields in $vectorSearch.filter that are not part of the vector index.\n- **Post-filtering:**\n For all remaining filters, add a $match stage after $vectorSearch.\n- If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields.\n- If no requested filters are valid prefilters, omit the filter key from $vectorSearch.\n\n### Usage Rules for `$search`\n- Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name.\n- The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the appropriate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/\n\n### Usage Rules for `$rankFusion` and `$scoreFusion` (Hybrid Search)\nUse these stages when the user wants to combine full-text (`$search`) and vector\n(`$vectorSearch`) retrieval into a single fused result set. **Prefer native\nfusion over a `$unionWith` + `$group` workaround** — the workaround averages\nincompatible score scales and produces wrong rankings.\n\n**Which stage to use:**\n- `$rankFusion` (MongoDB 8.0+) — Reciprocal Rank Fusion. The recommended default.\n Normalizes scores across incompatible scales automatically. No score tuning needed.\n- `$scoreFusion` (MongoDB 8.2+) — Score-based fusion. Use when the user needs explicit\n per-pipeline weights, score normalisation (sigmoid / minMaxScaler), or a custom\n combination expression.\n\n**Construction rules:**\n- `$rankFusion` / `$scoreFusion` MUST be the first stage of the top-level pipeline.\n- Sub-pipelines go inside `input.pipelines` as a named map (not an array). Each name\n must be non-empty, must not start with `$`, and must not contain `.` or null bytes.\n- Allowed stages inside sub-pipelines: `$search`, `$vectorSearch`, `$match`, `$sort`,\n `$geoNear`, `$skip`, `$limit`. `$project` and `$unset` are NOT allowed inside sub-pipelines.\n- Do field shaping (`$project` / `$unset`) only AFTER the fusion stage, at the root.\n- Both a vectorSearch (or autoEmbed) index AND a search (lexical) index must exist on\n the collection. Use the collection-indexes tool to confirm both before running a hybrid query.\n- Add a `$limit` stage after the fusion stage to cap the final result set.\n- Add `$unset` at the end to remove embedding fields and avoid context bloat.\n\n### Usage Rules for `$rerank` (Native Reranking)\nUse this stage when the user wants to reorder a set of candidate documents using a cross-encoder reranker model.\n\n**Construction rules:**\n- `$rerank` can be any stage in the pipeline on an Atlas cluster running MongoDB 8.3 or higher.\n- It is recommended to use `$rerank` after a sorted pipeline, e.g. `$search`, `$vectorSearch`, `$rankFusion`, `$scoreFusion`, or [`$match`, `$sort`].\n- $rerank must be enabled via the Native Reranking Project Setting\n- Set `numDocsToRerank` as the number of documents passed into `$rerank`. This will also limit the number of documents returned by `$rerank`\n- Set `path` as a field name or an array of field names that exist in all documents. Use `$match` or `$set` before `$rerank` to validate no fields are missing.\n- Add `$addFields` after `$rerank` to retrieve the reranker score.\n\n**`$rerank` example (recommended default):**\n```javascript\n[\n {\n $match: {\n description: { $exists: true },\n name: { $exists: true }\n }\n },\n {\n $sort: {\n lastUpdated: -1\n }\n },\n {\n $rerank: {\n query: {\n text: \"query text including instructions\"\n },\n model: \"rerank-2.5\",\n numDocsToRerank: 100,\n path: [\"description\", \"name\"]\n }\n },\n {\n $addFields: {\n rerankScore: { $meta: \"score\" }\n }\n }\n]\n```\n", + "items": { + "anyOf": [ + { + "properties": { + "$vectorSearch": { + "anyOf": [ + { + "description": "Classic vector search using 'queryVector'. Use this when the indexed field has a classic vector index (type: 'vector'). Note to LLM: Use the collection-indexes tool to verify the target field has a classic vector index before using 'queryVector'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "queryVector": { + "description": "The vector embeddings to search for when using classic vector search indexes (type: 'vector'). Provide embeddings as an array of numbers. Use this for classic vector indexes. For auto-embed indexes (type: 'autoEmbed'), use 'query' instead.", + "items": { + "type": "number" + }, + "type": "array" + } + }, + "required": [ + "index", + "path", + "queryVector" + ], + "type": "object" + }, + { + "description": "Auto-embed vector search using 'query'. Use this when the indexed field has an auto-embed index (type: 'autoEmbed'). Note to LLM: Use the collection-indexes tool to verify the target field has an auto-embed index before using 'query'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "model": { + "description": "The embedding model to use for generating embeddings from the query text. If not specified, defaults to the model configured in the auto-embed index definition.", + "enum": [ + "voyage-4", + "voyage-4-large", + "voyage-4-lite", + "voyage-code-3" + ], + "type": "string" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "query": { + "description": "The query to search for when using auto-embed indexes (type: 'autoEmbed'). MongoDB will automatically generate embeddings for the text at query time. Use this for auto-embed indexes, not 'queryVector'.", + "properties": { + "text": { + "description": "The text query to search for.", + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + } + }, + "required": [ + "index", + "path", + "query" + ], + "type": "object" + } + ] + } + }, + "required": [ + "$vectorSearch" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": {}, + "type": "object" + } + ] + }, + "type": "array" + } + }, + "required": [ + "pipeline" + ], + "type": "object" + }, + "name": { + "const": "aggregate", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + }, + { + "properties": { + "arguments": { + "properties": { + "filter": { + "additionalProperties": {}, + "description": "The query filter, matching the syntax of the query argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "limit": { + "default": 10, + "description": "The maximum number of documents to return", + "type": "number" + }, + "projection": { + "additionalProperties": {}, + "description": "The projection, matching the syntax of the projection argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "sort": { + "additionalProperties": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": -1, + "type": "number" + }, + { + "const": "asc", + "type": "string" + }, + { + "const": "desc", + "type": "string" + }, + { + "const": "ascending", + "type": "string" + }, + { + "const": "descending", + "type": "string" + }, + { + "properties": { + "$meta": { + "type": "string" + } + }, + "required": [ + "$meta" + ], + "type": "object" + } + ], + "description": "The sort key and its direction" + }, + "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "type": "object" + }, + "name": { + "const": "find", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + }, + { + "properties": { + "arguments": { + "properties": { + "query": { + "additionalProperties": {}, + "description": "A filter/query parameter. Allows users to filter the documents to count. Matches the syntax of the filter argument of db.collection.count().", + "properties": {}, + "type": "object" + } + }, + "type": "object" + }, + "name": { + "const": "count", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + } +] - changed
Input schema / requiredPrevious value: -[ - "database", - "collection", - "method" -]New value: +[ + "connectionId", + "database", + "collection", + "method" +]
- Changed
export4 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / properties / exportTarget / items / oneOfPrevious value: -[ - { - "properties": { - "arguments": { - "description": "The arguments for 'find' operation.", - "properties": { - "filter": { - "additionalProperties": {}, - "description": "The query filter, matching the syntax of the query argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "limit": { - "type": "number" - }, - "projection": { - "additionalProperties": {}, - "description": "The projection, matching the syntax of the projection argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "sort": { - "additionalProperties": { - "anyOf": [ - { - "const": 1, - "type": "number" - }, - { - "const": -1, - "type": "number" - }, - { - "const": "asc", - "type": "string" - }, - { - "const": "desc", - "type": "string" - }, - { - "const": "ascending", - "type": "string" - }, - { - "const": "descending", - "type": "string" - }, - { - "properties": { - "$meta": { - "type": "string" - } - }, - "required": [ - "$meta" - ], - "type": "object" - } - ], - "description": "The sort key and its direction" - }, - "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", - "propertyNames": { - "type": "string" - }, - "type": "object" - } - }, - "type": "object" - }, - "name": { - "const": "find", - "description": "The literal name 'find' to represent a find cursor as target.", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - }, - { - "properties": { - "arguments": { - "description": "The arguments for 'aggregate' operation.", - "properties": { - "pipeline": { - "description": "An array of aggregation stages to execute.\nIf the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage of the pipeline, or the first stage of a `$unionWith` subpipeline.\nIf the user has asked for lexical/Atlas search, use `$search` instead of `$text`.\n### Usage Rules for `$vectorSearch`\n- **Index Type Detection:**\n Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed').\n- **Classic Vector Search (type: 'vector'):**\n Use 'queryVector' with embeddings as an array of numbers.\n- **Auto-Embed Vector Search (type: 'autoEmbed'):**\n Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes.\n- **Unset embeddings:**\n Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**.\n- **Pre-filtering:**\n If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index.\n NEVER include fields in $vectorSearch.filter that are not part of the vector index.\n- **Post-filtering:**\n For all remaining filters, add a $match stage after $vectorSearch.\n- If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields.\n- If no requested filters are valid prefilters, omit the filter key from $vectorSearch.\n\n### Usage Rules for `$search`\n- Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name.\n- The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the approprate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/\n", - "items": { - "anyOf": [ - { - "properties": { - "$vectorSearch": { - "anyOf": [ - { - "description": "Classic vector search using 'queryVector'. Use this when the indexed field has a classic vector index (type: 'vector'). Note to LLM: Use the collection-indexes tool to verify the target field has a classic vector index before using 'queryVector'.", - "properties": { - "exact": { - "default": false, - "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", - "type": "boolean" - }, - "filter": { - "additionalProperties": {}, - "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", - "properties": {}, - "type": "object" - }, - "index": { - "description": "Name of the index, as retrieved from the `collection-indexes` tool.", - "type": "string" - }, - "limit": { - "default": 10, - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "numCandidates": { - "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "path": { - "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", - "type": "string" - }, - "queryVector": { - "description": "The vector embeddings to search for when using classic vector search indexes (type: 'vector'). Provide embeddings as an array of numbers. Use this for classic vector indexes. For auto-embed indexes (type: 'autoEmbed'), use 'query' instead.", - "items": { - "type": "number" - }, - "type": "array" - } - }, - "required": [ - "index", - "path", - "queryVector" - ], - "type": "object" - }, - { - "description": "Auto-embed vector search using 'query'. Use this when the indexed field has an auto-embed index (type: 'autoEmbed'). Note to LLM: Use the collection-indexes tool to verify the target field has an auto-embed index before using 'query'.", - "properties": { - "exact": { - "default": false, - "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", - "type": "boolean" - }, - "filter": { - "additionalProperties": {}, - "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", - "properties": {}, - "type": "object" - }, - "index": { - "description": "Name of the index, as retrieved from the `collection-indexes` tool.", - "type": "string" - }, - "limit": { - "default": 10, - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "model": { - "description": "The embedding model to use for generating embeddings from the query text. If not specified, defaults to the model configured in the auto-embed index definition.", - "enum": [ - "voyage-4", - "voyage-4-large", - "voyage-4-lite", - "voyage-code-3" - ], - "type": "string" - }, - "numCandidates": { - "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "path": { - "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", - "type": "string" - }, - "query": { - "description": "The query to search for when using auto-embed indexes (type: 'autoEmbed'). MongoDB will automatically generate embeddings for the text at query time. Use this for auto-embed indexes, not 'queryVector'.", - "properties": { - "text": { - "description": "The text query to search for.", - "type": "string" - } - }, - "required": [ - "text" - ], - "type": "object" - } - }, - "required": [ - "index", - "path", - "query" - ], - "type": "object" - } - ] - } - }, - "required": [ - "$vectorSearch" - ], - "type": "object" - }, - { - "additionalProperties": {}, - "properties": {}, - "type": "object" - } - ] - }, - "type": "array" - } - }, - "required": [ - "pipeline" - ], - "type": "object" - }, - "name": { - "const": "aggregate", - "description": "The literal name 'aggregate' to represent an aggregation cursor as target.", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - } -]New value: +[ + { + "properties": { + "arguments": { + "description": "The arguments for 'find' operation.", + "properties": { + "filter": { + "additionalProperties": {}, + "description": "The query filter, matching the syntax of the query argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "limit": { + "type": "number" + }, + "projection": { + "additionalProperties": {}, + "description": "The projection, matching the syntax of the projection argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "sort": { + "additionalProperties": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": -1, + "type": "number" + }, + { + "const": "asc", + "type": "string" + }, + { + "const": "desc", + "type": "string" + }, + { + "const": "ascending", + "type": "string" + }, + { + "const": "descending", + "type": "string" + }, + { + "properties": { + "$meta": { + "type": "string" + } + }, + "required": [ + "$meta" + ], + "type": "object" + } + ], + "description": "The sort key and its direction" + }, + "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "type": "object" + }, + "name": { + "const": "find", + "description": "The literal name 'find' to represent a find cursor as target.", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + }, + { + "properties": { + "arguments": { + "description": "The arguments for 'aggregate' operation.", + "properties": { + "pipeline": { + "description": "An array of aggregation stages to execute.\n\nIf the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage\nof the pipeline (or the first stage of a `$unionWith` sub-pipeline only when explicitly\ncombining unrelated result sets — for hybrid full-text + vector search, use `$rankFusion`\nor `$scoreFusion` instead, see below).\n\nIf the user has asked for lexical/Atlas search, use `$search` instead of `$text`.\n### Usage Rules for `$vectorSearch`\n- **Index Type Detection:**\n Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed').\n- **Classic Vector Search (type: 'vector'):**\n Use 'queryVector' with embeddings as an array of numbers.\n- **Auto-Embed Vector Search (type: 'autoEmbed'):**\n Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes.\n- **Unset embeddings:**\n Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**.\n- **Pre-filtering:**\n If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index.\n NEVER include fields in $vectorSearch.filter that are not part of the vector index.\n- **Post-filtering:**\n For all remaining filters, add a $match stage after $vectorSearch.\n- If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields.\n- If no requested filters are valid prefilters, omit the filter key from $vectorSearch.\n\n### Usage Rules for `$search`\n- Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name.\n- The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the appropriate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/\n\n### Usage Rules for `$rankFusion` and `$scoreFusion` (Hybrid Search)\nUse these stages when the user wants to combine full-text (`$search`) and vector\n(`$vectorSearch`) retrieval into a single fused result set. **Prefer native\nfusion over a `$unionWith` + `$group` workaround** — the workaround averages\nincompatible score scales and produces wrong rankings.\n\n**Which stage to use:**\n- `$rankFusion` (MongoDB 8.0+) — Reciprocal Rank Fusion. The recommended default.\n Normalizes scores across incompatible scales automatically. No score tuning needed.\n- `$scoreFusion` (MongoDB 8.2+) — Score-based fusion. Use when the user needs explicit\n per-pipeline weights, score normalisation (sigmoid / minMaxScaler), or a custom\n combination expression.\n\n**Construction rules:**\n- `$rankFusion` / `$scoreFusion` MUST be the first stage of the top-level pipeline.\n- Sub-pipelines go inside `input.pipelines` as a named map (not an array). Each name\n must be non-empty, must not start with `$`, and must not contain `.` or null bytes.\n- Allowed stages inside sub-pipelines: `$search`, `$vectorSearch`, `$match`, `$sort`,\n `$geoNear`, `$skip`, `$limit`. `$project` and `$unset` are NOT allowed inside sub-pipelines.\n- Do field shaping (`$project` / `$unset`) only AFTER the fusion stage, at the root.\n- Both a vectorSearch (or autoEmbed) index AND a search (lexical) index must exist on\n the collection. Use the collection-indexes tool to confirm both before running a hybrid query.\n- Add a `$limit` stage after the fusion stage to cap the final result set.\n- Add `$unset` at the end to remove embedding fields and avoid context bloat.\n\n### Usage Rules for `$rerank` (Native Reranking)\nUse this stage when the user wants to reorder a set of candidate documents using a cross-encoder reranker model.\n\n**Construction rules:**\n- `$rerank` can be any stage in the pipeline on an Atlas cluster running MongoDB 8.3 or higher.\n- It is recommended to use `$rerank` after a sorted pipeline, e.g. `$search`, `$vectorSearch`, `$rankFusion`, `$scoreFusion`, or [`$match`, `$sort`].\n- $rerank must be enabled via the Native Reranking Project Setting\n- Set `numDocsToRerank` as the number of documents passed into `$rerank`. This will also limit the number of documents returned by `$rerank`\n- Set `path` as a field name or an array of field names that exist in all documents. Use `$match` or `$set` before `$rerank` to validate no fields are missing.\n- Add `$addFields` after `$rerank` to retrieve the reranker score.\n\n**`$rerank` example (recommended default):**\n```javascript\n[\n {\n $match: {\n description: { $exists: true },\n name: { $exists: true }\n }\n },\n {\n $sort: {\n lastUpdated: -1\n }\n },\n {\n $rerank: {\n query: {\n text: \"query text including instructions\"\n },\n model: \"rerank-2.5\",\n numDocsToRerank: 100,\n path: [\"description\", \"name\"]\n }\n },\n {\n $addFields: {\n rerankScore: { $meta: \"score\" }\n }\n }\n]\n```\n", + "items": { + "anyOf": [ + { + "properties": { + "$vectorSearch": { + "anyOf": [ + { + "description": "Classic vector search using 'queryVector'. Use this when the indexed field has a classic vector index (type: 'vector'). Note to LLM: Use the collection-indexes tool to verify the target field has a classic vector index before using 'queryVector'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "queryVector": { + "description": "The vector embeddings to search for when using classic vector search indexes (type: 'vector'). Provide embeddings as an array of numbers. Use this for classic vector indexes. For auto-embed indexes (type: 'autoEmbed'), use 'query' instead.", + "items": { + "type": "number" + }, + "type": "array" + } + }, + "required": [ + "index", + "path", + "queryVector" + ], + "type": "object" + }, + { + "description": "Auto-embed vector search using 'query'. Use this when the indexed field has an auto-embed index (type: 'autoEmbed'). Note to LLM: Use the collection-indexes tool to verify the target field has an auto-embed index before using 'query'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "model": { + "description": "The embedding model to use for generating embeddings from the query text. If not specified, defaults to the model configured in the auto-embed index definition.", + "enum": [ + "voyage-4", + "voyage-4-large", + "voyage-4-lite", + "voyage-code-3" + ], + "type": "string" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "query": { + "description": "The query to search for when using auto-embed indexes (type: 'autoEmbed'). MongoDB will automatically generate embeddings for the text at query time. Use this for auto-embed indexes, not 'queryVector'.", + "properties": { + "text": { + "description": "The text query to search for.", + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + } + }, + "required": [ + "index", + "path", + "query" + ], + "type": "object" + } + ] + } + }, + "required": [ + "$vectorSearch" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": {}, + "type": "object" + } + ] + }, + "type": "array" + } + }, + "required": [ + "pipeline" + ], + "type": "object" + }, + "name": { + "const": "aggregate", + "description": "The literal name 'aggregate' to represent an aggregation cursor as target.", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + } +] - changed
Input schema / requiredPrevious value: -[ - "database", - "collection", - "exportTitle", - "exportTarget" -]New value: +[ + "connectionId", + "database", + "collection", + "exportTitle", + "exportTarget" +]
- Changed
find4 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / properties / responseBytesLimit / descriptionPrevious value: -"The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire query result is required, use the \"export\" tool instead of increasing this limit."New value: +"The maximum number of bytes to return in the response. This value is capped by the server's configured maximum and cannot be exceeded." - changed
Input schema / requiredPrevious value: -[ - "database", - "collection" -]New value: +[ + "connectionId", + "database", + "collection" +]
- Changed
list-collections3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "database" -]New value: +[ + "connectionId", + "database" +]
- Added
list-connections - Changed
list-databases3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - added
Input schema / requiredAdded value: +[ + "connectionId" +]
- Changed
list-knowledge-sources1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
mongodb-logs3 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / connectionIdAdded value: +{ + "description": "The connection to run the operation against. Use the id returned by one of the connect tools, or \"preconfigured\" to use the connection string the server was configured with.", + "type": "string" +} - added
Input schema / requiredAdded value: +[ + "connectionId" +]
- Changed
search-knowledge1 field changed- added
Input schema / additionalPropertiesAdded value: +false
14 tool updates
v1.14.0- Changed
aggregate1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "appliedLimits": { + "description": "The limits applied to the aggregation pipeline", + "items": { + "enum": [ + "config.maxDocumentsPerQuery", + "config.maxBytesPerQuery", + "tool.responseBytesLimit" + ], + "type": "string" + }, + "type": "array" + }, + "count": { + "anyOf": [ + { + "type": "number" + }, + { + "const": "indeterminate", + "type": "string" + } + ], + "description": "The total number of documents returned by the aggregation pipeline" + }, + "documents": { + "description": "The documents returned by the aggregation pipeline", + "items": {}, + "type": "array" + } + }, + "required": [ + "documents", + "count", + "appliedLimits" + ], + "type": "object" +}
- Changed
aggregate-db1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "aggResultsCount": { + "description": "The total number of documents returned by the aggregation pipeline", + "type": "number" + }, + "appliedLimits": { + "description": "The limits applied to the aggregation pipeline", + "items": { + "enum": [ + "config.maxDocumentsPerQuery", + "config.maxBytesPerQuery", + "tool.responseBytesLimit" + ], + "type": "string" + }, + "type": "array" + }, + "documents": { + "description": "The documents returned by the aggregation pipeline", + "items": {}, + "type": "array" + } + }, + "required": [ + "documents", + "appliedLimits" + ], + "type": "object" +}
- Changed
atlas-get-performance-advisor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "clusterName": { + "type": "string" + }, + "dropIndexSuggestions": { + "additionalProperties": false, + "properties": { + "hiddenIndexes": { + "items": {}, + "type": "array" + }, + "redundantIndexes": { + "items": {}, + "type": "array" + }, + "unusedIndexes": { + "items": {}, + "type": "array" + } + }, + "required": [ + "hiddenIndexes", + "redundantIndexes", + "unusedIndexes" + ], + "type": "object" + }, + "projectId": { + "type": "string" + }, + "schemaSuggestions": { + "items": {}, + "type": "array" + }, + "slowQueryLogs": { + "items": {}, + "type": "array" + }, + "suggestedIndexes": { + "items": {}, + "type": "array" + } + }, + "required": [ + "projectId", + "clusterName" + ], + "type": "object" +}
- Changed
atlas-inspect-access-list1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "entries": { + "items": { + "additionalProperties": false, + "properties": { + "cidrBlock": { + "type": "string" + }, + "comment": { + "type": "string" + }, + "ipAddress": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + }, + "projectId": { + "type": "string" + }, + "totalCount": { + "type": "number" + } + }, + "required": [ + "projectId", + "entries", + "totalCount" + ], + "type": "object" +}
- Changed
atlas-inspect-cluster1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "connectionStrings": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "instanceSize": { + "type": "string" + }, + "instanceType": { + "enum": [ + "FREE", + "DEDICATED", + "FLEX" + ], + "type": "string" + }, + "mongoDBVersion": { + "type": "string" + }, + "name": { + "type": "string" + }, + "paused": { + "type": "boolean" + }, + "provider": { + "type": "string" + }, + "region": { + "type": "string" + }, + "state": { + "type": "string" + } + }, + "required": [ + "name", + "instanceType", + "instanceSize", + "paused", + "state", + "mongoDBVersion", + "connectionStrings" + ], + "type": "object" +}
- Changed
atlas-list-alerts1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "alerts": { + "items": { + "additionalProperties": false, + "properties": { + "acknowledgementComment": { + "type": "string" + }, + "created": { + "type": "string" + }, + "eventTypeName": { + "type": "string" + }, + "id": { + "type": "string" + }, + "status": { + "type": "string" + }, + "updated": { + "type": "string" + } + }, + "required": [ + "id", + "status", + "created", + "updated", + "eventTypeName", + "acknowledgementComment" + ], + "type": "object" + }, + "type": "array" + }, + "projectId": { + "type": "string" + }, + "status": { + "enum": [ + "OPEN", + "TRACKING", + "CLOSED" + ], + "type": "string" + }, + "totalCount": { + "type": "number" + } + }, + "required": [ + "projectId", + "status", + "alerts" + ], + "type": "object" +}
- Changed
atlas-list-clusters1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "clusters": { + "items": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "clusterName": { + "type": "string" + }, + "projectId": { + "type": "string" + }, + "projectName": { + "type": "string" + } + }, + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "connectionStrings": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "instanceSize": { + "type": "string" + }, + "instanceType": { + "enum": [ + "FREE", + "DEDICATED", + "FLEX" + ], + "type": "string" + }, + "mongoDBVersion": { + "type": "string" + }, + "name": { + "type": "string" + }, + "paused": { + "type": "boolean" + }, + "processIds": { + "items": { + "type": "string" + }, + "type": "array" + }, + "provider": { + "type": "string" + }, + "region": { + "type": "string" + }, + "state": { + "enum": [ + "IDLE", + "CREATING", + "UPDATING", + "DELETING", + "REPAIRING" + ], + "type": "string" + } + }, + "required": [ + "instanceType", + "paused" + ], + "type": "object" + } + ] + }, + "type": "array" + }, + "projectId": { + "type": "string" + }, + "projectName": { + "type": "string" + }, + "totalCount": { + "type": "number" + } + }, + "required": [ + "clusters", + "totalCount" + ], + "type": "object" +}
- Changed
atlas-list-db-users1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "projectId": { + "type": "string" + }, + "totalCount": { + "type": "number" + }, + "users": { + "items": { + "additionalProperties": false, + "properties": { + "roles": { + "items": { + "additionalProperties": false, + "properties": { + "collectionName": { + "type": "string" + }, + "databaseName": { + "type": "string" + }, + "roleName": { + "type": "string" + } + }, + "required": [ + "roleName", + "databaseName" + ], + "type": "object" + }, + "type": "array" + }, + "scopes": { + "items": { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "type": { + "enum": [ + "CLUSTER", + "DATA_LAKE", + "STREAM" + ], + "type": "string" + } + }, + "required": [ + "type", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "username": { + "type": "string" + } + }, + "required": [ + "username", + "roles", + "scopes" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "projectId", + "users", + "totalCount" + ], + "type": "object" +}
- Changed
atlas-list-orgs1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "organizations": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + }, + "totalCount": { + "type": "number" + } + }, + "required": [ + "organizations", + "totalCount" + ], + "type": "object" +}
- Changed
atlas-list-projects1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "orgId": { + "type": "string" + }, + "projects": { + "items": { + "additionalProperties": false, + "properties": { + "created": { + "type": "string" + }, + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "orgId": { + "type": "string" + }, + "orgName": { + "type": "string" + } + }, + "required": [ + "name", + "orgId", + "orgName", + "created" + ], + "type": "object" + }, + "type": "array" + }, + "totalCount": { + "type": "number" + } + }, + "required": [ + "projects", + "totalCount" + ], + "type": "object" +}
- Changed
atlas-streams-discover1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "accountDetails": { + "additionalProperties": false, + "properties": { + "awsAccountId": { + "type": "string" + }, + "azureSubscriptionId": { + "type": "string" + }, + "cidrBlock": { + "type": "string" + }, + "gcpProjectId": { + "type": "string" + }, + "virtualNetworkName": { + "type": "string" + }, + "vpcId": { + "type": "string" + }, + "vpcNetworkName": { + "type": "string" + } + }, + "type": "object" + }, + "connection": { + "additionalProperties": false, + "properties": { + "bootstrapServers": { + "anyOf": [ + { + "type": "string" + }, + { + "items": { + "type": "string" + }, + "type": "array" + } + ] + }, + "clusterName": { + "type": "string" + }, + "region": { + "type": "string" + }, + "state": { + "type": "string" + }, + "type": { + "type": "string" + } + }, + "type": "object" + }, + "connectionHealth": { + "items": { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "state": { + "type": "string" + }, + "type": { + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": "array" + }, + "connections": { + "items": { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "state": { + "type": "string" + }, + "type": { + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": "array" + }, + "dlq": { + "additionalProperties": false, + "properties": { + "coll": { + "type": "string" + }, + "connectionName": { + "type": "string" + }, + "db": { + "type": "string" + } + }, + "type": "object" + }, + "pipeline": { + "items": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "privateLinks": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "provider": { + "type": "string" + }, + "region": { + "type": "string" + }, + "state": { + "type": "string" + }, + "vendor": { + "type": "string" + } + }, + "required": [ + "id" + ], + "type": "object" + }, + "type": "array" + }, + "processorState": { + "enum": [ + "STARTED", + "STOPPED", + "CREATED", + "FAILED" + ], + "type": "string" + }, + "processors": { + "items": { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "state": { + "type": "string" + }, + "tier": { + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": "array" + }, + "stats": { + "additionalProperties": false, + "properties": { + "dlqMessageCount": { + "type": "number" + }, + "inputMessageCount": { + "type": "number" + }, + "outputMessageCount": { + "type": "number" + } + }, + "type": "object" + }, + "tier": { + "type": "string" + }, + "workspace": { + "additionalProperties": false, + "properties": { + "connectionCount": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "maxTier": { + "type": "string" + }, + "name": { + "type": "string" + }, + "region": { + "type": "string" + }, + "tier": { + "type": "string" + } + }, + "required": [ + "name", + "region", + "tier", + "maxTier", + "connectionCount" + ], + "type": "object" + }, + "workspaces": { + "items": { + "additionalProperties": false, + "properties": { + "maxTier": { + "type": "string" + }, + "name": { + "type": "string" + }, + "region": { + "type": "string" + }, + "tier": { + "type": "string" + } + }, + "required": [ + "name", + "region", + "tier", + "maxTier" + ], + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
connect1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "connected": { + "type": "boolean" + } + }, + "required": [ + "connected" + ], + "type": "object" +}
- Changed
count1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "count": { + "description": "The number of documents in the collection", + "type": "number" + } + }, + "required": [ + "count" + ], + "type": "object" +}
- Changed
find1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "appliedLimits": { + "description": "The limits applied to the find query", + "items": { + "enum": [ + "config.maxDocumentsPerQuery", + "config.maxBytesPerQuery", + "tool.responseBytesLimit" + ], + "type": "string" + }, + "type": "array" + }, + "documents": { + "description": "The documents returned by the find query", + "items": {}, + "type": "array" + }, + "queryResultsCount": { + "description": "The total number of documents returned by the find query", + "type": "number" + } + }, + "required": [ + "documents", + "appliedLimits" + ], + "type": "object" +}
1 tool update
v1.12.0- Changed
explain2 fields changed- added
Output schema / properties / method / enumAdded value: +[ + "aggregate", + "find", + "count" +] - added
Output schema / properties / verbosity / enumAdded value: +[ + "queryPlanner", + "queryPlannerExtended", + "executionStats", + "allPlansExecution" +]
24 tool updates
v1.11.0- Changed
aggregate6 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Input schema / properties / pipeline / descriptionPrevious value: -"An array of aggregation stages to execute."New value: +"An array of aggregation stages to execute.\nIf the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage of the pipeline, or the first stage of a `$unionWith` subpipeline.\nIf the user has asked for lexical/Atlas search, use `$search` instead of `$text`.\n### Usage Rules for `$vectorSearch`\n- **Index Type Detection:**\n Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed').\n- **Classic Vector Search (type: 'vector'):**\n Use 'queryVector' with embeddings as an array of numbers.\n- **Auto-Embed Vector Search (type: 'autoEmbed'):**\n Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes.\n- **Unset embeddings:**\n Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**.\n- **Pre-filtering:**\n If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index.\n NEVER include fields in $vectorSearch.filter that are not part of the vector index.\n- **Post-filtering:**\n For all remaining filters, add a $match stage after $vectorSearch.\n- If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields.\n- If no requested filters are valid prefilters, omit the filter key from $vectorSearch.\n\n### Usage Rules for `$search`\n- Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name.\n- The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the approprate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/\n" - removed
Input schema / properties / pipeline / items / additionalPropertiesRemoved value: -true - added
Input schema / properties / pipeline / items / anyOfAdded value: +[ + { + "properties": { + "$vectorSearch": { + "anyOf": [ + { + "description": "Classic vector search using 'queryVector'. Use this when the indexed field has a classic vector index (type: 'vector'). Note to LLM: Use the collection-indexes tool to verify the target field has a classic vector index before using 'queryVector'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "queryVector": { + "description": "The vector embeddings to search for when using classic vector search indexes (type: 'vector'). Provide embeddings as an array of numbers. Use this for classic vector indexes. For auto-embed indexes (type: 'autoEmbed'), use 'query' instead.", + "items": { + "type": "number" + }, + "type": "array" + } + }, + "required": [ + "index", + "path", + "queryVector" + ], + "type": "object" + }, + { + "description": "Auto-embed vector search using 'query'. Use this when the indexed field has an auto-embed index (type: 'autoEmbed'). Note to LLM: Use the collection-indexes tool to verify the target field has an auto-embed index before using 'query'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "model": { + "description": "The embedding model to use for generating embeddings from the query text. If not specified, defaults to the model configured in the auto-embed index definition.", + "enum": [ + "voyage-4", + "voyage-4-large", + "voyage-4-lite", + "voyage-code-3" + ], + "type": "string" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "query": { + "description": "The query to search for when using auto-embed indexes (type: 'autoEmbed'). MongoDB will automatically generate embeddings for the text at query time. Use this for auto-embed indexes, not 'queryVector'.", + "properties": { + "text": { + "description": "The text query to search for.", + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + } + }, + "required": [ + "index", + "path", + "query" + ], + "type": "object" + } + ] + } + }, + "required": [ + "$vectorSearch" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": {}, + "type": "object" + } +] - removed
Input schema / properties / pipeline / items / propertiesRemoved value: -{} - removed
Input schema / properties / pipeline / items / typeRemoved value: -"object"
- Added
aggregate-db - Changed
atlas-connect-cluster2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "addedCurrentIp": { + "type": "boolean" + }, + "createdTemporaryUser": { + "type": "boolean" + }, + "sharedTierAlerts": { + "items": { + "enum": [ + "CONNECTIONS_PERCENT", + "FLEX_CONNECTIONS_PERCENT", + "FLEX_DATA_SIZE_TOTAL", + "LOGICAL_SIZE" + ], + "type": "string" + }, + "type": "array" + }, + "sharedTierAlertsDetected": { + "type": "boolean" + }, + "sharedTierTier": { + "enum": [ + "Free", + "Flex" + ], + "type": "string" + }, + "state": { + "enum": [ + "connected", + "connecting" + ], + "type": "string" + }, + "temporaryUserClarification": { + "type": "string" + } + }, + "required": [ + "state", + "addedCurrentIp", + "createdTemporaryUser" + ], + "type": "object" +}
- Changed
atlas-get-performance-advisor2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / since / patternAdded value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"
- Changed
atlas-inspect-access-list1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
atlas-inspect-cluster1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
atlas-list-alerts4 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / limitAdded value: +{ + "default": 100, + "description": "Max results per page.", + "maximum": 500, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / pageNumAdded value: +{ + "default": 1, + "description": "Page number.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / statusAdded value: +{ + "default": "OPEN", + "description": "Status of the alerts to return. Defaults to OPEN. TRACKING means the alert condition exists but hasn't persisted beyond the notification delay. OPEN means the alert condition currently exists. CLOSED means the alert has been resolved.", + "enum": [ + "OPEN", + "TRACKING", + "CLOSED" + ], + "type": "string" +}
- Changed
atlas-list-clusters1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
atlas-list-db-users1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
atlas-list-projects1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Added
atlas-streams-discover - Changed
collection-indexes2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "classicIndexes": { + "items": { + "additionalProperties": false, + "properties": { + "key": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "name": { + "type": "string" + } + }, + "required": [ + "name", + "key" + ], + "type": "object" + }, + "type": "array" + }, + "classicIndexesCount": { + "type": "number" + }, + "searchIndexes": { + "items": { + "additionalProperties": false, + "properties": { + "latestDefinition": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "name": { + "type": "string" + }, + "queryable": { + "type": "boolean" + }, + "status": { + "type": "string" + }, + "type": { + "type": "string" + } + }, + "required": [ + "name", + "type", + "status", + "queryable", + "latestDefinition" + ], + "type": "object" + }, + "type": "array" + }, + "searchIndexesCount": { + "type": "number" + } + }, + "required": [ + "classicIndexes", + "searchIndexes", + "classicIndexesCount", + "searchIndexesCount" + ], + "type": "object" +}
- Changed
collection-schema2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "fieldsCount": { + "type": "number" + }, + "schema": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "required": [ + "schema", + "fieldsCount" + ], + "type": "object" +}
- Changed
collection-storage-size2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "size": { + "type": "number" + }, + "units": { + "type": "string" + } + }, + "required": [ + "size", + "units" + ], + "type": "object" +}
- Changed
connect1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
count2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Input schema / properties / query / additionalPropertiesPrevious value: -trueNew value: +{}
- Changed
db-stats2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "stats": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "required": [ + "stats" + ], + "type": "object" +}
- Changed
explain4 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - removed
Input schema / properties / method / items / anyOfRemoved value: -[ - { - "additionalProperties": false, - "properties": { - "arguments": { - "additionalProperties": false, - "properties": { - "pipeline": { - "description": "An array of aggregation stages to execute.", - "items": { - "additionalProperties": true, - "properties": {}, - "type": "object" - }, - "type": "array" - }, - "responseBytesLimit": { - "default": 1048576, - "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire aggregation result is required, use the \"export\" tool instead of increasing this limit.", - "type": "number" - } - }, - "required": [ - "pipeline" - ], - "type": "object" - }, - "name": { - "const": "aggregate", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "arguments": { - "additionalProperties": false, - "properties": { - "filter": { - "additionalProperties": true, - "description": "The query filter, matching the syntax of the query argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "limit": { - "default": 10, - "description": "The maximum number of documents to return", - "type": "number" - }, - "projection": { - "additionalProperties": true, - "description": "The projection, matching the syntax of the projection argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "responseBytesLimit": { - "default": 1048576, - "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire query result is required, use the \"export\" tool instead of increasing this limit.", - "type": "number" - }, - "sort": { - "additionalProperties": {}, - "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", - "properties": {}, - "type": "object" - } - }, - "type": "object" - }, - "name": { - "const": "find", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "arguments": { - "additionalProperties": false, - "properties": { - "query": { - "additionalProperties": true, - "description": "A filter/query parameter. Allows users to filter the documents to count. Matches the syntax of the filter argument of db.collection.count().", - "properties": {}, - "type": "object" - } - }, - "type": "object" - }, - "name": { - "const": "count", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - } -] - added
Input schema / properties / method / items / oneOfAdded value: +[ + { + "properties": { + "arguments": { + "properties": { + "pipeline": { + "description": "An array of aggregation stages to execute.\nIf the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage of the pipeline, or the first stage of a `$unionWith` subpipeline.\nIf the user has asked for lexical/Atlas search, use `$search` instead of `$text`.\n### Usage Rules for `$vectorSearch`\n- **Index Type Detection:**\n Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed').\n- **Classic Vector Search (type: 'vector'):**\n Use 'queryVector' with embeddings as an array of numbers.\n- **Auto-Embed Vector Search (type: 'autoEmbed'):**\n Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes.\n- **Unset embeddings:**\n Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**.\n- **Pre-filtering:**\n If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index.\n NEVER include fields in $vectorSearch.filter that are not part of the vector index.\n- **Post-filtering:**\n For all remaining filters, add a $match stage after $vectorSearch.\n- If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields.\n- If no requested filters are valid prefilters, omit the filter key from $vectorSearch.\n\n### Usage Rules for `$search`\n- Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name.\n- The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the approprate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/\n", + "items": { + "anyOf": [ + { + "properties": { + "$vectorSearch": { + "anyOf": [ + { + "description": "Classic vector search using 'queryVector'. Use this when the indexed field has a classic vector index (type: 'vector'). Note to LLM: Use the collection-indexes tool to verify the target field has a classic vector index before using 'queryVector'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "queryVector": { + "description": "The vector embeddings to search for when using classic vector search indexes (type: 'vector'). Provide embeddings as an array of numbers. Use this for classic vector indexes. For auto-embed indexes (type: 'autoEmbed'), use 'query' instead.", + "items": { + "type": "number" + }, + "type": "array" + } + }, + "required": [ + "index", + "path", + "queryVector" + ], + "type": "object" + }, + { + "description": "Auto-embed vector search using 'query'. Use this when the indexed field has an auto-embed index (type: 'autoEmbed'). Note to LLM: Use the collection-indexes tool to verify the target field has an auto-embed index before using 'query'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "model": { + "description": "The embedding model to use for generating embeddings from the query text. If not specified, defaults to the model configured in the auto-embed index definition.", + "enum": [ + "voyage-4", + "voyage-4-large", + "voyage-4-lite", + "voyage-code-3" + ], + "type": "string" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "query": { + "description": "The query to search for when using auto-embed indexes (type: 'autoEmbed'). MongoDB will automatically generate embeddings for the text at query time. Use this for auto-embed indexes, not 'queryVector'.", + "properties": { + "text": { + "description": "The text query to search for.", + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + } + }, + "required": [ + "index", + "path", + "query" + ], + "type": "object" + } + ] + } + }, + "required": [ + "$vectorSearch" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": {}, + "type": "object" + } + ] + }, + "type": "array" + } + }, + "required": [ + "pipeline" + ], + "type": "object" + }, + "name": { + "const": "aggregate", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + }, + { + "properties": { + "arguments": { + "properties": { + "filter": { + "additionalProperties": {}, + "description": "The query filter, matching the syntax of the query argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "limit": { + "default": 10, + "description": "The maximum number of documents to return", + "type": "number" + }, + "projection": { + "additionalProperties": {}, + "description": "The projection, matching the syntax of the projection argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "sort": { + "additionalProperties": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": -1, + "type": "number" + }, + { + "const": "asc", + "type": "string" + }, + { + "const": "desc", + "type": "string" + }, + { + "const": "ascending", + "type": "string" + }, + { + "const": "descending", + "type": "string" + }, + { + "properties": { + "$meta": { + "type": "string" + } + }, + "required": [ + "$meta" + ], + "type": "object" + } + ], + "description": "The sort key and its direction" + }, + "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "type": "object" + }, + "name": { + "const": "find", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + }, + { + "properties": { + "arguments": { + "properties": { + "query": { + "additionalProperties": {}, + "description": "A filter/query parameter. Allows users to filter the documents to count. Matches the syntax of the filter argument of db.collection.count().", + "properties": {}, + "type": "object" + } + }, + "type": "object" + }, + "name": { + "const": "count", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + } +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "explainResult": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "method": { + "type": "string" + }, + "verbosity": { + "type": "string" + } + }, + "required": [ + "explainResult", + "method", + "verbosity" + ], + "type": "object" +}
- Changed
export3 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - removed
Input schema / properties / exportTarget / items / anyOfRemoved value: -[ - { - "additionalProperties": false, - "properties": { - "arguments": { - "additionalProperties": false, - "description": "The arguments for 'find' operation.", - "properties": { - "filter": { - "additionalProperties": true, - "description": "The query filter, matching the syntax of the query argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "limit": { - "type": "number" - }, - "projection": { - "additionalProperties": true, - "description": "The projection, matching the syntax of the projection argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "responseBytesLimit": { - "default": 1048576, - "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire query result is required, use the \"export\" tool instead of increasing this limit.", - "type": "number" - }, - "sort": { - "additionalProperties": {}, - "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", - "properties": {}, - "type": "object" - } - }, - "type": "object" - }, - "name": { - "const": "find", - "description": "The literal name 'find' to represent a find cursor as target.", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "arguments": { - "additionalProperties": false, - "description": "The arguments for 'aggregate' operation.", - "properties": { - "pipeline": { - "description": "An array of aggregation stages to execute.", - "items": { - "additionalProperties": true, - "properties": {}, - "type": "object" - }, - "type": "array" - }, - "responseBytesLimit": { - "default": 1048576, - "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire aggregation result is required, use the \"export\" tool instead of increasing this limit.", - "type": "number" - } - }, - "required": [ - "pipeline" - ], - "type": "object" - }, - "name": { - "const": "aggregate", - "description": "The literal name 'aggregate' to represent an aggregation cursor as target.", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - } -] - added
Input schema / properties / exportTarget / items / oneOfAdded value: +[ + { + "properties": { + "arguments": { + "description": "The arguments for 'find' operation.", + "properties": { + "filter": { + "additionalProperties": {}, + "description": "The query filter, matching the syntax of the query argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "limit": { + "type": "number" + }, + "projection": { + "additionalProperties": {}, + "description": "The projection, matching the syntax of the projection argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "sort": { + "additionalProperties": { + "anyOf": [ + { + "const": 1, + "type": "number" + }, + { + "const": -1, + "type": "number" + }, + { + "const": "asc", + "type": "string" + }, + { + "const": "desc", + "type": "string" + }, + { + "const": "ascending", + "type": "string" + }, + { + "const": "descending", + "type": "string" + }, + { + "properties": { + "$meta": { + "type": "string" + } + }, + "required": [ + "$meta" + ], + "type": "object" + } + ], + "description": "The sort key and its direction" + }, + "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "type": "object" + }, + "name": { + "const": "find", + "description": "The literal name 'find' to represent a find cursor as target.", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + }, + { + "properties": { + "arguments": { + "description": "The arguments for 'aggregate' operation.", + "properties": { + "pipeline": { + "description": "An array of aggregation stages to execute.\nIf the user has asked for a vector search, `$vectorSearch` **MUST** be the first stage of the pipeline, or the first stage of a `$unionWith` subpipeline.\nIf the user has asked for lexical/Atlas search, use `$search` instead of `$text`.\n### Usage Rules for `$vectorSearch`\n- **Index Type Detection:**\n Use the collection-indexes tool to determine if the target field has a classic vector index (type: 'vector') or an auto-embed index (type: 'autoEmbed').\n- **Classic Vector Search (type: 'vector'):**\n Use 'queryVector' with embeddings as an array of numbers.\n- **Auto-Embed Vector Search (type: 'autoEmbed'):**\n Use 'query' - MongoDB automatically generates embeddings at query time. Do NOT use 'queryVector' or 'embeddingParameters' for auto-embed indexes.\n- **Unset embeddings:**\n Unless the user explicitly requests the embeddings, add an `$unset` stage **at the end of the pipeline** to remove the embedding field and avoid context limits. **The $unset stage in this situation is mandatory**.\n- **Pre-filtering:**\n If the user requests additional filtering, include filters in `$vectorSearch.filter` only for pre-filter fields in the vector index.\n NEVER include fields in $vectorSearch.filter that are not part of the vector index.\n- **Post-filtering:**\n For all remaining filters, add a $match stage after $vectorSearch.\n- If unsure which fields are filterable, use the collection-indexes tool to determine valid prefilter fields.\n- If no requested filters are valid prefilters, omit the filter key from $vectorSearch.\n\n### Usage Rules for `$search`\n- Include the index name, unless you know for a fact there's a default index. If unsure, use the collection-indexes tool to determine the index name.\n- The `$search` stage supports multiple operators, such as 'autocomplete', 'text', 'geoWithin', and others. Choose the approprate operator based on the user's query. If unsure of the exact syntax, consult the MongoDB Atlas Search documentation, which can be found here: https://www.mongodb.com/docs/atlas/atlas-search/operators-and-collectors/\n", + "items": { + "anyOf": [ + { + "properties": { + "$vectorSearch": { + "anyOf": [ + { + "description": "Classic vector search using 'queryVector'. Use this when the indexed field has a classic vector index (type: 'vector'). Note to LLM: Use the collection-indexes tool to verify the target field has a classic vector index before using 'queryVector'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "queryVector": { + "description": "The vector embeddings to search for when using classic vector search indexes (type: 'vector'). Provide embeddings as an array of numbers. Use this for classic vector indexes. For auto-embed indexes (type: 'autoEmbed'), use 'query' instead.", + "items": { + "type": "number" + }, + "type": "array" + } + }, + "required": [ + "index", + "path", + "queryVector" + ], + "type": "object" + }, + { + "description": "Auto-embed vector search using 'query'. Use this when the indexed field has an auto-embed index (type: 'autoEmbed'). Note to LLM: Use the collection-indexes tool to verify the target field has an auto-embed index before using 'query'.", + "properties": { + "exact": { + "default": false, + "description": "When true, uses an ENN algorithm, otherwise uses ANN. Using ENN is not compatible with numCandidates, in that case, numCandidates must be left empty.", + "type": "boolean" + }, + "filter": { + "additionalProperties": {}, + "description": "MQL filter that can only use filter fields from the index definition. Note to LLM: If unsure, use the `collection-indexes` tool to learn which fields can be used for filtering.", + "properties": {}, + "type": "object" + }, + "index": { + "description": "Name of the index, as retrieved from the `collection-indexes` tool.", + "type": "string" + }, + "limit": { + "default": 10, + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "model": { + "description": "The embedding model to use for generating embeddings from the query text. If not specified, defaults to the model configured in the auto-embed index definition.", + "enum": [ + "voyage-4", + "voyage-4-large", + "voyage-4-lite", + "voyage-code-3" + ], + "type": "string" + }, + "numCandidates": { + "description": "Number of candidates for the ANN algorithm. Mandatory when exact is false.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "path": { + "description": "Field, in dot notation, where to search. There must be a vector search index for that field.", + "type": "string" + }, + "query": { + "description": "The query to search for when using auto-embed indexes (type: 'autoEmbed'). MongoDB will automatically generate embeddings for the text at query time. Use this for auto-embed indexes, not 'queryVector'.", + "properties": { + "text": { + "description": "The text query to search for.", + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + } + }, + "required": [ + "index", + "path", + "query" + ], + "type": "object" + } + ] + } + }, + "required": [ + "$vectorSearch" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": {}, + "type": "object" + } + ] + }, + "type": "array" + } + }, + "required": [ + "pipeline" + ], + "type": "object" + }, + "name": { + "const": "aggregate", + "description": "The literal name 'aggregate' to represent an aggregation cursor as target.", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + } +]
- Changed
find7 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Input schema / properties / filter / additionalPropertiesPrevious value: -trueNew value: +{} - changed
Input schema / properties / projection / additionalPropertiesPrevious value: -trueNew value: +{} - added
Input schema / properties / sort / additionalProperties / anyOfAdded value: +[ + { + "const": 1, + "type": "number" + }, + { + "const": -1, + "type": "number" + }, + { + "const": "asc", + "type": "string" + }, + { + "const": "desc", + "type": "string" + }, + { + "const": "ascending", + "type": "string" + }, + { + "const": "descending", + "type": "string" + }, + { + "properties": { + "$meta": { + "type": "string" + } + }, + "required": [ + "$meta" + ], + "type": "object" + } +] - added
Input schema / properties / sort / additionalProperties / descriptionAdded value: +"The sort key and its direction" - removed
Input schema / properties / sort / propertiesRemoved value: -{} - added
Input schema / properties / sort / propertyNamesAdded value: +{ + "type": "string" +}
- Changed
list-collections2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "collections": { + "items": { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": "array" + }, + "totalCount": { + "type": "number" + } + }, + "required": [ + "collections", + "totalCount" + ], + "type": "object" +}
- Added
list-knowledge-sources - Changed
mongodb-logs2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "logs": { + "items": { + "type": "string" + }, + "type": "array" + }, + "shownCount": { + "type": "number" + }, + "totalLinesWritten": { + "type": "number" + } + }, + "required": [ + "logs", + "totalLinesWritten", + "shownCount" + ], + "type": "object" +}
- Added
search-knowledge
24 tool updates
v1.0.0- Changed
aggregate2 fields changed- changed
Input schema / properties / pipeline / descriptionPrevious value: -"An array of aggregation stages to execute"New value: +"An array of aggregation stages to execute." - added
Input schema / properties / responseBytesLimitAdded value: +{ + "default": 1048576, + "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire aggregation result is required, use the \"export\" tool instead of increasing this limit.", + "type": "number" +}
- Added
atlas-connect-cluster - Added
atlas-get-performance-advisor - Added
atlas-inspect-access-list - Added
atlas-inspect-cluster - Added
atlas-list-alerts - Added
atlas-list-clusters - Added
atlas-list-db-users - Added
atlas-list-orgs - Added
atlas-list-projects - Changed
collection-schema2 fields changed- added
Input schema / properties / responseBytesLimitAdded value: +{ + "default": 1048576, + "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded.", + "type": "number" +} - added
Input schema / properties / sampleSizeAdded value: +{ + "default": 50, + "description": "Number of documents to sample for schema inference", + "type": "number" +}
- Changed
connect1 field changed- removed
Input schema / descriptionRemoved value: -"Options for connecting to MongoDB."
- Removed
create-collection - Removed
create-index - Removed
delete-many - Removed
drop-collection - Removed
drop-database - Changed
explain2 fields changed- changed
Input schema / properties / method / items / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "arguments": { - "additionalProperties": false, - "properties": { - "pipeline": { - "description": "An array of aggregation stages to execute", - "items": { - "additionalProperties": true, - "properties": {}, - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "pipeline" - ], - "type": "object" - }, - "name": { - "const": "aggregate", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "arguments": { - "additionalProperties": false, - "properties": { - "filter": { - "additionalProperties": true, - "description": "The query filter, matching the syntax of the query argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "limit": { - "default": 10, - "description": "The maximum number of documents to return", - "type": "number" - }, - "projection": { - "additionalProperties": true, - "description": "The projection, matching the syntax of the projection argument of db.collection.find()", - "properties": {}, - "type": "object" - }, - "sort": { - "additionalProperties": {}, - "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", - "properties": {}, - "type": "object" - } - }, - "type": "object" - }, - "name": { - "const": "find", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "arguments": { - "additionalProperties": false, - "properties": { - "query": { - "additionalProperties": true, - "description": "A filter/query parameter. Allows users to filter the documents to count. Matches the syntax of the filter argument of db.collection.count().", - "properties": {}, - "type": "object" - } - }, - "type": "object" - }, - "name": { - "const": "count", - "type": "string" - } - }, - "required": [ - "name", - "arguments" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "arguments": { + "additionalProperties": false, + "properties": { + "pipeline": { + "description": "An array of aggregation stages to execute.", + "items": { + "additionalProperties": true, + "properties": {}, + "type": "object" + }, + "type": "array" + }, + "responseBytesLimit": { + "default": 1048576, + "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire aggregation result is required, use the \"export\" tool instead of increasing this limit.", + "type": "number" + } + }, + "required": [ + "pipeline" + ], + "type": "object" + }, + "name": { + "const": "aggregate", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "arguments": { + "additionalProperties": false, + "properties": { + "filter": { + "additionalProperties": true, + "description": "The query filter, matching the syntax of the query argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "limit": { + "default": 10, + "description": "The maximum number of documents to return", + "type": "number" + }, + "projection": { + "additionalProperties": true, + "description": "The projection, matching the syntax of the projection argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "responseBytesLimit": { + "default": 1048576, + "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire query result is required, use the \"export\" tool instead of increasing this limit.", + "type": "number" + }, + "sort": { + "additionalProperties": {}, + "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", + "properties": {}, + "type": "object" + } + }, + "type": "object" + }, + "name": { + "const": "find", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "arguments": { + "additionalProperties": false, + "properties": { + "query": { + "additionalProperties": true, + "description": "A filter/query parameter. Allows users to filter the documents to count. Matches the syntax of the filter argument of db.collection.count().", + "properties": {}, + "type": "object" + } + }, + "type": "object" + }, + "name": { + "const": "count", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + } +] - added
Input schema / properties / verbosityAdded value: +{ + "default": "queryPlanner", + "description": "The verbosity of the explain plan, defaults to queryPlanner. If the user wants to know how fast is a query in execution time, use executionStats. It supports all verbosities as defined in the MongoDB Driver.", + "enum": [ + "queryPlanner", + "queryPlannerExtended", + "executionStats", + "allPlansExecution" + ], + "type": "string" +}
- Changed
export6 fields changed- added
Input schema / properties / exportTargetAdded value: +{ + "description": "The export target along with its arguments.", + "items": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "arguments": { + "additionalProperties": false, + "description": "The arguments for 'find' operation.", + "properties": { + "filter": { + "additionalProperties": true, + "description": "The query filter, matching the syntax of the query argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "limit": { + "type": "number" + }, + "projection": { + "additionalProperties": true, + "description": "The projection, matching the syntax of the projection argument of db.collection.find()", + "properties": {}, + "type": "object" + }, + "responseBytesLimit": { + "default": 1048576, + "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire query result is required, use the \"export\" tool instead of increasing this limit.", + "type": "number" + }, + "sort": { + "additionalProperties": {}, + "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", + "properties": {}, + "type": "object" + } + }, + "type": "object" + }, + "name": { + "const": "find", + "description": "The literal name 'find' to represent a find cursor as target.", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "arguments": { + "additionalProperties": false, + "description": "The arguments for 'aggregate' operation.", + "properties": { + "pipeline": { + "description": "An array of aggregation stages to execute.", + "items": { + "additionalProperties": true, + "properties": {}, + "type": "object" + }, + "type": "array" + }, + "responseBytesLimit": { + "default": 1048576, + "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire aggregation result is required, use the \"export\" tool instead of increasing this limit.", + "type": "number" + } + }, + "required": [ + "pipeline" + ], + "type": "object" + }, + "name": { + "const": "aggregate", + "description": "The literal name 'aggregate' to represent an aggregation cursor as target.", + "type": "string" + } + }, + "required": [ + "name", + "arguments" + ], + "type": "object" + } + ] + }, + "type": "array" +} - removed
Input schema / properties / filterRemoved value: -{ - "additionalProperties": true, - "description": "The query filter, matching the syntax of the query argument of db.collection.find()", - "properties": {}, - "type": "object" -} - removed
Input schema / properties / limitRemoved value: -{ - "description": "The maximum number of documents to return", - "type": "number" -} - removed
Input schema / properties / projectionRemoved value: -{ - "additionalProperties": true, - "description": "The projection, matching the syntax of the projection argument of db.collection.find()", - "properties": {}, - "type": "object" -} - removed
Input schema / properties / sortRemoved value: -{ - "additionalProperties": {}, - "description": "A document, describing the sort order, matching the syntax of the sort argument of cursor.sort(). The keys of the object are the fields to sort on, while the values are the sort directions (1 for ascending, -1 for descending).", - "properties": {}, - "type": "object" -} - changed
Input schema / requiredPrevious value: -[ - "exportTitle", - "database", - "collection" -]New value: +[ + "database", + "collection", + "exportTitle", + "exportTarget" +]
- Changed
find1 field changed- added
Input schema / properties / responseBytesLimitAdded value: +{ + "default": 1048576, + "description": "The maximum number of bytes to return in the response. This value is capped by the server's configured maxBytesPerQuery and cannot be exceeded. Note to LLM: If the entire query result is required, use the \"export\" tool instead of increasing this limit.", + "type": "number" +}
- Removed
insert-many - Changed
list-databases2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "databases": { + "items": { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "size": { + "type": "number" + } + }, + "required": [ + "name", + "size" + ], + "type": "object" + }, + "type": "array" + }, + "totalCount": { + "type": "number" + } + }, + "required": [ + "databases", + "totalCount" + ], + "type": "object" +}
- Removed
rename-collection - Removed
update-many
21 tool updates
- First observed
aggregate - First observed
collection-indexes - First observed
collection-schema - First observed
collection-storage-size - First observed
connect - First observed
count - First observed
create-collection - First observed
create-index - First observed
db-stats - First observed
delete-many - First observed
drop-collection - First observed
drop-database - First observed
explain - First observed
export - First observed
find - First observed
insert-many - First observed
list-collections - First observed
list-databases - First observed
mongodb-logs - First observed
rename-collection - First observed
update-many
TDQS
Scored across 28 tools
Most tools have distinct purposes: find, count, aggregate, export, and explain are clearly separate query operations. The Atlas tools are well-prefixed and target different resources. Minor confusion exists between aggregate and aggregate-db, and between connect and atlas-connect-cluster, but descriptions clarify the distinction.
Naming conventions are mixed: some tools use verb-first style (find, count, export, connect), some use noun-only (collection-indexes, db-stats), and the Atlas group consistently uses atlas-* prefix. This is readable but lacks a uniform pattern, making it less predictable.
With 28 tools, the server exceeds the 25-tool threshold for 'too many'. While the breadth reflects both core MongoDB operations and Atlas management, the large count can overwhelm agents, especially with many similar list/inspect tools. A leaner set or grouping would improve usability.
The tool surface is heavily read/analysis-oriented (find, aggregate, explain, export) and includes Atlas admin operations, but it lacks fundamental write/update/delete operations for documents and collections. Agents cannot perform mutations, which is a significant gap for a MongoDB server.
Maintenance
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
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.
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
Related MCP Servers
- AlicenseAqualityDmaintenanceA Model Context Protocol server that provides read-only access to MongoDB databases, enabling AI assistants to directly query and analyze MongoDB data while maintaining data safety.1465 npm9MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables LLMs to interact directly with MongoDB databases, allowing users to query collections, inspect schemas, and manage data through natural language.34 npm2MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables LLMs to interact directly with MongoDB databases, allowing users to query collections, inspect schemas, and manage data through natural language.34 npmMIT
- AlicenseAqualityBmaintenanceA Model Context Protocol server that enables interaction with MongoDB databases and MongoDB Atlas, allowing users to perform database operations and manage Atlas resources through natural language.2298,382 npmApache 2.0