blastcheck-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLOUDRIFT_API_TOKEN | No | Reserved for the future remote tier. If set today, the server notes on stderr that the remote tier is not in this release and runs the local tools only. Credentials are NEVER accepted as tool arguments. | |
| BLASTCHECK_MCP_EXPLAIN_BUDGET | No | Hard cap, in characters, on impact_explain output (default 32000, floor 4000). Over the cap, a compact grouped view with an explicit partial-view notice is returned instead - never a silent cut. | 32000 |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| impact_emitA | Produce an Impact Manifest (a machine-readable change-safety assertion) from a Terraform plan, using blastcheck. plan_path may point at Returns a manifest_handle (pass it to impact_explain) plus a short summary. The full manifest is written to a private temp file rather than returned inline, because it is large. |
| impact_explainA | Explain an Impact Manifest in plain language. Provide exactly one of: manifest_handle (from impact_emit), manifest_path (a manifest JSON file on disk), or manifest (the document inline). Returns markdown covering the verdict and why, each change's noteworthy findings, a "safe if ..." checklist of unmet preconditions, and what could not be verified. Output is capped by a hard budget (BLASTCHECK_MCP_EXPLAIN_BUDGET env, default 32000 characters). Large plans get a compact grouped view with an explicit partial-view notice - never a silent cut. Drill down with the optional filters, which combine with AND: severity (e.g. ["blocking"]), module_prefix (address prefix), resource_type (exact, e.g. "azurerm_managed_disk"), and addresses (exact addresses, always rendered in full detail - the guaranteed path to any specific change). All lists are lexically sorted before any cut, so the same plan always shows the same subset. Purely local and deterministic; nothing is sent anywhere. |
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 2 tools
The two tools have clearly distinct roles: impact_emit produces a manifest from a Terraform plan, while impact_explain consumes an existing manifest and explains it. There is no overlap or possible misselection between them.
Both tools follow the same predictable prefix-plus-verb pattern: impact_emit and impact_explain. The naming is consistent and immediately signals the shared domain and the action each tool performs.
Two tools is on the thin side by the general rubric, but the server has a very narrow purpose: emit and explain impact manifests. The pair is reasonable for that scope, though it barely crosses the 'feels thin' boundary.
For the stated domain, the lifecycle is complete: impact_emit generates a manifest from a plan, and impact_explain supports all reasonable input paths (handle, file, or inline) and offers filtering for drill-down. There are no obvious missing operations for this focused workflow.