Skip to main content
Glama
mongodb-js

MongoDB MCP Server

Official
by mongodb-js

atlas-connect-cluster

Read-only

Connect to a MongoDB Atlas cluster by specifying project ID, cluster name, and connection type for database operations and management.

Instructions

Connect to MongoDB Atlas cluster

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectIdYesAtlas project ID
clusterNameYesAtlas cluster name
connectionTypeNoType of connection (standard, private, or privateEndpoint) to an Atlas clusterstandard

Implementation Reference

  • The main handler function that executes the tool logic: disconnects if needed, prepares connection string with temporary user, adds IP to access list, attempts connection with retries, and returns appropriate messages.
    protected async execute({
        projectId,
        clusterName,
        connectionType,
    }: ToolArgs<typeof this.argsShape>): Promise<CallToolResult> {
        const ipAccessListUpdated = await ensureCurrentIpInAccessList(this.session.apiClient, projectId);
        let createdUser = false;
    
        const state = this.queryConnection(projectId, clusterName);
        switch (state) {
            case "connected-to-other-cluster":
            case "disconnected": {
                await this.session.disconnect();
    
                const { connectionString, atlas } = await this.prepareClusterConnection(
                    projectId,
                    clusterName,
                    connectionType
                );
    
                createdUser = true;
    
                // try to connect for about 5 minutes asynchronously
                void this.connectToCluster(connectionString, atlas).catch((err: unknown) => {
                    const error = err instanceof Error ? err : new Error(String(err));
                    this.session.logger.error({
                        id: LogId.atlasConnectFailure,
                        context: "atlas-connect-cluster",
                        message: `error connecting to cluster: ${error.message}`,
                    });
                });
                break;
            }
            case "connecting":
            case "connected":
            case "unknown":
            default: {
                break;
            }
        }
    
        for (let i = 0; i < 60; i++) {
            const state = this.queryConnection(projectId, clusterName);
            switch (state) {
                case "connected": {
                    const content: CallToolResult["content"] = [
                        {
                            type: "text",
                            text: `Connected to cluster "${clusterName}".`,
                        },
                    ];
    
                    if (ipAccessListUpdated) {
                        content.push({
                            type: "text",
                            text: addedIpAccessListMessage,
                        });
                    }
    
                    if (createdUser) {
                        content.push({
                            type: "text",
                            text: createdUserMessage,
                        });
                    }
    
                    return { content };
                }
                case "connecting":
                case "unknown":
                case "connected-to-other-cluster":
                case "disconnected":
                default: {
                    break;
                }
            }
    
            await sleep(500); // wait 500ms before checking the connection state again
        }
    
        const content: CallToolResult["content"] = [
            {
                type: "text" as const,
                text: `Attempting to connect to cluster "${clusterName}"...`,
            },
            {
                type: "text" as const,
                text: `Warning: Provisioning a user and connecting to the cluster may take more time, please check again in a few seconds.`,
            },
        ];
    
        if (ipAccessListUpdated) {
            content.push({
                type: "text" as const,
                text: addedIpAccessListMessage,
            });
        }
    
        if (createdUser) {
            content.push({
                type: "text" as const,
                text: createdUserMessage,
            });
        }
    
        return { content };
    }
  • Input schema defining the arguments for the atlas-connect-cluster tool.
    export const ConnectClusterArgs = {
        projectId: AtlasArgs.projectId().describe("Atlas project ID"),
        clusterName: AtlasArgs.clusterName().describe("Atlas cluster name"),
        connectionType: AtlasArgs.connectionType().describe(
            "Type of connection (standard, private, or privateEndpoint) to an Atlas cluster"
        ),
    };
  • Registration of all tools, including Atlas tools (which include ConnectClusterTool via barrel re-export from src/tools/atlas/tools.ts).
    import * as AtlasTools from "./atlas/tools.js";
    import * as AtlasLocalTools from "./atlasLocal/tools.js";
    import * as MongoDbTools from "./mongodb/tools.js";
    import type { ToolClass } from "./tool.js";
    
    // Export the collection of tools for easier reference
    export const AllTools: ToolClass[] = Object.values({
        ...MongoDbTools,
        ...AtlasTools,
        ...AtlasLocalTools,
    });
  • Barrel export that makes ConnectClusterTool available for inclusion in the main tools registry.
    export { ConnectClusterTool } from "./connect/connectCluster.js";
Behavior3/5

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, non-destructive operation. The description adds no behavioral context beyond the annotations - it doesn't explain what 'Connect to' means operationally (e.g., establishes a session, returns connection details, enables subsequent operations), nor does it mention any side effects, authentication requirements, or rate limits.

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

Conciseness5/5

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

The description is a single, clear sentence with zero wasted words. It's appropriately sized for a tool with good schema documentation and annotations, and it front-loads the essential information (verb + resource). Every word earns its place.

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

Completeness3/5

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

For a connection tool with read-only annotations and full parameter documentation, the description is minimally adequate. However, it lacks important context about what 'Connect to' actually means operationally - whether it returns connection details, establishes a session for subsequent operations, or has any prerequisites. Without an output schema, the description should ideally hint at what the connection result looks like.

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

Parameters3/5

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

With 100% schema description coverage, all parameters are already documented in the schema. The description adds no additional meaning about parameters - it doesn't explain why these specific parameters are needed, how they relate to the connection process, or provide usage examples. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Connect to') and resource ('MongoDB Atlas cluster'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'connect' or 'atlas-list-clusters', but the verb 'Connect to' is more specific than generic 'connect' and implies establishing a connection rather than listing resources.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication, relationship to other tools (e.g., whether you need to list clusters first), or what happens after connection is established. The agent must infer usage from the name and parameters alone.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mongodb-js/mongodb-mcp-server'

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