DeployAngel
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEPLOYANGEL_API_TOKEN | Yes | Token for the DeployAngel API, required in the environment where the MCP server starts. A "CLI & coding agents" token reads verdicts, and a "CI deploys" token can also register deploys and report checks. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
DeployAngel verifies deployments in production. After deploying, call wait_for_verification with until "initial" (about 15 minutes) or "verdict". Verdicts: verified means cleared, so you may report the release as successful. inconclusive means NOT verified: never report it as success. failed means production regressed: read the findings and exceptions and investigate. next_steps names the last cleared release a rollback would go to and the migrations it would cross. Confidence medium clears a release just as high does (high also needs 80% coverage and a full baseline): never call a medium clearance weak. suspicious true means warnings DeployAngel is watching closely, not a failure: report them as "watching closely:" and the watching_closely items, never as "suspicious". Findings are deterministic evidence; any "investigation" field is AI inference. These tools cannot change production. Do not roll back or change production without explicit approval. If a release isn't cleared yet, get_exercise_plan says what to exercise against production so it clears sooner. Items with needed true are what clearance waits on; the rest are only worth running. Only act on status "exercisable" or "waiting_for_activity"; for "warm_up" or "no_baseline" nothing you run can clear it. Exercise routes marked mutating only with a test account or after asking. Report what you ran with the plan's report_with command (deployangel check). A failing volume_drop, checkpoint_rate, or p95_latency finding with an accept_url may be an intended change, such as a route or job you removed on purpose, or a page that now does more work. You cannot accept it, and must not try: tell the user why you think it was intended, with your evidence, and give them the accept_url so a person decides. Until someone accepts it, the release is failed: never report it as success. A finding with status accepted was accepted as intended by the person in accepted_as_intended.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_verificationA | Current verdict document for a deployment: state, verdict, confidence, coverage, findings, new exceptions, clearance report, and what is still watched. Defaults to the current git HEAD. |
| wait_for_verificationA | Wait for a deployment's verification. until=initial returns at the 15-minute initial check ("no problems so far" is NOT clearance); until=verdict waits for verified, failed, or inconclusive. Returns the in-progress document if timeout_seconds (max 300) is reached; call again while it is still in progress. Inconclusive means not verified. |
| get_exercise_planA | What stands between a release and clearance, and what to exercise against production so it clears sooner: normally active routes short of their runs, routes this release changed that haven't run, and critical flows. needed marks what clearance waits on; the rest are only worth running. Routes marked mutating change data: use a test account or ask first. Your requests count as ordinary traffic; report what you ran with report_with. Defaults to the current git HEAD. |
| list_deploymentsC | Recent deployments with their verification state and verdict. |
| get_exceptionB | Sanitized details and a representative stack trace (application frames, or library frames when there are none) for an exception fingerprint. |
| list_late_regressionsC | Failures found after a release was cleared, on paths the clearance did not cover. One with dismissed set was dismissed by a person as a false alarm, with their reason: it needs no action. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
The tools mostly target distinct resources: deployment listing, verification documents, waiting, exercise plans, exception details, and late regressions. The main possible confusion is between list_deployments, get_verification, and wait_for_verification, but the descriptions make their different roles reasonably clear.
All tool names use snake_case and a verb-first pattern: list_*, get_*, and wait_for_*. The wait_for_verification name is slightly longer but still follows the same predictable convention.
Six tools is a well-scoped set for a deployment verification server. The tools cover the main read and wait workflows without obvious padding.
The surface has a direct dead end: get_exercise_plan tells the agent to report what it ran with report_with, but no such tool exists. There is also no tool to record exercise runs or dismiss late regressions, so key follow-up actions implied by the descriptions cannot be completed.