The SNC Cribl MCP server provides tools for querying, managing, and synchronizing Cribl Stream and Edge deployments through AI assistants like Claude via the Model Context Protocol.
Discovery & Retrieval:
list_groups – List all Stream worker groups and Edge fleets, including metadata like IDs, names, and configurations
list_sources – Get all input sources across groups, including collector types (S3, REST, database, etc.)
list_destinations – Retrieve all configured destinations across Stream and Edge groups
list_pipelines – Get all pipelines across groups; optionally filter by pipeline_id for full function details
list_routes – Retrieve all routes, including filters, destinations, and referenced pipelines
list_breakers – Get all event breaker rulesets across groups
list_lookups – Retrieve all lookups, including file info and configurations
Cross-Leader Synchronization:
Copy configurations for groups, sources, destinations, pipelines, or routes from one Cribl leader to another
Validate whether configurations are in sync between two Cribl leaders, detailing any differences
Additional Capabilities:
Authentication Management: Automatic token retrieval and refresh for both Cribl.Cloud (OAuth) and on-prem deployments
Typed Data Models: 41 pipeline function models and 9 collector source models via Pydantic for reliable, structured JSON output
MCP Resources: Read-oriented data also exposed as MCP resources (e.g., cribl://groups, cribl://sources)
Multi-Server Support: All tools accept an optional server parameter to target a specific Cribl leader defined in config.toml; defaults to the configured default if omitted
Error Handling: Graceful validation errors with user-friendly, actionable guidance
Provides tools for querying Cribl Stream and Edge deployments, including retrieval of worker groups, fleets, sources (including Splunk collectors), destinations, pipelines, routes, event breakers, and lookups with full configuration details.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SNC Cribl MCP list all worker groups and their configured sources"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides tools for querying Cribl deployments.
Related MCP server: Flight Control MCP Server
This MCP server connects to Cribl Stream and Edge deployments to retrieve and compare metadata about leaders, worker groups, fleets, sources, destinations, pipelines, routes, variables, and Packs. It also supports targeted cross-leader copy and validation workflows for local users, group/fleet contents, and global system settings so AI assistants can help keep multiple leaders aligned without passing entire configs through context.
The server handles authentication with bearer tokens, manages token refresh automatically, and provides a clean JSON interface for exploring your Cribl infrastructure.
Comprehensive Discovery: List all worker groups (Stream) and fleets (Edge) in your deployment.
Configuration Retrieval:
Retrieve configured sources across all products and groups.
Retrieve configured destinations across all products and groups.
Retrieve configured pipelines across all products and groups, with full function configuration details.
Retrieve configured routes across all products and groups.
Retrieve configured event breakers across all products and groups.
Retrieve configured lookups across all products and groups.
Retrieve configured variables across all products and groups.
Pack Management:
List and inspect installed Packs.
Install Packs from IDs, URLs, Git repositories, or previously uploaded Pack files.
Upload, upgrade, and uninstall Packs through the cribl-control-plane SDK.
Cross-Leader Sync Workflows:
Copy supported resources between configured leaders.
Validate whether supported resources are in sync between configured leaders.
Resolve different source and target group selectors during copy and validation workflows.
Create or replicate local users, using explicit or environment-sourced passwords because Cribl does not return passwords from the API.
Replicate and validate complete Stream worker groups or Edge fleets, including group/fleet settings, variables, event breakers, lookups, destinations, pipelines, sources, and routes.
Replicate and validate global system settings from the Global Settings page.
Typed Pipeline Models: 41 Pydantic models for pipeline function configurations (eval, mask, sampling, regex_extract, etc.) with full type safety.
Typed Collector Models: 9 Pydantic models for collector source configurations (S3, REST, database, Splunk, Azure Blob, GCS, filesystem, script, health check) with full type safety.
Graceful Error Handling: SDK validation errors return structured, user-friendly responses with actionable guidance instead of crashing.
Robust Authentication: Automatic token management and refresh for customer-managed deployments.
FastMCP Integration: Built with FastMCP 3.x for easy integration with Claude and other AI assistants.
Quality Assurance: Comprehensive unit test coverage with full typing support.
Prerequisites:
Python 3.14 or higher
uv package manager (required)
Access to a Cribl deployment with valid credentials
The server is designed to run from a source checkout. It reads config.toml and optional .env values from the checkout root, so keep the checkout in place and point your MCP client at that directory.
Install from source:
git clone https://github.com/atree1023/snc-cribl-mcp.git
cd snc-cribl-mcp
# Optional once the release tag exists:
# git checkout v0.3.0
uv sync
cp config.example.toml config.tomlEdit config.toml with your Cribl leaders, then verify the server starts:
uv run snc-cribl-mcpFor MCP clients, use the checkout path directly with uv run --directory; see Example Integration with Claude.
Create a config.toml file in the project root with your Cribl server definitions:
[defaults]
verify_ssl = true
timeout_ms = 10_000
oauth_token_url = "https://login.cribl.cloud/oauth/token"
oauth_audience = "https://api.cribl.cloud"
# Optional for on-prem; defaults to snc-cribl-mcp:<server-name>.
# keychain_name = "shared-cribl-login"
[golden.oak]
url = "http://localhost:19000"
# Optional for on-prem; defaults to your local macOS user.
# username = "admin"
# Optional for on-prem; overrides the default Keychain service name.
# keychain_name = "golden-oak-login"
[cribl.cloud]
url = "https://<workspace>-<org>.cribl.cloud"
client_id = "your-client-id"
client_secret = "${CRIBL_CLOUD_SECRET}"For on-prem servers, omit password to use the local credential chain:
Use the configured username, or default to the locally logged-in macOS user.
Read the password from the macOS Keychain via Python keyring, using service
keychain_name when configured in [defaults] or the server section. If omitted, the service defaults to
snc-cribl-mcp:<server-name> and the resolved username. For [golden.oak], the default service is
snc-cribl-mcp:golden.oak. A server-level keychain_name overrides [defaults].
Fall back to per-server environment variables loaded from .env or your shell. For [golden.oak],
the resolver checks SNC_CRIBL_MCP_GOLDEN_OAK_PASSWORD, CRIBL_GOLDEN_OAK_PASSWORD,
GOLDEN_OAK_PASSWORD, then GOLDEN_OAK_PASS.
To store a local Keychain password:
uv run keyring set snc-cribl-mcp:golden.oak "$(whoami)"If you use ${VAR} placeholders, set the values in a .env file (or your shell environment). Explicit
placeholder values still take precedence over keychain lookup and must exist when referenced.
When a tool call omits a server name, the first non-[defaults] section in config.toml is used.
Logging is still controlled via the LOG_LEVEL environment variable (default: INFO).
Configuration Options:
Section | Key | Description | Required |
|
| Verify SSL certificates | No |
|
| API request timeout in milliseconds | No |
|
| OAuth token URL for Cribl.Cloud | No |
|
| OAuth audience for Cribl.Cloud | No |
|
| Shared macOS Keychain service name for on-prem passwords | No |
|
| Base URL of your Cribl deployment (auto-appends | Yes |
|
| On-prem username; defaults to local macOS user | No* |
|
| On-prem password; defaults to Keychain/env lookup | No* |
|
| Per-server macOS Keychain service name override | No |
|
| Cribl.Cloud client ID | Yes* |
|
| Cribl.Cloud client secret | Yes* |
*Cribl.Cloud URLs (ending in .cribl.cloud) require client_id/client_secret. On-prem URLs ultimately require a
resolved username/password pair, but the password can come from macOS Keychain or a per-server environment fallback.
Start the server directly:
uv run snc-cribl-mcpOr using the Python module:
uv run python -m snc_cribl_mcp.serverThe server exposes twenty-four MCP tools, and also mirrors the read-oriented data as MCP resources (e.g., cribl://groups, cribl://sources, cribl://destinations, cribl://pipelines, cribl://routes, cribl://breakers, cribl://lookups, cribl://variables, cribl://packs):
get_leader_overviewReturns a compact operational overview for a configured Cribl leader.
Returns: JSON containing leader health, Cribl version, Stream/Edge aggregate node counts, active worker groups and Edge fleets with node counts, and source/destination runtime health summaries for groups or fleets with nodes.
list_groupsLists all Stream worker groups and Edge fleets from your Cribl deployment.
Returns: JSON containing groups organized by product (Stream and Edge), with metadata including group IDs, names, descriptions, and configuration.
list_sourcesLists all configured sources across all groups and products, including both regular sources (from /system/inputs) and collector sources (from /lib/jobs).
Returns: JSON containing sources organized by product and group, including source IDs, types, and configurations. Collector sources (S3, REST, database, etc.) are merged with regular sources per group.
list_destinationsLists all configured destinations across all groups and products.
Returns: JSON containing destinations organized by product and group, including destination IDs, types, and configurations.
list_pipelinesLists all configured pipelines across all groups and products.
Returns: JSON containing pipelines organized by product and group, including pipeline IDs, names, and configurations.
list_routesLists all configured routes across all groups and products.
Returns: JSON containing routes organized by product and group, including route IDs, names, filters, destinations, and referenced pipelines.
list_breakersLists all configured event breakers across all groups and products.
Returns: JSON containing event breakers organized by product and group, including ruleset IDs, rules, and configurations.
list_lookupsLists all configured lookups across all groups and products.
Returns: JSON containing lookups organized by product and group, including lookup IDs, file info, and configurations.
list_variablesLists all configured variables across all groups and products.
Returns: JSON containing variables organized by product and group, including variable IDs and configurations.
list_packsLists installed Packs. Optionally pass with_="inputs", with_="outputs", or with_="inputs,outputs" to include Pack input/output counts. For distributed environments, pass product="stream" or product="edge" and group="<group id, name, or description>" to scope the request to /m/{group}.
Returns: JSON containing Pack IDs, sources, versions, metadata, and any requested counts.
get_packGets one installed Pack by Pack ID. By default, this returns the Pack metadata plus a bounded summary of the Pack's sources, destinations, pipelines, routes, knowledge categories, and settings categories. Pass kind to drill into one concrete section or category, object_id to fetch one object, detail="full" to include raw payloads from that selected section/category, and cursor/limit to page that selected section/category.
Supported kind values: sources, destinations, pipelines, routes, knowledge, knowledge.lookups, knowledge.breakers, knowledge.parsers, knowledge.variables, knowledge.samples, knowledge.regexes, knowledge.grok, knowledge.schemas, knowledge.functions, knowledge.hmac_functions, knowledge.appscope_configs, knowledge.database_connections, settings, settings.system, settings.cribl, settings.conf, settings.auth, settings.git.
Returns: JSON containing Pack metadata and either section summaries or the requested Pack object details.
Distributed scope: Supports the same optional product and group arguments as list_packs.
install_packInstalls a Pack using the SDK Pack request body. The request can create an empty Pack by ID, install from a URL, install from a git+ repository URL, or install from an uploaded Pack source returned by upload_pack.
Returns: JSON containing installed Pack metadata and any warnings returned by Cribl.
Distributed scope: Supports the same optional product and group arguments as list_packs.
upload_packUploads a local .crbl Pack file.
Returns: JSON containing the uploaded source value to pass to install_pack.
Distributed scope: Supports the same optional product and group arguments as list_packs.
update_packUpgrades an installed Pack from a source URL or uploaded source ID.
Returns: JSON containing the upgraded Pack metadata.
Distributed scope: Supports the same optional product and group arguments as list_packs.
delete_packUninstalls an installed Pack by Pack ID.
Returns: JSON containing uninstall metadata returned by Cribl.
Distributed scope: Supports the same optional product and group arguments as list_packs.
get_config_objectsQueries supported config objects through one bounded read tool: groups, sources, destinations, pipelines, routes, breakers, lookups, and variables.
Returns: Compact summaries by default, including product, group, ID, type, enabled state, optional dependency references, truncation state, and a cursor for follow-up calls. Use detail="full" with filters such as selector, product, and group_id to retrieve selected payloads without flooding the MCP response.
validate_config_objectsSemantically compares groups, sources, destinations, pipelines, routes, breakers, lookups, or variables between two configured leaders.
Returns: Functional validation results that classify differences as blocking functional drift, non-blocking environment identity differences, or volatile metadata differences. Hostnames, endpoint server lists, generated IDs, credential references, and timestamps are reported but do not count as functional drift.
copy_resource_configCopies groups, sources, destinations, pipelines, routes, breakers, lookups, or variables from one configured leader to another.
Returns: JSON describing the copy actions taken, including created, updated, appended, skipped, and unsupported items. For group-scoped resources, the response includes both the requested source and target group selectors and the resolved group IDs used on each leader.
validate_resource_syncCompares groups, sources, destinations, pipelines, routes, breakers, lookups, or variables between two configured leaders.
Returns: JSON describing whether the selected item or scope is in sync, along with per-item status and differing paths. For group-scoped resources, the response includes both the requested source and target group selectors and the resolved group IDs used on each leader.
sync_userCreates or replicates a local Cribl user on a target leader. When source_server is provided, profile fields and roles are copied from the source leader.
Password handling: Cribl does not return user passwords from the API, so pass password, pass password_env, or provide one of the automatic .env/environment fallbacks such as SNC_CRIBL_MCP_<TARGET_SERVER>_<USERNAME>_PASSWORD, CRIBL_USER_<USERNAME>_PASSWORD, or <USERNAME>_PASSWORD.
Transport note: For on-prem leaders configured with http:// URLs, password create/update requests are sent over cleartext HTTP. Use HTTPS for production user sync.
Returns: JSON describing whether the target user was created, updated, skipped, or validated. Password values are never returned.
replicate_group_configReplicates a complete Stream worker group or Edge fleet between configured leaders.
Includes: Group/fleet settings plus variables, event breakers, lookups, destinations, pipelines, sources, and routes by default.
Returns: JSON describing each replicated section and optional post-copy validation.
validate_group_configValidates a complete Stream worker group or Edge fleet between configured leaders.
Returns: JSON with group/fleet setting status and per-section sync status for variables, event breakers, lookups, destinations, pipelines, sources, and routes.
replicate_system_settingsReplicates global Cribl system settings from one configured leader to another.
Returns: JSON describing whether settings were updated, skipped, and optionally validated.
validate_system_settingsValidates global Cribl system settings between two configured leaders.
Returns: JSON with an in-sync flag and differing setting paths. Use include_payloads=true when the raw source and target setting payloads are needed.
Add this server to your Claude desktop app configuration. Use an absolute path to the source checkout that contains config.toml:
{
"mcpServers": {
"snc-cribl-mcp": {
"command": "uv",
"args": [
"run",
"--directory",
"/absolute/path/to/snc-cribl-mcp",
"snc-cribl-mcp"
],
"env": {
"LOG_LEVEL": "INFO"
}
}
}
}snc_cribl_mcp/
├── src/snc_cribl_mcp/ # Main package (src-layout)
│ ├── client/ # Cribl client and token management
│ │ ├── cribl_client.py # Control plane client factory
│ │ └── token_manager.py # Bearer token lifecycle management
│ ├── models/ # Pydantic models for Cribl data structures
│ │ ├── collectors.py # Typed models for 9 collector source types
│ │ └── pipeline_functions.py # Typed models for 41 pipeline function types
│ ├── operations/ # Core business logic
│ │ ├── common.py # Shared utilities and generic collectors
│ │ ├── groups.py # Group collection and serialization
│ │ ├── sources.py # Source collection helpers
│ │ ├── destinations.py # Destination collection helpers
│ │ ├── pipelines.py # Pipeline collection helpers
│ │ ├── routes.py # Route collection helpers
│ │ ├── breakers.py # Event breaker collection helpers
│ │ ├── lookups.py # Lookup collection helpers
│ │ ├── variables.py # Variable collection helpers
│ │ ├── users.py # Local user create/replicate helpers
│ │ ├── group_sync.py # Whole group/fleet copy and validation helpers
│ │ ├── system_settings.py # Global system setting sync helpers
│ │ ├── packs.py # Top-level Pack management helpers
│ │ ├── config_objects.py # Consolidated config object response shaping
│ │ ├── resource_actions.py # Context-free CRUD helpers over the SDK
│ │ ├── semantic_diff.py # Functional vs environment identity comparison
│ │ ├── sync.py # Cross-leader copy and validation helpers
│ │ └── validation_errors.py # SDK validation error handling
│ ├── tools/ # MCP tool registrations
│ │ ├── common.py # Shared tool registration utilities
│ │ ├── copy_resource_config.py
│ │ ├── list_groups.py
│ │ ├── list_sources.py
│ │ ├── list_destinations.py
│ │ ├── list_pipelines.py
│ │ ├── list_routes.py
│ │ ├── list_breakers.py
│ │ ├── list_lookups.py
│ │ ├── list_variables.py
│ │ ├── users.py
│ │ ├── group_sync.py
│ │ ├── system_settings.py
│ │ ├── packs.py
│ │ ├── get_config_objects.py
│ │ ├── validate_config_objects.py
│ │ ├── sync_common.py
│ │ └── validate_resource_sync.py
│ ├── config.py # Configuration management
│ ├── prompts.py # MCP prompt definitions
│ ├── resources.py # MCP resource definitions
│ └── server.py # FastMCP app entry point
├── tests/
│ └── unit/ # Unit tests with pytest
├── docs/ # Additional documentation
├── pyproject.toml # Project dependencies and tool config
└── .env # Local configuration (not committed)# Run all tests
uv run pytest
# Run with coverage
uv run pytest --cov=src/snc_cribl_mcp
# Run specific test file
uv run pytest tests/unit/test_server.py# Type checking
uv run pyright
# Linting and formatting
uv run ruff check
uv run ruff formatCreate the implementation logic in src/snc_cribl_mcp/operations/.
Create a new tool file in src/snc_cribl_mcp/tools/ following the existing pattern.
Register the tool in src/snc_cribl_mcp/server.py in the _register_capabilities() function.
Add corresponding tests in tests/unit/.
The server retrieves bearer tokens automatically based on the configured server type:
Cribl.Cloud: Uses OAuth client credentials (client_id/client_secret) and refreshes tokens automatically.
On-prem: Uses a resolved username/password pair to fetch bearer tokens, defaulting to the local macOS user and
macOS Keychain before falling back to per-server environment variables. It refreshes using the JWT exp claim when
available.
Tokens expire based on your Cribl settings (default: 1 hour on-prem, 24 hours on Cribl.Cloud). For production use, configure TLS and use HTTPS.
Contributions are welcome! Here's how to get started:
Fork the repository.
Create a feature branch (git checkout -b feature/amazing-feature).
Make your changes and add tests.
Run the test suite (uv run pytest).
Run type checking and linting (uv run pyright && uv run ruff check).
Commit your changes with a descriptive message.
Push to your branch (git push origin feature/amazing-feature).
Open a Pull Request.
Please ensure all tests pass and maintain code coverage before submitting a PR.
This project is licensed under the MIT No Attribution License (MIT-0). See the LICENSE file for details.
For issues, questions, or feature requests, please open an issue in the repository.
Return JSON describing all configured Stream and Edge event breakers in all groups in the Cribl deployment.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, indicating a safe read operation, which the description doesn't contradict. The description adds context by specifying the scope ('all configured Stream and Edge event breakers in all groups') and output format ('Return JSON'), but doesn't detail behavioral aspects like rate limits, authentication needs, or pagination. With annotations covering safety, this provides moderate additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and scope without unnecessary words. It's front-loaded with the key action and resource, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, read-only operation, output schema provided), the description is reasonably complete. It specifies the resource type and scope, and with annotations and output schema handling safety and return values, it covers essential aspects, though it lacks usage guidelines for sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (server) with 0% description coverage, and the tool description provides no information about parameters. Since there's only one parameter and an output schema exists, the baseline is 3, as the description doesn't add semantic details but the minimal parameter count reduces the need for extensive explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return JSON describing') and resource ('all configured Stream and Edge event breakers in all groups in the Cribl deployment'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from sibling tools like list_destinations or list_pipelines, which likely list other resource types in the same deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, context for usage, or how it differs from sibling tools that list other resources in the Cribl deployment, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return JSON describing all configured Stream and Edge destinations in all groups in the Cribl deployment.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description aligns by describing a read operation ('Return JSON describing'). It adds value by specifying the scope ('all configured Stream and Edge destinations in all groups'), which isn't covered by annotations. No contradictions exist, and it provides useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations (readOnlyHint) and an output schema, the description is reasonably complete for a read operation. It specifies the resource scope clearly, though it lacks parameter details. For a simple list tool with structured support, this is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden for parameter meaning. However, it doesn't mention the 'server' parameter at all, leaving it undocumented. With one parameter and no schema descriptions, the baseline is 3 as the description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return JSON describing') and resource ('all configured Stream and Edge destinations in all groups in the Cribl deployment'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like list_groups or list_sources, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 list_groups or list_sources, nor does it mention any prerequisites or exclusions. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return JSON describing all Stream worker groups and Edge fleets in the configured Cribl deployment.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about what gets returned ('JSON describing all...') and specifies the scope ('in the configured Cribl deployment'), which isn't covered by annotations. However, it doesn't mention pagination, rate limits, authentication requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality. Every word serves a purpose: 'Return JSON' specifies output format, 'describing all' indicates comprehensiveness, 'Stream worker groups and Edge fleets' identifies resources, and 'in the configured Cribl deployment' provides scope. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a read-only list operation with annotations covering safety, an output schema exists (so return values are documented elsewhere), and only one optional parameter, the description is reasonably complete. It clearly states what resources are listed and the output format. The main gap is lack of guidance about when to use this versus sibling list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (the 'server' parameter has no description in the schema), the description carries the full burden but doesn't mention the parameter at all. However, since there's only one optional parameter with a null default, the tool likely works without it. The description's specification of 'in the configured Cribl deployment' somewhat compensates by implying server configuration is handled elsewhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return JSON describing') and the target resources ('all Stream worker groups and Edge fleets'), providing specific verb+resource information. However, it doesn't explicitly differentiate this tool from its sibling list tools (like list_destinations, list_sources), which all appear to list different resource types in the same system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention the sibling tools or explain why someone would list worker groups/fleets instead of other resources like destinations or pipelines. There's no context about prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return JSON describing all configured Stream and Edge lookups in all groups in the Cribl deployment.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the scope ('all configured Stream and Edge lookups in all groups') and that it returns JSON, but doesn't detail pagination, rate limits, or auth needs beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action and resource. It's concise with no wasted words, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations (readOnlyHint), an output schema (implied by 'Return JSON'), and low complexity (one optional parameter), the description is mostly complete. It specifies the resource scope clearly, though it could benefit from more usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter 'server', the description adds no parameter information. However, since there's only one optional parameter (default null), the baseline is high. The description implies no parameters are needed for the core functionality, which is adequate given the low parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'JSON describing all configured Stream and Edge lookups in all groups in the Cribl deployment.' It distinguishes from siblings like list_breakers, list_destinations, etc., by specifying it's about lookups rather than other components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, exclusions, or compare to other list_* tools, leaving the agent to infer usage based on the resource type alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return JSON describing configured Stream and Edge pipelines in all groups in the Cribl deployment. Optionally filter by pipeline_id to fetch a specific pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline_id | No | ||
| server | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating safe read access. The description adds value by specifying the scope ('all groups') and optional filtering, but doesn't disclose additional behavioral traits like rate limits, auth needs, or pagination. With annotations covering safety, this is adequate but not rich in extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and efficiently adds optional filtering in a second sentence. Every sentence contributes directly to understanding the tool, with no wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations (readOnlyHint), an output schema (implying return values are documented), and low complexity, the description is reasonably complete. It covers the action, resource, and filtering option, though it could benefit from more parameter details or sibling differentiation to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema doesn't explain parameters. The description mentions pipeline_id for filtering, adding some meaning, but doesn't cover the server parameter or provide details like format or constraints. It partially compensates but leaves gaps, aligning with the baseline for moderate coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return JSON describing') and resource ('configured Stream and Edge pipelines in all groups'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like list_groups or list_sources, which list other resource types, so it lacks specific sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning optional filtering by pipeline_id, suggesting when to use this tool for specific vs. all pipelines. However, it doesn't provide explicit guidance on when to choose this over alternatives or any exclusions, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return JSON describing all configured Stream and Edge routes in all groups in the Cribl deployment.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the output format ('Return JSON') and the scope ('all groups'), which are not covered by annotations. However, it lacks details on rate limits, authentication needs, or pagination behavior, though annotations reduce the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's action, resource, and scope without any redundant information. It is front-loaded and appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter), annotations covering safety, and the presence of an output schema, the description is complete enough. It clearly states what the tool does and what it returns, aligning well with the structured data provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description does not mention parameters. However, since there is only one optional parameter (server), the tool's core functionality is clear without parameter details. The description compensates for the low schema coverage by fully explaining the tool's purpose and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Return JSON describing') and resource ('all configured Stream and Edge routes in all groups in the Cribl deployment'), distinguishing it from sibling tools like list_breakers, list_destinations, etc. It precisely identifies what is being listed (routes) and their scope (all groups).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving route configurations but does not explicitly state when to use this tool versus alternatives like list_groups or list_pipelines. No exclusions or specific contexts are provided, leaving usage guidance at an implied level without clear differentiation from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return JSON describing all configured Stream and Edge sources in all groups in the Cribl deployment. Includes both regular input sources and collector sources (S3, REST, database, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| server | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the scope (all groups, all sources) and including both regular and collector sources, which goes beyond the annotations. However, it does not mention behavioral aspects like rate limits, authentication needs, or pagination, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and scope without unnecessary details. It is front-loaded with the main action and includes all essential information concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of annotations and an output schema, the description is mostly complete. It clearly states what the tool returns and its scope. However, it lacks details on the 'server' parameter, which slightly reduces completeness for a tool with parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not mention the 'server' parameter at all. With one parameter undocumented in both schema and description, the description fails to compensate for the coverage gap. Baseline is 3 due to the schema's existence, but no additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'JSON describing all configured Stream and Edge sources in all groups in the Cribl deployment', specifying both scope (all groups) and types (regular input sources and collector sources like S3, REST, database). It distinguishes from siblings by focusing on sources rather than breakers, destinations, groups, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving source configurations but does not explicitly state when to use this tool versus alternatives like list_destinations or list_pipelines. It provides context about what's included but lacks explicit guidance on when/when-not to use it or mention of specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose targeting different Cribl resources: breakers, destinations, groups, lookups, pipelines, routes, and sources. The naming and descriptions make it unambiguous which resource each tool retrieves, with no overlap in functionality.
All tools follow a consistent 'list_<resource>' naming pattern in snake_case, making them predictable and easy to understand. This uniformity aids in agent selection and reduces confusion.
With 7 tools, the count is reasonable for a Cribl management server, covering key resources like sources, pipelines, and routes. However, it lacks CRUD operations beyond listing, which slightly limits its scope but keeps it focused.
The toolset is severely incomplete as it only provides read-only list operations for resources. There are no create, update, or delete tools, which are essential for managing a Cribl deployment, leading to significant gaps in agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query Honeycomb observability data: traces, events, metrics, SLOs, triggers, and boards.
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Browse, query, and administer your managed WaveHouse + ClickHouse projects (schema, pipes, policy).
Query your OpsLevel internal developer portal: catalog, maturity data, and tech docs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/atree1023/snc-cribl-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
