Skip to main content
Glama
hendrickcastro

MCP CosmosDB

mcp_list_containers

List all containers in a connected CosmosDB database to discover available containers, their partition key paths, and indexing policies for query planning.

Instructions

List all containers in the connected CosmosDB database. Use this to discover available containers and their partition key configurations before querying data. Returns container IDs, partition key paths, and indexing policies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
connection_idNoID of the connection to use. Use mcp_list_connections to see available connections. If not specified, uses the default connection.

Implementation Reference

  • Handler function that lists all containers in the CosmosDB database. Accepts an optional connection_id, fetches all containers via database.containers.readAll(), maps results to ContainerInfo objects with id, partitionKey, indexingPolicy, etag, and timestamp fields.
    export const mcp_list_containers = async (args?: { connection_id?: string }): Promise<ToolResult<ContainerInfo[]>> => {
      const connection_id = args?.connection_id;
      log(`Executing mcp_list_containers with connection_id: ${connection_id || 'default'}`);
    
      try {
        const database = getDatabase(connection_id);
        const { resources: containers } = await database.containers.readAll().fetchAll();
        
        const containersInfo: ContainerInfo[] = containers.map((container: any) => ({
          id: container.id,
          partitionKey: container.partitionKey ? {
            paths: container.partitionKey.paths || [],
            kind: container.partitionKey.kind
          } : undefined,
          indexingPolicy: container.indexingPolicy,
          etag: container._etag,
          timestamp: container._ts ? new Date(container._ts * 1000) : undefined
        }));
    
        return { success: true, data: containersInfo };
      } catch (error: any) {
        log(`Error in mcp_list_containers: ${error.message}`);
        return { success: false, error: error.message };
      }
    };
  • Type definition for ContainerInfo returned by the mcp_list_containers handler.
    export interface ContainerInfo {
      id: string;
      partitionKey?: {
        paths: string[];
        kind?: string;
      };
      throughput?: number;
      indexingPolicy?: any;
      etag?: string;
      timestamp?: Date;
    }
  • Input schema definition for the mcp_list_containers tool. Has an optional connection_id property and no required fields.
    // 2. Container Operations
    {
      name: "mcp_list_containers",
      description: "List all containers in the connected CosmosDB database. Use this to discover available containers and their partition key configurations before querying data. Returns container IDs, partition key paths, and indexing policies.",
      inputSchema: {
        type: "object",
        properties: {
          ...connectionIdProperty
        },
        required: []
      }
    },
  • src/server.ts:122-124 (registration)
    Registration in the MCP server: routes the 'mcp_list_containers' tool name to the handler function via the CallToolRequestSchema switch statement.
    case 'mcp_list_containers':
        result = await toolHandlers.mcp_list_containers(input as any);
        break;
  • Re-exports the mcp_list_containers handler from containerAnalysis.ts for centralized import in mcp-server.ts.
    export {
      mcp_list_databases,
      mcp_list_containers,
      mcp_get_container_definition,
      mcp_get_container_stats
    } from './containerAnalysis.js';
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses return types (container IDs, partition key paths, indexing policies) and implies a safe read operation. It does not mention auth or rate limits, but given the nature of the tool, this is adequate.

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 consists of exactly two sentences, with the essential purpose in the first sentence. Every word earns its place, and there is no fluff or redundant information.

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

Completeness5/5

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

Given the tool's low complexity (single optional parameter, no output schema), the description fully covers what the tool does, when to use it, and what it returns. No gaps remain for an agent to misinterpret.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already describes the optional connection_id parameter. The description does not add further meaning to this parameter, but it adds value by explaining the overall return structure and purpose of the results.

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

Purpose5/5

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

The description clearly states the action ('List all containers') and the resource ('connected CosmosDB database'), and it distinguishes itself from siblings like mcp_get_container_definition and mcp_list_databases by specifying scope ('all containers') and mention of partition key configurations.

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

Usage Guidelines4/5

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

The description provides explicit usage context: 'Use this to discover available containers and their partition key configurations before querying data.' It does not explicitly state when not to use it or name alternatives, but the context is clear and sufficient for most cases.

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/hendrickcastro/MCPCosmosDB'

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