Skip to main content
Glama
hendrickcastro

MCP CosmosDB

mcp_execute_query

Execute SQL queries on CosmosDB containers to retrieve and analyze document data with parameter support and cross-partition capabilities.

Instructions

Execute a SQL query against a CosmosDB container

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
container_idYesThe ID of the container to query
queryYesThe SQL query to execute
parametersNoOptional parameters for the query as key-value pairs
max_itemsNoMaximum number of items to return
enable_cross_partitionNoWhether to enable cross-partition queries

Implementation Reference

  • Core implementation of the mcp_execute_query tool handler. Executes SQL queries on CosmosDB containers, supports parameters, limits results, and returns documents with query statistics.
    export const mcp_execute_query = async (args: { 
      container_id: string; 
      query: string; 
      parameters?: Record<string, any>;
      max_items?: number;
      enable_cross_partition?: boolean;
    }): Promise<ToolResult<{ documents: any[]; stats: QueryStats }>> => {
      const { container_id, query, parameters, max_items = 100, enable_cross_partition = true } = args;
      console.log('Executing mcp_execute_query with:', args);
    
      try {
        const container = getContainer(container_id);
        const startTime = Date.now();
    
        // Prepare query spec
        const querySpec = {
          query,
          parameters: parameters ? Object.entries(parameters).map(([name, value]) => ({ name: `@${name}`, value })) : []
        };
    
        // Execute query
        const queryIterator = container.items.query(querySpec, {
          maxItemCount: max_items
        });
    
        const { resources: documents, requestCharge } = await queryIterator.fetchAll();
        const executionTimeMs = Date.now() - startTime;
    
        const stats: QueryStats = {
          requestCharge,
          executionTimeMs,
          documentCount: documents.length
        };
    
        return { success: true, data: { documents, stats } };
      } catch (error: any) {
        console.error(`Error in mcp_execute_query for container ${container_id}: ${error.message}`);
        return { success: false, error: error.message };
      }
    };
  • Tool metadata and JSON input schema definition for mcp_execute_query, used for tool discovery and validation.
    {
      name: "mcp_execute_query",
      description: "Execute a SQL query against a CosmosDB container",
      inputSchema: {
        type: "object",
        properties: {
          container_id: {
            type: "string",
            description: "The ID of the container to query"
          },
          query: {
            type: "string",
            description: "The SQL query to execute"
          },
          parameters: {
            type: "object",
            description: "Optional parameters for the query as key-value pairs"
          },
          max_items: {
            type: "number",
            description: "Maximum number of items to return",
            default: 100
          },
          enable_cross_partition: {
            type: "boolean",
            description: "Whether to enable cross-partition queries",
            default: true
          }
        },
        required: ["container_id", "query"]
      }
    },
  • src/server.ts:63-66 (registration)
    Registration of tool list handler, exposing MCP_COSMOSDB_TOOLS (including mcp_execute_query schema) for MCP tool discovery.
    // @ts-ignore - Bypass TypeScript errors from the SDK's types
    server.setRequestHandler(ListToolsRequestSchema, async () => ({
        tools: MCP_COSMOSDB_TOOLS
    }));
  • src/server.ts:103-105 (registration)
    Dispatch/execution routing for mcp_execute_query tool call in the MCP CallToolRequest handler.
    case 'mcp_execute_query':
        result = await toolHandlers.mcp_execute_query(input as any);
        break;
  • Type definitions for QueryStats used in the tool's return type.
    export interface QueryStats {
      requestCharge: number;
      executionTimeMs: number;
      documentCount: number;
      indexHitRatio?: number;
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic action but omits critical details: whether this is a read-only or write operation (SQL queries could be SELECT or UPDATE), potential side effects, authentication requirements, rate limits, error handling, or response format. For a tool executing arbitrary SQL, this is a significant gap in transparency.

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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for the tool's complexity, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the complexity (executing arbitrary SQL queries against a database), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't address behavioral risks, return values, error conditions, or sibling tool differentiation. For a potentially powerful/mutating tool, this leaves the agent under-informed.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema fully documents all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain query syntax, parameter binding formats, or practical examples. The baseline score of 3 reflects adequate but minimal value added by the description.

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 ('Execute a SQL query') and target resource ('against a CosmosDB container'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like mcp_get_documents or mcp_analyze_schema, which might also involve querying or analyzing data.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like mcp_get_documents (for simpler retrieval) or mcp_analyze_schema (for schema analysis). It lacks context about appropriate use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name 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/hendrickcastro/MCPCosmosDB'

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