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.
This server publishes no instructions, or was last inspected before Glama recorded them.
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_exceptionC | Sanitized details and the application stack trace for an exception fingerprint. |
| list_late_regressionsC | Failures found after a release was cleared, on paths the clearance did not cover. |
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
get_verification (immediate snapshot) and wait_for_verification (blocking poll) are functionally distinct, and the remaining tools target clearly separate resources: deployments list, exercise plan, exception details, and post-clearance regressions. There is mild overlap between get_verification and wait_for_verification since both return the same verdict document, but descriptions clarify the difference.
All six tools follow a clean verb_noun snake_case pattern (get_*, wait_for_*, list_*), with verbs matching their action type consistently. No convention mixing.
Six tools is well-scoped for a deployment verification/monitoring server, with each tool earning its place in the verification workflow.
Coverage is strong for the verification domain: read state, wait for verdict, plan exercises, list deployments, inspect exceptions, and track late regressions. However, the exercise-plan description references a 'report_with' tool for reporting runs that is not present, creating a minor dead end.