Skip to main content
Glama

bootstrap_validation_loop

Validates deployment environments through an iterative workflow: detects platform, verifies connectivity, and guides cleanup, using step-by-step command execution and result processing.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
autoFixNoWhether to generate auto-fix suggestions in guidance
projectPathNoPath to the project directory.
adrDirectoryNoDirectory where ADRs are storeddocs/adrs
maxIterationsNoMaximum validation/fix iterations
currentIterationNoCurrent iteration number (0 for initial call, then increment). Used to track workflow progress.
targetEnvironmentNoTarget deployment environmentdevelopment
conversationContextNoRich context from the calling LLM about user goals and discussion history
previousExecutionOutputNoOutput from the previous command execution. Paste the stdout/stderr from running the command that was recommended in the previous iteration.
updateAdrsWithLearningsNoUpdate ADRs with deployment learnings (non-sensitive)
previousExecutionSuccessNoWhether the previous command execution succeeded (exit code 0). Set to true if command succeeded, false if it failed.
deploymentCleanupRequestedNoSet to true to request deployment cleanup/teardown guidance (for CI/CD workflows that need to delete and restart deployments).
Behavior4/5

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

With no annotations, the description carries full burden. It discloses key behaviors: does not execute commands internally, requires human approval, validates environment, supports cleanup/teardown. However, it does not cover authentication or rate limits.

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 detailed but well-structured with headings and bullet points. It is slightly verbose but every section adds necessary context for the iterative workflow. No wasted words.

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?

Given the complexity (11 parameters, nested objects, iterative flow), the description explains the workflow well but omits return format (no output schema) and error handling. Output behavior is only hinted ('provides next steps').

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 coverage is 100%, baseline 3. The description adds value by explaining parameter roles in the iterative process (e.g., currentIteration tracks progress, previousExecutionOutput feeds results). This goes beyond individual parameter descriptions.

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 clearly defines the tool as an interactive, step-by-step deployment validation workflow. It specifies verbs like 'guides' and 'tells you what commands to run', and distinguishes from sibling tools by its iterative, non-executing nature.

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 explains when to call the tool (for deployment validation), how to use it iteratively (first call with iteration=0, subsequent calls with output), and what to expect. It lacks explicit exclusions or alternatives, but provides sufficient usage context.

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

Install Server

Other Tools

Latest Blog Posts

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/tosin2013/mcp-adr-analysis-server'

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