pipelines-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct resource/action pairing: jobs, pods, job configs, pod configs, and two log types. Pipeline worker logs and service logs are the only overlapping pair, but the names and descriptions cleanly separate them.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using get_ or list_ prefixes. The resource nouns are uniform and predictable, with job/config/pod/log/service modifiers making the hierarchy easy to infer.
Tool Count5/5
Eight tools is a well-scoped size for a pipeline inspection server. Each tool covers a distinct need without redundancy or surface bloat.
Completeness4/5
The set provides solid read-only coverage of jobs, pods, configs, and logs, which matches an observability-focused purose. Minor gaps exist, such as no direct way to list services or aggregate request-level status, but agents can work around these using the existing list and get tools.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description must carry the behavioral burden. It does state the operation is a read and implies cursor pagination behavior matches pipeline log. However, it omits authorization requirements, log scope, and possible side-effect context, though for a read tool the core mutation risk is addressed.
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 short sentences with no filler. The verb and resource are front-loaded, and the second sentence efficiently reuses the sibling's cursor rules instead of repeating them.
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?
With no annotations and 0% schema description coverage, the description should clarify full, cursor behavior, and the distinction from pipeline log. The output schema covers return shape, so that omission is acceptable, but parameter semantics and tool-selection context remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for parameter meaning. It only hints at cursor rules; request_id and full are left to their schema names and defaults. The cursor cross-reference is minor but nonzero.
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 opens with an explicit verb and resource: 'Read service logs for a request'. This is clear, but it does not contrast directly with sibling get_pipeline_log beyond the word 'service', so sibling differentiation is only implicit.
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 only usage guidance is 'Same cursor rules as pipeline log', which addresses pagination mechanics, not when to select this tool over get_pipeline_log or other siblings. There are no explicit when-to-use, when-not-to-use, or alternative conditions.
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?
With no annotations, the description carries the full behavioral burden. It adds one meaningful trait: an empty result when pods are gone, which prevents the agent from misreading an empty list as an error. It does not disclose read-only semantics, ordering, or failure modes, but the edge-case note is a valuable disclosure.
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 two short sentences with the core action front-loaded and the behavioral nuance second. Every word contributes information, and there is no filler or 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 three required parameters and zero schema descriptions, the tool is underspecified for correct invocation: parameter meanings and constraints are missing. The output schema covers return values, so that part is fine, but the input side is not adequately documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what request_id, step_index, and replica mean. The 'one job' phrase hints that request_id identifies the job, but the agent is left guessing about step_index and replica semantics. This is insufficient for a 3-required-parameter tool.
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 gives a clear verb-resource pair: list pods for one specific job. The 'Empty if they are already gone' line adds useful scoping, and the sibling get_pipeline_pod implies the single-vs-list distinction, though it is not stated explicitly.
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 establishes the context for use: listing pods for a single job. However, it never mentions alternatives like get_pipeline_pod or list_pipeline_jobs, nor does it state when this tool should not be used, so routing among siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only restates the retrieval action and the key fields, without mentioning what happens on not-found, whether the operation is read-only, or any limits/errors. This leaves an agent without expectations for side effects or failure modes.
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 entire description is a single 10-word sentence, with no redundant content or filler. It is appropriately concise for a simple lookup tool.
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 simple getter with an output schema, the description conveys the core operation, but with no annotations and 0% parameter coverage, it leaves gaps around usage context and parameter semantics. The sibling list is large, and without a differentiating note an agent could still be uncertain about selecting this over list_pipeline_jobs or get_pipeline_pod.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely lists the three parameter names in the 'by' phrase, adding only that they together identify the job. It does not explain the meaning of step_index or replica, their formats, or allowed values, so the agent must infer from names.
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 opens with a specific verb ('Get') and a precise resource ('one job'), and it names the three identifiers that select the job. This distinguishes it from siblings like list_pipeline_jobs (plural) and get_pipeline_job_config/log, which target different resources or collections.
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 the tool is for fetching a single job when all three identifiers are known, but it does not explicitly contrast with list_pipeline_jobs or other siblings, nor state conditions when one should prefer this tool. No exclusion guidance is given.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds a useful trait ('Secrets are redacted') and the verb 'Get' implies read-only behavior, but it does not cover error conditions, existence guarantees, or any side effects.
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 action and resource, names the three identifiers, and adds the important redaction caveat. Every word earns its place with no redundancy.
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 simple getter with an output schema, the description is nearly complete: it specifies the resource, selection keys, return format (YAML), and the redaction behavior. The only notable gap is explicit alternative-tool guidance, which is already handled in the usage_guidelines dimension.
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 must compensate. It names all three parameters and indicates they identify a single job, but it does not elaborate on their formats, semantics, or relationships beyond what the parameter names imply.
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 states a specific action ('Get'), a precise resource ('full YAML config for one job'), and the identifying parameters. This clearly differentiates it from siblings like get_pipeline_job and get_pipeline_pod_config.
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 when to use the tool: when the full YAML config for a specific job replica is needed. However, it does not explicitly mention when not to use it or contrast it with sibling tools such as get_pipeline_job or get_pipeline_pod_config.
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?
There are no annotations, so the description carries the behavioral burden. 'Get' conveys a read-only single-resource lookup, but the description does not address missing-pod behavior, response shape, or any side effects. This is adequate for a simple getter but leaves edge cases implicit.
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 six words and contains no filler. The action and identifier are front-loaded, and every word contributes to meaning.
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?
The tool is simple, with one required parameter and an existing output schema, so the description does not need to explain return values. It is slightly terse regarding alternatives and edge cases, but nothing essential for selecting and invoking the tool is missing.
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 coverage is 0%, so the description must add meaning. 'by pod_name' clarifies that pod_name is the selection key, which is useful. However, it does not specify format, matching rules, or how the name is used beyond the obvious.
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 states a specific action (Get), a specific resource (one pod), and the lookup key (pod_name). This clearly distinguishes it from siblings like list_pipeline_pods and get_pipeline_pod_config.
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 phrase 'Get one pod by pod_name' implies the tool is for retrieving a single known pod, but it does not explicitly contrast with list_pipeline_pods or get_pipeline_pod_config. Usage context is inferable rather than stated.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It adds meaningful context: sort order ('newest first'), filter values, limit bounds, and the job-name naming convention. However, it omits details on empty-result behavior, exact versus partial matching for request_id, and pagination beyond the limit, leaving some behavior unspecified.
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 compact sentences with no filler. The first sentence front-loads the core verb, object, and ordering; the second packs filters, defaults, and limits efficiently. The minor casing inconsistency in the status list does not detract from the concise structure.
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 simple read-only list tool with optional filters and an output schema, the description covers the essential invocation details: filters, defaults, limits, ordering, and naming. It lacks explicit differentiation from sibling get_* tools and nuanced pagination behavior, but these are minor gaps for an agent to invoke it correctly.
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?
Schema description coverage is 0%, so the description must compensate. It does so for all three parameters: limit's default/max, status's allowed values, and request_id's relationship to the job-name format. It does not fully specify request_id matching semantics, but the provided context adds real meaning beyond the bare schema.
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 states a specific verb ('List'), a clear resource ('pipeline jobs'), and a distinguishing ordering trait ('newest first'). It differentiates from singular sibling tools like get_pipeline_job and get_pipeline_job_config by clearly indicating this is the bulk-listing operation.
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 guidance is provided about when to use this tool versus alternatives such as get_pipeline_job or get_pipeline_log. The description only lists optional filters; it does not explain scenarios that favor this tool, nor does it mention any exclusions or conditions.
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?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that secrets are redacted, which is a meaningful behavioral trait beyond the basic 'get' semantics. The read-only nature is implied by 'Get', and the redaction note adds valuable safety 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?
Two short sentences with no filler. The main action is front-loaded, and the redaction note is a distinct, important behavioral caveat. Every word earns its place.
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 single-parameter read tool with an output schema, the description covers the essential facts: what is returned, for which pod, and the redaction behavior. It could add a hint that pod_name comes from list_pipeline_pods, but the current description is sufficient for correct invocation in most contexts.
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 must compensate. 'by pod_name' clarifies that pod_name is the selector for the config lookup, but it adds little detail about the expected format, provenance, or behavior when the pod does not exist. The single parameter is simple, but the description only minimally supplements the bare schema.
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 names a specific verb ('Get'), resource ('full YAML config'), and selection scope ('for one pod by pod_name'). The word 'config' clearly differentiates it from siblings like get_pipeline_pod, and the scope prevents confusion with job-level config tools.
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?
It provides clear context: use this when you need the full YAML configuration for a single pod, identified by pod_name. It does not explicitly name alternatives or exclusion conditions, but the resource and scope are specific enough to guide selection among siblings.
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?
With no annotations, the description carries the full behavioral disclosure burden. It reveals several non-obvious traits: empty until pod running, default 100-line limit, cursor-based incremental retrieval, and that full=true still imposes a size cap. Exact caps and authentication details are absent, but the disclosed behavior is substantially helpful.
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?
Four short sentences, front-loaded with purpose and followed by dense, relevant behavioral details. Every sentence adds value and there is no filler.
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?
An output schema exists, so return-format details are not required from the description. The description covers default behavior, pagination, empty-before-running semantics, and the full flag cap, which is sufficient for correct invocation. It could name the exact cap or route to sibling tools, but nothing critical is missing.
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?
Schema description coverage is 0%, so the description must compensate. It explains cursor and full behavior in functional terms, which the bare schema does not. The request_id parameter is only implied by 'for a request,' but that is reasonable given the required schema field is self-explanatory.
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?
Opens with a specific verb and resource: 'Read pipeline worker logs for a request.' This clearly differentiates the tool from siblings like get_pipeline_service_log or get_pipeline_pod by scoping it to worker logs tied to a request.
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?
Provides clear practical context: logs are empty until the worker pod is running, the default is last 100 lines, and passing a cursor retrieves only new lines. It does not explicitly name sibling alternatives or state when not to use this tool, but the usage pattern is clearly implied.
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:

[![pipelines-mcp MCP server](https://glama.ai/mcp/servers/maxim-at-reveliolabs/pipelines-mcp/badges/card.svg)](https://glama.ai/mcp/servers/maxim-at-reveliolabs/pipelines-mcp)

Score Badge

Copy to your README.md:

[![pipelines-mcp MCP server](https://glama.ai/mcp/servers/maxim-at-reveliolabs/pipelines-mcp/badges/score.svg)](https://glama.ai/mcp/servers/maxim-at-reveliolabs/pipelines-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/maxim-at-reveliolabs/pipelines-mcp'

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