mcp-adr-analysis-server

bootstrap_validation_loop

Read-onlyIdempotent

Validate deployment iteratively: receive step-by-step commands, submit outputs, and get next actions after environment detection and confirmation.

Instructions

GUIDED EXECUTION MODE: This tool guides you through an interactive, step-by-step deployment validation workflow. It does NOT execute commands internally - instead, it tells YOU what commands to run and processes the results iteratively. Workflow: (1) First call with iteration=0: Detects platform (OpenShift/K8s/Docker), validates environment connection, and requests human approval for target platform. (2) Subsequent calls: After running each command and reporting back with output, the tool provides next steps. Environment Validation: Before deployment, the tool verifies connection to the target platform (e.g., oc status for OpenShift, kubectl cluster-info for K8s) and requires explicit human confirmation. Validated Patterns Integration: Automatically identifies base code repositories (e.g., validatedpatterns/common for OpenShift) and guides you to merge them into your project. Deployment Cleanup: Supports CI/CD-style workflows with deployment teardown/restart guidance. Call this tool iteratively, passing previous command output back each time.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "bootstrap_validation_loop"
  }
}

Input Schema

Name	Required	Description	Default
`autoFix`	No	Whether to generate auto-fix suggestions in guidance
`appSelector`	No	Label selector scoping every destructive teardown command, e.g. "app=checkout-api". Required before any kubectl/oc delete is offered — the tool will not guess a selector, and without this it returns discovery instructions instead of a delete.
`projectPath`	No	Path to the project directory	.
`adrDirectory`	No	Directory where ADRs are stored	docs/adrs
`maxIterations`	No	Maximum validation/fix iterations
`currentIteration`	No	Current iteration number (0 for initial call, then increment). Used to track workflow progress.
`targetEnvironment`	No	Target deployment environment	development
`previousExecutionOutput`	No	Output from the previous command execution. Paste the stdout/stderr from running the command that was recommended in the previous iteration.
`updateAdrsWithLearnings`	No	Update ADRs with deployment learnings (non-sensitive)
`previousExecutionSuccess`	No	Whether the previous command execution succeeded (exit code 0). Set to true if command succeeded, false if it failed.
`deploymentCleanupRequested`	No	Set to true to request deployment cleanup/teardown guidance (for CI/CD workflows that need to delete and restart deployments).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.7.46Sep 2, 2026

removedInput schema / properties / conversationContext

Removed value: -{
-  "additionalProperties": false,
-  "description": "Rich context from the calling LLM about user goals and discussion history",
-  "properties": {
-    "budget": {
-      "description": "Budget or resource constraints (e.g., \"limited budget\", \"enterprise scale\")",
-      "type": "string"
-    },
-    "constraints": {
-      "description": "Limitations, compliance requirements, or restrictions (e.g., [\"GDPR compliance\", \"budget under $50k\", \"minimal downtime\"])",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "focusAreas": {
-      "description": "Specific areas of concern or interest (e.g., [\"security\", \"performance\", \"maintainability\"])",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "humanRequest": {
-      "description": "Original human request text for context restoration and knowledge graph storage",
-      "type": "string"
-    },
-    "previousContext": {
-      "description": "Relevant context from previous conversation (e.g., \"User mentioned concerns about database splitting\")",
-      "type": "string"
-    },
-    "projectPhase": {
-      "description": "Current project phase (e.g., \"planning\", \"development\", \"migration\", \"production\")",
-      "type": "string"
-    },
-    "requirements": {
-      "description": "Specific requirements or preferences mentioned",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "timeline": {
-      "description": "Timeline or urgency information (e.g., \"launch in 3 months\", \"urgent migration\")",
-      "type": "string"
-    },
-    "userGoals": {
-      "description": "Primary objectives the user wants to achieve (e.g., [\"microservices migration\", \"improve security\"])",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "userRole": {
-      "description": "User's role or expertise level (e.g., \"senior architect\", \"developer\", \"project manager\")",
-      "type": "string"
-    }
-  },
-  "type": "object"
-}

Changed1 schema field changedv2.7.32Aug 29, 2026

addedInput schema / properties / appSelector

Added value: +{
+  "description": "Label selector scoping every destructive teardown command, e.g. \"app=checkout-api\". Required before any kubectl/oc delete is offered — the tool will not guess a selector, and without this it returns discovery instructions instead of a delete.",
+  "type": "string"
+}

Addedv1.0.0Jan 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

The description adds significant behavioral detail beyond the annotations: the tool does not run commands internally, it iteratively processes user-provided output, it requires explicit human confirmation for platform selection, and it detects the target platform. These traits align with the readOnlyHint and destructiveHint annotations and provide the agent with essential expectations for the tool's interaction model. It does not cover every edge behavior (e.g., maxIterations behavior), but the disclosed traits are highly valuable.

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?

The description is well-structured with bold section headers and front-loads the most critical fact (does NOT execute commands internally). Some redundancy exists, such as repeating that the tool is iterative and that the user reports back output, but overall every section contributes to the agent's understanding of the tool's operation mode. It earns a 4 rather than 5 because the moderate length and occasional repetition could be tightened.

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 complexity (11 parameters, no output schema), the description covers the core interaction loop, platform detection, environment validation, human approval requirements, validated patterns integration, and cleanup guidance. Missing details like maxIterations termination, ADR update behavior, and output structure are either captured in the schema or are peripheral to the main workflow. This is a reasonably complete overview for a tool of this complexity.

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 baseline is 3. The description reinforces the meaning of currentIteration and previousExecutionOutput by explaining the iterative flow, but it does not add new parameter-level semantics that are not already present in the schema. The workflow explanation provides useful context, but the schema descriptions already carry the detailed parameter definitions.

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 tool's specific function: it guides an interactive, step-by-step deployment validation workflow and does NOT execute commands itself. It distinguishes itself from sibling tools by emphasizing its 'GUIDED EXECUTION MODE' and iterative command-feedback loop, which is a unique behavioral trait among the listed deployment tools. However, it does not explicitly name or compare against alternatives like deployment_readiness or troubleshoot_guided_workflow, so differentiation relies on behavioral description rather than explicit contrast.

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?

The description provides concrete usage context: when to make the first call (iteration=0), how subsequent calls should pass back command output, and when to request deployment cleanup for CI/CD workflows. It also specifies that human approval is required before deployment and before destructive commands may be offered. It does not, however, explicitly state when not to use this tool or mention alternative tools, so it stops short of a full when/when-not comparison.

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

Deploy Server