SNC Cribl MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness2/5
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.
Average 3.7/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT No Attribution.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
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, 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.
Parameters3/5
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.
Purpose4/5
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.
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. 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
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. 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
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 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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
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. 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![snc-cribl-mcp MCP server](https://glama.ai/mcp/servers/atree1023/snc-cribl-mcp/badges/card.svg)](https://glama.ai/mcp/servers/atree1023/snc-cribl-mcp)

Score Badge

Copy to your README.md:

[![snc-cribl-mcp MCP server](https://glama.ai/mcp/servers/atree1023/snc-cribl-mcp/badges/score.svg)](https://glama.ai/mcp/servers/atree1023/snc-cribl-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

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