Skip to main content
Glama

cribl_listWorkerGroups

List worker groups in your Cribl deployment, optionally filtered by product type (stream, edge, search, or all) to manage and query cluster resources.

Instructions

Lists available worker groups in the Cribl deployment, optionally filtered by product type (stream, edge, search, or all).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
productTypeNoFilter groups by product type (stream, edge, search, all). Defaults to stream.

Implementation Reference

  • src/server.ts:106-138 (registration)
    Registration of the 'cribl_listWorkerGroups' tool on the MCP server, including the Zod schema for arguments (productType filter) and the handler callback.
    server.tool(
        'cribl_listWorkerGroups',
        'Lists available worker groups in the Cribl deployment, optionally filtered by product type (stream, edge, search, or all).',
        ListWorkerGroupsArgsShape,
        async (args: ValidatedArgs<typeof ListWorkerGroupsArgsShape>) => {
            const { productType } = args;
            console.error(`[Tool Call] cribl_listWorkerGroups (Filtering for: ${productType})`);
            const result = await listWorkerGroups();
    
            if (!result.success || !result.data) {
                console.error('[Tool Error] cribl_listWorkerGroups:', result.error);
                return {
                    isError: true,
                    content: [{ type: 'text', text: `Error listing worker groups: ${result.error || 'Unknown error'}` }],
                };
            }
    
            // Filter based on productType, skip if 'all'
            const groupsToReturn = productType === 'all' 
                ? result.data 
                : result.data.filter(group => {
                    if (productType === 'stream') return !group.isFleet && !group.isSearch;
                    if (productType === 'edge') return group.isFleet === true;
                    if (productType === 'search') return group.isSearch === true;
                    return false; // Should not happen
                 });
    
            console.error(`[Tool Success] cribl_listWorkerGroups: Found ${groupsToReturn.length} groups matching filter '${productType}'.`);
            return {
                content: [{ type: 'text', text: JSON.stringify(groupsToReturn, null, 2) }],
            };
        }
    );
  • Handler function for cribl_listWorkerGroups. It calls listWorkerGroups() from the API client, filters results by productType (stream/edge/search/all), and returns the matching worker groups as JSON.
        async (args: ValidatedArgs<typeof ListWorkerGroupsArgsShape>) => {
            const { productType } = args;
            console.error(`[Tool Call] cribl_listWorkerGroups (Filtering for: ${productType})`);
            const result = await listWorkerGroups();
    
            if (!result.success || !result.data) {
                console.error('[Tool Error] cribl_listWorkerGroups:', result.error);
                return {
                    isError: true,
                    content: [{ type: 'text', text: `Error listing worker groups: ${result.error || 'Unknown error'}` }],
                };
            }
    
            // Filter based on productType, skip if 'all'
            const groupsToReturn = productType === 'all' 
                ? result.data 
                : result.data.filter(group => {
                    if (productType === 'stream') return !group.isFleet && !group.isSearch;
                    if (productType === 'edge') return group.isFleet === true;
                    if (productType === 'search') return group.isSearch === true;
                    return false; // Should not happen
                 });
    
            console.error(`[Tool Success] cribl_listWorkerGroups: Found ${groupsToReturn.length} groups matching filter '${productType}'.`);
            return {
                content: [{ type: 'text', text: JSON.stringify(groupsToReturn, null, 2) }],
            };
        }
    );
  • Zod schema definition for the 'productType' argument of cribl_listWorkerGroups. Accepts 'stream', 'edge', 'search', or 'all', defaulting to 'stream'.
    // Define schema for listWorkerGroups arguments
    const ListWorkerGroupsArgsShape = {
        productType: z.preprocess(
            (val) => (val === null || val === undefined || val === '' ? 'stream' : val), // Map null/undefined/empty to default
            z.enum(['stream', 'edge', 'search', 'all'])
        ).describe('Filter groups by product type (stream, edge, search, all). Defaults to stream.'),
    };
  • The listWorkerGroups() API client function that performs the GET /api/v1/master/groups HTTP request to fetch all worker groups from the Cribl leader.
    export async function listWorkerGroups(): Promise<ClientResult<CriblWorkerGroup[]>> {
        const context = 'listWorkerGroups';
        // Using /master/groups path as it reportedly worked previously
        const url = '/api/v1/master/groups'; 
        console.error(`[stderr] Attempting API call: GET ${url}`);
        try {
            // Assuming the response structure has an 'items' array
            const response = await apiClient.get<CriblApiResponse>(url); 
            return { success: true, data: response.data.items as CriblWorkerGroup[] };
        } catch (error) {
            const errorMessage = handleApiError(error, context);
            return { success: false, error: errorMessage };
        }
    }
Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the action but fails to mention any behavioral traits such as rate limits, authentication requirements, the format of the returned data, or behavior when no groups are available. The description is minimal and does not go beyond the basic action.

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 sentence that front-loads the main action and includes the key optional feature. Every word is necessary, and there is no redundancy or extraneous information.

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

Completeness4/5

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

Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is largely complete. It conveys the core functionality and the filter option. However, it does not specify the output format or any edge cases, which would be beneficial for an agent but not critical for this straightforward listing tool.

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?

The input schema has 100% description coverage, documenting the single parameter with enum and description. The description adds the phrase 'optionally filtered by product type (stream, edge, search, or all)', which reinforces the schema's content and clarifies optionality. However, the added value is marginal, placing it at the baseline for high schema coverage.

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?

Description clearly states the tool lists available worker groups in the Cribl deployment, with an optional filter by product type. The verb 'list' and resource 'worker groups' are specific, and the filtering option is mentioned, distinguishing it from sibling tools that deal with pipelines, sources, or metrics.

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 when needing to view worker groups, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. With no sibling tools performing the same function, the context is clear, but explicit guidelines are missing.

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/pebbletek/cribl-mcp'

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