Skip to main content
Glama
jonfreeland

MongoDB MCP Server

by jonfreeland

get_indexes

Retrieve detailed information about MongoDB collection indexes, including names, fields, types, sizes, options, and usage statistics to optimize database performance.

Instructions

Get information about indexes on a collection.

Returns details about:

  • Index names and fields

  • Index types (single field, compound, text, etc.)

  • Index sizes

  • Index options

  • Usage statistics

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
databaseNoDatabase name (optional if default database is configured)
collectionYesCollection name

Implementation Reference

  • Handler for 'get_indexes' tool: connects to the specified database, retrieves the indexes for the given collection using MongoDB's indexes() method, and returns the results as formatted JSON text content.
    case 'get_indexes': {
      const { database, collection } = request.params.arguments as {
        database?: string;
        collection: string;
      };
      const dbName = database || this.defaultDatabase;
      if (!dbName) {
        throw new McpError(
          ErrorCode.InvalidRequest,
          'Database name is required when no default database is configured'
        );
      }
    
      const db = client.db(dbName);
      const indexes = await db.collection(collection).indexes();
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(indexes, null, 2),
          },
        ],
      };
    }
  • src/index.ts:576-598 (registration)
    Registration of the 'get_indexes' tool in the list_tools response, including name, description, and input schema definition.
              name: 'get_indexes',
              description: `Get information about indexes on a collection.
    
    Returns details about:
    - Index names and fields
    - Index types (single field, compound, text, etc.)
    - Index sizes
    - Index options
    - Usage statistics`,
              inputSchema: {
                type: 'object',
                properties: {
                  database: {
                    type: 'string',
                    description: 'Database name (optional if default database is configured)',
                  },
                  collection: {
                    type: 'string',
                    description: 'Collection name',
                  },
                },
                required: ['collection'],
              },
  • Input schema definition for the 'get_indexes' tool, specifying parameters for database (optional) and required collection name.
              name: 'get_indexes',
              description: `Get information about indexes on a collection.
    
    Returns details about:
    - Index names and fields
    - Index types (single field, compound, text, etc.)
    - Index sizes
    - Index options
    - Usage statistics`,
              inputSchema: {
                type: 'object',
                properties: {
                  database: {
                    type: 'string',
                    description: 'Database name (optional if default database is configured)',
                  },
                  collection: {
                    type: 'string',
                    description: 'Collection name',
                  },
                },
                required: ['collection'],
              },
Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses return details (index names, types, sizes, etc.), which is helpful. However, it lacks critical behavioral traits: whether this is a read-only operation, performance implications (e.g., if it locks the collection), authentication needs, or rate limits. For a tool with zero annotation coverage, this is insufficient.

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 efficiently structured: a clear purpose statement followed by a bulleted list of return details. Every sentence (and bullet point) earns its place by providing specific value. No wasted words or redundancy.

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

Completeness3/5

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

Given 2 parameters with full schema coverage, no output schema, and no annotations, the description is adequate but has gaps. It explains what information is returned, which compensates for missing output schema. However, for a tool that likely interacts with a database system, more behavioral context (e.g., read-only nature, performance impact) would improve completeness.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents both parameters (database and collection). The description adds no parameter-specific information beyond what's in the schema (e.g., no examples, format details, or constraints). Baseline 3 is appropriate when the schema does all the work.

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 tool's purpose: 'Get information about indexes on a collection' (verb+resource). It distinguishes from siblings like 'get_collection_stats' or 'get_schema' by focusing specifically on indexes. However, it doesn't explicitly differentiate from all possible alternatives, keeping it at 4 rather than 5.

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

Usage Guidelines3/5

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

The description implies usage context through 'on a collection,' suggesting this is for database/collection analysis. However, it provides no explicit guidance on when to use this vs. alternatives like 'get_collection_stats' (which might include index info) or 'explain_query' (which uses indexes). No when-not-to-use or prerequisite information is included.

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/jonfreeland/mongodb-mcp'

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