Skip to main content
Glama
Cerios-TechLab

Quality Transformation Coach Assistent MCP server

Cicd Readiness Scan

cicd_readiness_scan

Assess CI/CD readiness across 5 domains with 103 questions. Submit answers or retrieve the full question set to evaluate your pipeline maturity.

Instructions

Run a CI/CD Readiness Scan assessment with 103 questions across 5 domains.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
answersNoOptional dict mapping question text to 'ja'/'nee'. If None, returns the full question set for manual assessment.
projectYesProject name

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.0

TDQS

C2.9/5.0
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 burden, yet it discloses only scope counts. It does not explain the two-phase usage model (omitting answers to get the question set vs. submitting answers), whether the scan is read-only, or what non-obvious side effects occur.

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

Conciseness4/5

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

A single front-loaded sentence with no wasted words. It is efficient and appropriately brief, though the brevity comes at the cost of leaving usage and behavioral detail unaddressed.

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?

An output schema exists, so return values need not be explained, and 100% schema coverage handles parameters. However, with no annotations and no usage or side-effect guidance, the definition is only minimally adequate for an agent deciding when and how to invoke it.

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 the 'answers' and 'project' semantics are already documented in the schema, and this is the baseline case. The description echoes the domain/question scope but adds nothing about parameter format or accepted values beyond the schema (e.g., 'ja'/'nee' mapping is schema-only).

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?

States a specific verb and resource ('Run a CI/CD Readiness Scan assessment') and adds scope detail (103 questions, 5 domains). This clearly identifies the tool as an assessment/scan, but it does not differentiate itself from siblings like maturity_assessment or quality_gate_check that also read as assessments.

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 when-to-use guidance, no prerequisites, and does not name or contrast any alternative among the many assessment siblings. An agent cannot infer from the text alone when this scan is preferable to maturity_assessment.

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