Skip to main content
Glama
deenesjakoruzh
pebbletek

cribl-mcp

by pebbletek
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Cribl MCP Server

npm version License

A Model Context Protocol (MCP) server that enables AI interactions with the Cribl API.

This server allows AI clients to discover and invoke data operations from a Cribl deployment, using standardised MCP tooling.

For detailed documentation, please see the docs/ directory. Here's a breakdown of the documentation files:

  • README.md (this file): Provides the highest-level introduction, quick start instructions, very basic examples, and links to the docs directory.

  • docs/configuration.md: Focuses specifically on the environment variables needed for configuration and explains the authentication modes. It's purely about setup.

  • docs/usage.md: Focuses on how to run the server (via npx or local development commands) and how to configure an MCP client to connect to it. It provides conceptual examples of invoking the tools.

  • docs/overview.md: Sits between the README and the specific config/usage docs. It details what the server offers in terms of authentication and, most importantly, provides a detailed reference guide to the available tools and their specific parameters/outputs, and future tools.

Getting Started

You can either install and run locally, or execute instantly via npx. npx saves you installing Git, dependencies, or any build tools. Both scenarios require you to have node later than version 16 installed:

Prerequisites

To run this server ensure the following:

  • Node.js is installed (version 16 or later recommended)

  • Internet access is available (to fetch the MCP server package from npm)

You can install Node.js from https://nodejs.org.

To verify your setup:

node -v
npx -v

Quick Start with npx

CRIBL_BASE_URL=https://your.cribl.cloud.instance CRIBL_AUTH_TYPE=cloud CRIBL_CLIENT_ID=abc123 CRIBL_CLIENT_SECRET=secret npx @pebbletek/cribl-mcp

Note: Running npx requires essential environment variables (like CRIBL_BASE_URL and authentication details) to be set either in your environment or passed directly on the command line for the server to connect successfully.

See docs/usage.md for advanced npx usage configuration, including relevant JSON for your MCP client, and required variables.

Local Development

  1. Browse to a high-level folder where you'll store the code base (cloning will create the containing folder). Clone the repo:

    git clone https://github.com/pebbletek/cribl-mcp.git
cd cribl-mcp

  2. Install dependencies:

    npm install

  3. Copy the .env.example file and populate the required values:

    cp .env.example .env

  4. See usage.md > Local Development for running, building and starting the mcp server

See docs/configuration.md for details on environment variables and authentication, and docs/usage.md for running the server.

Related MCP server: splunk-mcp-server

Available Tools

This server provides tools to interact with Cribl, including:

  • Listing Worker Groups/Fleets

  • Getting/Setting Pipeline configurations

  • Getting Source configurations

  • Restarting Worker Groups

  • Querying System Metrics (with filtering)

For a detailed list and usage instructions, see docs/usage.md.

Example Usage (Prompts)

Once connected via an MCP client (like Claude Desktop), you can interact with your Cribl instance using natural language prompts that leverage the available tools. Here are some examples:

  • Prompt: what sources are we ingesting?
    (you will need to allow the MCP client access to the tool)

    • Response will be something like:
      "To answer your question about ingested sources, let me check the available data sources in your Cribl Stream environment.
      <View result from cribl_getSources from Cribl (local)>

      Let me also check what pipelines are configured in your Cribl Stream environment:
      <View result from cribl_getPipelines from Cribl (local)>

      Based on the information I've retrieved from your Cribl Stream environment, here are the sources you are ingesting:
      Active Data Sources
      Your Cribl Stream instance has several configured data sources, with the following notable ones:

      1. HTTP/HTTPS Sources:
        HTTP source (port 10080)
        Cribl HTTP (port 10200)
        Splunk HEC (port 8088)...

      2. <etc.>

      Pipeline Configurations
      Your environment also has several pipelines configured for processing specific data types:

      1. Cisco ASA events - Filters and samples Cisco ASA security logs

      2. Cisco eStreamer data - Processes Cisco eStreamer data

      3. Palo Alto traffic events - Filters and samples Palo Alto traffic logs

      4. Windows Event Logs - Processes Windows security event logs

      These pipelines suggest you're ingesting network security logs from Cisco ASA firewalls, Cisco eStreamer (likely from Firepower/FTD devices), Palo Alto Networks firewalls, and Windows security events.
      Would you like more detailed information about any specific source or pipeline configuration?"

  • Prompt: what functions are processing the palo alto traffic?

    • Response:
      "Let me examine the functions that are processing the Palo Alto traffic in more detail:
      <View result from cribl_getPipelineConfig from Cribl (local)>

      Here's a detailed breakdown of how the Palo Alto traffic data is being processed in your Cribl Stream environment:
      Palo Alto Traffic Pipeline Functions
      1. Initial Filter (Eval):

      • Filter: sourcetype!='pan:traffic'

      • Description: Short-circuits (skips) all events that are NOT of sourcetype 'pan'

      • This is set as a final function, meaning if the condition is true, processing stops for that event

      2. Field Extraction (Regex Extract):

      • Extracts several key fields from the raw event using regex pattern matching:

        • __log_subtype: Identifies if the log is a start/end record

        • __src_zone and __dest_zone: Source and destination security zones

        • __transport: Transport protocol

        • __action: Action taken (allow, deny, etc.)

        • __bytes_in: Bytes received

      3. Filtering Events (Drop):

      • Filter: __log_subtype=='start'

      • Description: Drops all events with log subtype of 'start'

      • Rationale (from comment): "Drop events of log_subtype=start as they often have incorrect app assignment. Log_subtype=end contain better information."

      • etc."

  • Prompt: please update the pipeline to include start events as well as end events.

    • Response:
      "I'll update the Palo Alto traffic pipeline to include both "start" and "end" events by modifying the configuration. Let me make this change for you:
      <View result from cribl_getPipelineConfig from Cribl (local)>

      Now I'll update the pipeline configuration to keep both "start" and "end" events by disabling the drop function and updating the comments:
      <View result from cribl_setPipelineConfig from Cribl (local)>

      Now let's restart the worker group to apply these changes: <View result from cribl_restartWorkerGroup from Cribl (local)>

      The Palo Alto traffic pipeline has been successfully updated to include both "start" and "end" events. Here's what I modified:

      1. Disabled the Drop Function:

        • The function that was filtering out __log_subtype=='start' events has been disabled

        • This means both "start" and "end" session events will now be processed

      2. Updated the Comment:

        • Changed the comment from explaining why "start" events were being dropped to noting that both event types are now being kept for complete traffic visibility

      3. Restarted the Worker Group:

        • Applied the changes by restarting the Cribl Stream worker group

      The updated pipeline will now process both "start" and "end" events from your Palo Alto firewalls, giving you complete visibility into traffic sessions from initiation through completion. All other processing functions remain in place, including:

      • Field extraction for key traffic attributes

      • Sampling for zero-byte traffic and trusted zone traffic

      • Removal of unreliable date fields

      Your Palo Alto traffic data will now include the complete lifecycle of network connections while still maintaining the efficiency benefits of the sampling rules."

License

MIT

Available Tools

10 tools
cribl_commitPipelineA

Commits staged pipeline config changes to version control with a message. Returns detailed commit information including branch, commit ID, and summary of changed files.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesThe commit message.

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the full burden. It mentions returning commit information but does not disclose side effects, permissions required, or whether the operation is reversible. For a write operation, more behavioral context would be beneficial.

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 two concise sentences. The first sentence communicates the primary action and context, the second details the return value. No unnecessary words.

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 parameter, no output schema, no annotations), the description covers the essential aspects: what it does and what it returns. It could mention constraints like requiring a non-empty message (schema enforces minLength) but is largely complete.

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% coverage with a single parameter 'message' described as 'The commit message.' The description repeats 'with a message' but adds no additional meaning beyond what the schema provides.

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 'Commits' and the resource 'staged pipeline config changes to version control'. It effectively distinguishes from sibling tools like cribl_deployPipeline or cribl_setPipelineConfig by specifying the commit operation.

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 implies usage for committing staged changes but does not explicitly state when to use this tool versus alternatives like cribl_deployPipeline. However, the purpose is clear enough for an agent to infer context.

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

cribl_deployPipelineB

Deploys a specific committed configuration version to a worker group. Returns the list of ConfigGroup objects Cribl provides.

ParametersJSON Schema
NameRequiredDescriptionDefault
groupNameNoOptional: The name of the Worker Group/Fleet. If omitted, defaults to attempting to use Cribl Stream and if only one group exists for Stream, it will use that sole group.
versionYesThe commit ID (version) to deploy.

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It mentions return type but does not state whether deployment is destructive (overwrites existing), requires specific permissions, triggers restarts, or handles rollbacks. Lack of side-effect details limits agent understanding.

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?

Two sentences, no filler. Front-loaded with action and return type. Efficient for a simple tool.

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?

For a tool with only 2 parameters and no output schema, the description covers the core action and return. Could mention error conditions (e.g., invalid version or group), but overall sufficient for the tool's simplicity.

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%, and the description adds no extra meaning beyond what's in the schema. The description restates 'committed version' and 'worker group' but doesn't clarify format, constraints, or defaults beyond schema. Adequate but not enhanced.

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 verb ('Deploys'), resource ('committed configuration version to a worker group'), and return value ('list of ConfigGroup objects'). Distinct from siblings like cribl_commitPipeline (commits) and cribl_getPipelineConfig (retrieves).

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?

No explicit guidance on when to use this tool versus alternatives like cribl_setPipelineConfig or cribl_restartWorkerGroup. Does not mention prerequisites (e.g., need a committed version) or conditions where deployment might fail.

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

cribl_getPipelineConfigB

Retrieves full configuration JSON for a specified pipeline in a worker group.

ParametersJSON Schema
NameRequiredDescriptionDefault
groupNameNoOptional: The name of the Worker Group/Fleet. If omitted, defaults to attempting to use Cribl Stream and if only one group exists for Stream, it will use that sole group.
pipelineIdYesThe ID of the pipeline to retrieve configuration for.

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It states the operation is a retrieval, but omits details about potential errors (e.g., missing pipeline or group), performance implications, or authorization requirements. The limited transparency leaves the agent underinformed.

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, well-formed sentence that front-loads the core action. Every word is necessary; there is no redundancy or filler.

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 tool with two parameters and no annotations or output schema, the description is minimally adequate. It states the resource and action but lacks details on return format (beyond 'JSON'), error handling, or integration with sibling tools. It does not fully preempt common agent questions.

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 description adds minimal value beyond the parameter descriptions. It clarifies the return format ('full configuration JSON') but does not elaborate on parameter semantics beyond what the schema already provides. Baseline at 3 is appropriate.

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 uses a specific verb ('Retrieves') and clearly identifies the resource ('full configuration JSON for a specified pipeline in a worker group'). It distinguishes itself from siblings like 'cribl_getPipelines' by focusing on the full configuration of a single pipeline.

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, such as 'cribl_getPipelines' for listing pipelines, or 'cribl_setPipelineConfig' for updates. No prerequisites or contextual cues are given.

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

cribl_getPipelinesB

Fetches pipeline definitions in a specified worker group.

ParametersJSON Schema
NameRequiredDescriptionDefault
groupNameNoOptional: The name of the Worker Group/Fleet. If omitted, defaults to attempting to use Cribl Stream and if only one group exists for Stream, it will use that sole group.

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It states it fetches data (implying read-only) but does not explicitly confirm safety, idempotence, or any side effects. No mention of permissions 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, concise sentence that front-loads the core purpose without any fluff.

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 no output schema, the description should hint at return format or content, but it does not. It also does not clarify how this differs from similar sibling tools, leaving the agent with incomplete context.

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% and the schema already explains the parameter well. The tool description adds no additional semantics beyond what is in the schema, so baseline score of 3 is appropriate.

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 (fetches), resource (pipeline definitions), and context (in a specified worker group), distinguishing it from sibling tools like cribl_getPipelineConfig which retrieves config, not definitions.

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 does not provide any guidance on when to use this tool versus alternatives like cribl_getPipelineConfig or cribl_getSources, nor does it mention prerequisites or context.

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

cribl_getSourcesA

Fetches source configurations in a specified worker group.

ParametersJSON Schema
NameRequiredDescriptionDefault
groupNameNoOptional: The name of the Worker Group/Fleet. If omitted, defaults to attempting to use Cribl Stream and if only one group exists for Stream, it will use that sole group.

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. 'Fetches' implies a read-only operation with no side effects, but this is not explicitly stated. The description does disclose the default behavior when groupName is omitted, adding some 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 extremely concise: two sentences covering purpose and parameter behavior without any fluff. Every word is necessary.

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?

The tool has low complexity (one optional parameter, no nested objects, no output schema), but the description does not mention the return format or error cases. It provides enough context for basic usage but omits details about what 'source configurations' entails.

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

Parameters4/5

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

The schema covers the parameter at 100%, but the description adds value beyond the schema's description by explaining the default behavior when groupName is omitted, including the fallback logic for Cribl Stream groups.

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 ('Fetches'), the resource ('source configurations'), and the scope ('in a specified worker group'). It distinguishes itself from sibling tools like cribl_getPipelines or cribl_setPipelineConfig, which deal with pipelines.

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 does not explicitly state when to use this tool versus alternatives. However, the context of fetching source configurations is clear, and the optional parameter's default behavior is explained, which helps the agent decide if a worker group is needed.

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

cribl_getSystemMetricsA

Retrieves system metrics from the Cribl deployment. IMPORTANT: To avoid excessively large responses, please use the optional parameters (filterExpr, metricNameFilter, earliest, latest, numBuckets, wp) to narrow down your query whenever possible. If no parameters are provided, the server will default to fetching only the most recent data bucket (numBuckets=1) to prevent performance issues.

ParametersJSON Schema
NameRequiredDescriptionDefault
filterExprNoOptional: A JS expression to filter metrics (e.g., "model.pipeline === 'test'" or "host == 'myhost'").
metricNameFilterNoOptional: Regex or array of metric names (e.g.,limit to "pipe.*" , "total.in_bytes", or "os.cpu.perc,os.mem.*").
earliestNoOptional: Start time for the query (e.g., '-15m', '2023-10-26T10:00:00Z').
latestNoOptional: End time for the query (e.g., 'now', '2023-10-26T10:15:00Z').
numBucketsNoOptional: The number of time buckets for aggregation.
wpNoOptional: Worker process filter.

TDQS

A4.1/5.0
Behavior4/5

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

Without annotations, the description carries the full burden. It discloses the default behavior (fetches only most recent bucket if no params) and warns about large responses, adding behavioral context beyond the input schema. It doesn't cover all traits (e.g., rate limits) but is sufficient for a simple read operation.

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 compact with two short paragraphs. The first sentence states the purpose, followed by a highlighted IMPORTANT note and a default behavior explanation. Every sentence adds value with no 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 no output schema and no annotations, the description is adequate but incomplete. It covers the critical performance warning and default behavior, but doesn't describe the return format, data structure, or how to interpret metrics, leaving some gaps for an agent.

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% parameter description coverage, providing detailed explanations for each parameter. The description only lists the parameter names without adding new meaning, so it meets the baseline of 3 without exceeding schema contributions.

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 'Retrieves system metrics from the Cribl deployment' with a specific verb and resource. It distinguishes itself from sibling tools, which are about pipeline configuration, worker groups, etc., by being the only metrics retrieval tool.

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 explicitly advises using optional parameters to narrow queries and explains the default behavior (numBuckets=1) to prevent performance issues. This provides clear context for when to use the tool, though it doesn't compare with sibling tools explicitly.

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

cribl_listWorkerGroupsA

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

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

TDQS

A3.6/5.0
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.

cribl_restartWorkerGroupB

Restarts all workers within the default or specified worker group.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, and the description fails to disclose behavioral traits such as whether a restart disrupts ongoing operations, requires authentication, or is reversible. The description is minimal.

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 of 10 words, efficiently stating the tool's purpose with no redundancy.

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?

For a tool with no annotations or output schema, the description should provide more context. It fails to explain how to specify a worker group (conflicting with the schema), what the default group is, or what occurs after restarting. Incomplete.

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

Parameters4/5

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

With zero parameters in the input schema, the description does not need to add parameter details. The baseline for 0 parameters is 4, and the description does not contradict that (though it implies a parameter for worker group selection).

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 ('restarts') and the resource ('all workers within the default or specified worker group'), distinguishing it from sibling tools that focus on 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 Guidelines2/5

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

The description mentions a 'specified worker group' but the input schema has no parameters to select one, creating ambiguity. No guidance is given on when to use this tool versus alternatives like cribl_listWorkerGroups or other restart mechanisms.

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

cribl_setPipelineConfigB

Applies a new configuration payload to a specified pipeline in a worker group.

ParametersJSON Schema
NameRequiredDescriptionDefault
groupNameNoOptional: The name of the Worker Group/Fleet. If omitted, defaults to attempting to use Cribl Stream and if only one group exists for Stream, it will use that sole group.
pipelineIdYesThe ID of the pipeline to set configuration for.
configYesPipeline configuration payload to validate.

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It describes a write operation but lacks details on validation, error handling, immediacy of effect, or required permissions. The minimal description does not adequately compensate for missing annotations.

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, well-structured sentence that front-loads the action and resource. Every word contributes to clarity with no redundancy.

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 tool has three parameters, nested objects, and no output schema, the description is too minimal. It omits return values, error scenarios, and prerequisites, leaving an agent underinformed for correct invocation.

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?

All parameters have descriptions in the input schema (100% coverage), so the description does not need to repeat them. However, the description adds no additional meaning beyond the schema, such as constraints or usage nuances.

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 (applies) and the resource (new configuration payload to a specified pipeline in a worker group). This distinctly sets it apart from sibling tools like cribl_getPipelineConfig (retrieval) or cribl_deployPipeline (deployment).

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 for applying configuration but does not explicitly state when to use this tool instead of alternatives like cribl_commitPipeline or cribl_deployPipeline. No when-not-to-use guidance is provided.

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

cribl_versionControlA

Detects if version control (git) is enabled on the Cribl instance and whether a remote repository URL is configured.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'detects' enabling of version control and remote URL configuration, indicating a read-only, non-destructive operation. It adds context beyond the tool name but does not detail error cases or return format.

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 is clear, front-loaded, and contains no unnecessary words. Every word contributes to the tool's purpose.

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 simplicity of the tool (no parameters, no output schema), the description fully captures what the tool does: detecting two specific aspects of version control. It is complete for its intended use.

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

Parameters4/5

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

The input schema has zero parameters, so the description has no need to add parameter semantics. According to guidelines, baseline is 4 for zero parameters, and the description does not detract from this.

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 uses a specific verb 'detects' and clearly identifies the resource (version control status on Cribl instance). It distinguishes from sibling tools which focus on pipelines, sources, etc., none of which cover version control detection.

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 for checking git status, but does not explicitly state when to use this tool versus alternatives or provide exclusions. Given the sibling list, there are no direct alternatives, so the context is clear but guidelines are not explicit.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct action and resource: commit, deploy, get config, get list, sources, metrics, worker groups, restart, set config, version control. No overlapping purposes.

Naming Consistency5/5

All tools follow a consistent 'cribl_verbNoun' pattern with camelCase (e.g., cribl_commitPipeline, cribl_getPipelines). Even 'cribl_versionControl' fits the pattern as a noun-based verb.

Tool Count5/5

10 tools is well-scoped for a Cribl configuration and deployment server. It covers essential operations without being overwhelming or too sparse.

Completeness4/5

The tool set covers core pipeline lifecycle (get, set, commit, deploy), sources, worker groups, metrics, and version control. Missing are delete pipeline and potentially more granular worker group details, but the surface is solid for common use cases.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • splunk-mcp-server

    balajifunny
    F
    license
    B
    quality
    D
    maintenance
    A lightweight, extensible MCP server for Splunk Enterprise that enables secure, async, chat-based interaction with Splunk data via Claude Desktop or any MCP-compatible agent.
    7
    1

  • openhab

    deswong
    A
    license
    C
    quality
    A
    maintenance
    MCP server for OpenHAB v5+ that exposes the entire REST API as tools for AI models, enabling complete control over items, things, rules, persistence, and semantic model.
    25
    7
    MIT

  • dashy-mcp

    SavageCore
    A
    license
    A
    quality
    A
    maintenance
    MCP server exposing Dashy's REST API as tools, enabling an LLM to read and edit dashboard config, including sections, items, and top-level config keys.
    4
    MIT

Appeared in Searches

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