Cloud DevOps MCP Server

Overview Schema Source Related Servers Discussions Admin

Review CI/CD Pipeline

review_cicd_pipeline

Read-onlyIdempotent

Assess CI/CD pipeline production readiness from structured facts, distinguishing missing evidence from failed controls. Use for platform-agnostic delivery reviews; no builds or deployments triggered.

Instructions

Evaluate generic CI/CD production-readiness controls from structured pipeline facts, separating missing evidence from failed controls. Use this for platform-agnostic delivery process review; for raw GitHub Actions YAML, use review_github_actions_workflow. It is analysis-only and does not trigger builds, deployments, approvals, or pipeline changes.

Input Schema

TableJSON Schema

Name	Required	Description
`hasRollback`	No	Whether the pipeline has a defined rollback or recovery mechanism.
`environments`	Yes	Deployment environments handled by the pipeline, for example dev, staging and production.
`pipelineName`	Yes	Human-readable name of the CI/CD pipeline being reviewed.
`hasSecurityScan`	No	Whether the pipeline performs automated security scanning before deployment.
`hasAutomatedTests`	No	Whether automated tests run as a release gate.
`deploymentStrategy`	Yes	Primary deployment strategy used to release changes.
`hasArtifactVersioning`	No	Whether build artifacts are immutable and versioned for traceability.
`hasManualApprovalForProduction`	No	Whether production deployment requires an explicit human approval gate.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`findings`	Yes
`strengths`	Yes
`pipelineName`	Yes
`uncertainties`	Yes
`readinessLevel`	Yes
`readinessScore`	Yes
`recommendedGates`	Yes
`deploymentStrategy`	Yes
`assessmentConfidence`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.14.0Oct 3, 2026

addedInput schema / properties / deploymentStrategy / description

Added value: +"Primary deployment strategy used to release changes."

addedInput schema / properties / environments / description

Added value: +"Deployment environments handled by the pipeline, for example dev, staging and production."

addedInput schema / properties / hasArtifactVersioning / description

Added value: +"Whether build artifacts are immutable and versioned for traceability."

addedInput schema / properties / hasAutomatedTests / description

Added value: +"Whether automated tests run as a release gate."

addedInput schema / properties / hasManualApprovalForProduction / description

Added value: +"Whether production deployment requires an explicit human approval gate."

addedInput schema / properties / hasRollback / description

Added value: +"Whether the pipeline has a defined rollback or recovery mechanism."

addedInput schema / properties / hasSecurityScan / description

Added value: +"Whether the pipeline performs automated security scanning before deployment."

addedInput schema / properties / pipelineName / description

Added value: +"Human-readable name of the CI/CD pipeline being reviewed."

First observedv0.4.0Oct 1, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=true, so the safety profile is covered; the description reinforces this by enumerating the side effects it will not cause. It also adds a genuine behavioral trait beyond the annotations – that output separates missing evidence from failed controls – but does not cover depth of analysis or evidence requirements.

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 tight sentences with the core purpose front-loaded, then routing guidance, then the analysis-only constraint. Every clause earns its place with no restatement of the name or schema.

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?

With an output schema present, return values need not be explained, and annotations cover the safety and idempotency profile. The description supplies scope, sibling routing, and the no-side-effects guarantee, leaving nothing an agent needs to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100% across all 8 parameters, including the deploymentStrategy enum, so the schema carries full semantic load. The description adds no parameter-level guidance beyond the structured fields, making the baseline 3 correct here.

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?

States a specific verb and resource: 'Evaluate generic CI/CD production-readiness controls from structured pipeline facts', and adds the differentiator 'separating missing evidence from failed controls'. It explicitly names the sibling review_github_actions_workflow as the alternative for raw YAML, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Gives an explicit when-to-use ('platform-agnostic delivery process review') and a named alternative with its triggering condition ('for raw GitHub Actions YAML, use review_github_actions_workflow'). It also states the exclusions: analysis-only, no builds, deployments, approvals, or pipeline changes.

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

Deploy Server