Cloud DevOps MCP Server

Overview Schema Source Related Servers Discussions Admin

Review GitHub Actions Workflow

review_github_actions_workflow

Read-onlyIdempotent

Evaluate GitHub Actions workflow security and deployment readiness from YAML or structured facts, checking triggers, action pinning, token permissions, caching, environment protection, concurrency.

Instructions

Evaluate GitHub Actions workflow security and deployment readiness from structured facts or raw workflow YAML, including triggers, action pinning, token permissions, caching, environment protection and concurrency. Use review_cicd_pipeline for generic non-GitHub delivery-process review. It examines supplied evidence only and does not call GitHub or dispatch workflows.

Input Schema

TableJSON Schema

Name	Required	Description
`triggers`	No	Workflow trigger events when raw YAML is not supplied, such as push, pull_request or workflow_dispatch.
`workflowName`	Yes	Human-readable name of the GitHub Actions workflow being reviewed.
`workflowYaml`	No	Raw GitHub Actions workflow YAML. The server derives triggers, action pinning, token permissions, caching and concurrency.
`hasSecretScanning`	No	Whether the workflow or surrounding delivery process performs automated secret scanning.
`usesPinnedActions`	No	Whether third-party actions are pinned to immutable commit SHAs.
`deploysToProduction`	No	Whether the workflow can deploy directly or indirectly to production.
`hasDependencyCaching`	No	Whether dependency caching is configured for repeatable and efficient builds.
`hasConcurrencyControl`	No	Whether concurrency settings prevent overlapping or conflicting workflow runs.
`hasEnvironmentProtection`	No	Whether protected GitHub environments or equivalent approval controls guard production deployments.
`hasLeastPrivilegePermissions`	No	Whether GITHUB_TOKEN permissions are explicitly restricted to least privilege.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`evidence`	Yes
`findings`	Yes
`triggers`	Yes
`strengths`	Yes
`workflowName`	Yes
`uncertainties`	Yes
`workflowScore`	Yes
`readinessLevel`	Yes
`recommendedControls`	Yes
`assessmentConfidence`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.14.0Oct 3, 2026

addedInput schema / properties / deploysToProduction / description

Added value: +"Whether the workflow can deploy directly or indirectly to production."

addedInput schema / properties / hasConcurrencyControl / description

Added value: +"Whether concurrency settings prevent overlapping or conflicting workflow runs."

addedInput schema / properties / hasDependencyCaching / description

Added value: +"Whether dependency caching is configured for repeatable and efficient builds."

addedInput schema / properties / hasEnvironmentProtection / description

Added value: +"Whether protected GitHub environments or equivalent approval controls guard production deployments."

addedInput schema / properties / hasLeastPrivilegePermissions / description

Added value: +"Whether GITHUB_TOKEN permissions are explicitly restricted to least privilege."

addedInput schema / properties / hasSecretScanning / description

Added value: +"Whether the workflow or surrounding delivery process performs automated secret scanning."

addedInput schema / properties / triggers / description

Added value: +"Workflow trigger events when raw YAML is not supplied, such as push, pull_request or workflow_dispatch."

addedInput schema / properties / usesPinnedActions / description

Added value: +"Whether third-party actions are pinned to immutable commit SHAs."

addedInput schema / properties / workflowName / description

Added value: +"Human-readable name of the GitHub Actions workflow being reviewed."

First observedv0.4.0Oct 1, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful specifics beyond that: 'examines supplied evidence only and does not call GitHub or dispatch workflows', which concretely reinforces the closed-world, non-mutating behavior. It does not discuss limits or assessment trade-offs, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler. The scope is front-loaded in the first sentence and the sibling routing plus closed-world caveat follow immediately after.

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 and annotations are rich, so return values and safety need not be explained. The description covers input modes and routing, leaving only minor ambiguity about whether raw YAML and the boolean fact fields can be combined or which takes precedence.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented, and the description's facet list largely mirrors the property names rather than adding syntax, precedence, or format detail. Baseline 3 is appropriate when the schema carries the parameter burden; the one mild addition is the implication that YAML input supersedes the boolean fact fields.

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 ('Evaluate') and resource ('GitHub Actions workflow security and deployment readiness') and enumerates the exact facets assessed (triggers, action pinning, token permissions, caching, environment protection, concurrency). It explicitly distinguishes itself from the sibling review_cicd_pipeline, so an agent can route correctly 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?

Names the alternative tool explicitly ('Use review_cicd_pipeline for generic non-GitHub delivery-process review') and describes the input modes it accepts ('structured facts or raw workflow YAML'). The boundary condition for choosing the sibling versus this tool is stated, not inferred.

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

Deploy Server