What can you do with this server?

The Blast Scope MCP server is a consequence engine that assesses the blast radius of shell commands and provides undo snapshots for reversible actions. It offers the following tools: * assess_command: Analyzes a shell command's potential destructive impact, returning a risk score (0.0–1.0), severity (low/medium/high/critical), recommendation (proceed/confirm/block), rationale, evidence, recoverability classification, and a per-segment breakdown for chained commands. Uses a project dependency graph for contextual scoring. * index_project: Forces a rebuild of the project's dependency graph, which is used by assess_command for more accurate risk scoring. Automatically triggered on first use, but can be manually run after large changes. * list_snapshots: Lists available undo snapshots automatically created before high-risk commands, showing ID, creation time, reason, and covered paths. * restore_snapshot: Restores files from a selected snapshot to undo the effects of a risky command.

Which integrations are available for this server?

Scores destructive Docker commands (e.g., volume rm, system prune -a, rm -f) by performing safe read-only probes to assess blast radius and reversibility. Scores destructive Git commands (e.g., reset --hard, push --force, branch -D, clean -fdx) by using read-only probes like status, reflog, and rev-list to determine risk. Scores destructive SQL commands (e.g., DROP, TRUNCATE, DELETE without WHERE) by performing read-only SELECT count(*) probes on SQLite databases to assess data loss risk.

blast-scope-mcp

by Atharva-Jayappa

Overview Schema Related Servers Score Discussions

Python

Local

Blast Scope

A consequence engine for shell commands. Blast Scope scores what a command would actually do — before an AI agent (or you) runs it. It doesn't pattern-match syntax into a blocklist; it figures out the command's real target, observes that target with a safe, read-only probe, and returns a structured risk score with evidence.

The whole point is contextual blast radius. The same command gets a completely different score depending on what it would actually hit:

COMMAND                            SEVERITY   WHY                                          ADVICE
─────────────────────────────────  ────────   ──────────────────────────────────────────  ───────
rm -rf ./logs                      LOW        0 importers · regenerable · outside src      proceed
rm -rf ./config                    CRITICAL   8 modules import it · high PageRank hub      block
git reset --hard   (clean tree)    LOW        nothing uncommitted to discard               proceed
git reset --hard   (4 dirty files) HIGH       would throw away 4 files of uncommitted work confirm
git push --force   (protected)     CRITICAL   would orphan commits on a protected branch   block
docker volume rm cache  (absent)   LOW        volume doesn't exist — nothing to remove     proceed
docker volume rm pgdata (in use)   CRITICAL   holds data · in use · no image to rebuild    block
pip uninstall flask     (uv.lock)  LOW        regenerable — exact version pinned in lock   proceed
DROP TABLE users        (42 rows)  CRITICAL   schema + 42 rows · irreversible              block
DELETE FROM logs        (in txn)   HIGH       no WHERE — but inside a txn, ROLLBACK-able    confirm

Two commands can be byte-identical and score four bands apart. That gap is the product.

Not a blocklist. Not a replacement for Shellfirm. Not a syscall monitor. It scores structural consequence — advisory, never blocking — and for the rare critical command it captures an undo snapshot first.

How it works

A command flows through a cheap funnel: almost everything is recognized as non-destructive in microseconds and exits silent. Only a flagged destructive candidate pays for a probe.

  shell command
      │   split chains (&& || ; |) · de-alias PowerShell · parse flags/targets
      ▼
  ┌──────────────────────────────────────────────────────────────────────┐
  │  STAGE 1 · triage  (near-free regex — runs on every command)          │
  │     which class?   git · docker · pip/uv · sql · else filesystem       │
  │     destructive?   `git status` → no.   `git reset --hard` → yes ↓     │
  └───────────────────────────────┬──────────────────────────────────────┘
                    destructive candidate │   (everything else exits here, silent)
                                          ▼
  ┌──────────────────────────────────────────────────────────────────────┐
  │  ELIGIBILITY FILTER   safe read-only probe?   AND   undo authorable?   │
  └──────────────┬──────────────────────────────────────┬─────────────────┘
         yes, probe it │                       no probe here / now │
                       ▼                                           ▼
   STAGE 2 · safe probe (read-only)                    heuristic estimate
     git  status · reflog · rev-list                   from a static per-class
     docker  inspect · ps · ls                          table — and LABELED
     sqlite  SELECT count(*)  [mode=ro]                  "(estimated)" so you
     pip/uv  read lockfiles                              know it wasn't probed
                       │                                           │
                       └─────────────────────┬─────────────────────┘
                                              ▼
        blast radius  ×  reversibility   (combined PER CLASS — no global formula)
        filesystem also folds in: dependency-graph centrality + recoverability
                                              ▼
              score 0.0–1.0  →  severity (low / medium / high / critical)
                                              ▼
        PreToolUse hook:  silent (low/med) · advise (high) · advise + snapshot (critical)

The eligibility filter is the design boundary. A command class earns a live probe only when both hold: (1) its impact is observable by a strictly side-effect-free read (HTTP-GET sense — never mutate state to assess state), and (2) its undo story is well-known enough to encode in a static table. When a probe can't run here and now (no docker daemon, no DB driver, no creds), the tool degrades to a labeled estimate — it never guesses silently, and it never blocks.

See docs/heuristics.md for the per-class tables, the exact filesystem formula, and calibration.

The five command classes

Class	Destructive ops it scores	Safe (read-only) probe	Reversibility signal
Filesystem	`rm -rf`, `mv`, `>` truncate	dependency graph + git status	git-tracked? regenerable? secret? precious?
Git	`reset --hard`, `push --force`, `branch -D`, `clean -fdx`	`status` · `reflog` · `rev-list` · `rev-parse @{u}`	reflog window · remote ahead · protected branch
Docker	`volume rm`, `system prune -a`, `rm -f`	`volume inspect` · `ps -a` · `volume ls`	volume → none · container → recreatable from image
pip / uv	`pip uninstall`, `uv pip uninstall`	read lockfile / manifest (no subprocess)	lockfile present → fully regenerable
SQL	`DROP`, `TRUNCATE`, `DELETE` without `WHERE`	SQLite: `SELECT count(*)` `mode=ro`; transaction check	inside a transaction? backup posture?

New classes drop in behind one protocol (triage / assess) in src/blast_scope/classes/; each class confines assess to strictly side-effect-free reads.

Related MCP server: Capsule Bash Server

Status

Calibrated multi-class guardrail with command resolution and a precise dependency graph.

Capability	Module
Flag/operand-sensitive command model (POSIX and PowerShell)	`command_effects.py`, `command_parser.py`
Command resolution — env/tilde/brace/glob expansion, unset-var hazards, script transparency (`sh -c`, `npm run` + pre/post hooks, script files, Makefile targets), read-only `$(...)` substitution	`resolution.py`
Dry-run oracles — `git clean -n` exact lists, reset divergence, checkout clobber preview, `find -delete`→`-print` rewrite, sqlite scoped-DELETE counts, rsync `--dry-run`; oracle targets feed the undo snapshot	`classes/git.py`, `classes/find.py`, `classes/rsync.py`, `classes/sql.py`
Recoverability classification (git state, secrets, regenerable, precious data)	`recoverability.py`
Dependency graph + weighted PageRank centrality, incremental indexing	`graph_resolver.py`, `centrality.py`
Two-axis, evidence-based filesystem scoring	`risk_scorer.py`
Command-class probes — git / docker / pip·uv / SQL, behind one protocol	`classes/`
Out-of-graph path analyzers (infra / config-by-path) + git base	`consequences.py`, `vcs.py`, `infra.py`, `config_refs.py`
PreToolUse hook + tarball snapshot/undo	`hook.py`, `snapshot.py`
Eval harness + labeled corpus + calibration	`eval.py`, `tests/fixtures/eval_corpus.jsonl`

Calibration. Two harnesses, both run-it-yourself:

In-repo corpus (tests/fixtures/eval_corpus.jsonl, 58 cases spanning every recoverability category, git working-tree state, infra/config, rm -rf .git, a graph-indexed central module, the git/docker/pip/SQL classes, and the resolution layer — unset-var collapses, glob/env-var targets, sh -c payloads, npm pre-hooks, opaque wrappers, mass destruction of tracked source) — 58/58 exact severity, gate F1 1.00, pinned by tests/test_eval.py with headroom so changes can't silently regress.
SABER — 716 real coding-agent workspaces. Against ~1725 safe commands, blast-scope's false-positive rate is 0.58%; on its core competency (data_destruction) it catches 82.4% of injected attacks on realistic workspaces — on the fast hook path, no graph required, thanks to command resolution (env/glob binding + script transparency). Wrapper transparency also lifts code_tampering from ~0% to 50%. The per-category recall is deliberately uneven, and the table says so: blast-scope scores destructive consequence — filesystem/data loss plus git/docker/pip/SQL state. Network exfiltration and persistence are a different threat model, out of scope by design — not an unfinished corner. That's the boundary, drawn on purpose. See bench/.

uv run python -m blast_scope.eval                 # in-repo corpus
python bench/saber_eval.py --tasks <saber>/dataset/data/tasks.jsonl   # SABER

Installation

The fastest path for any MCP client is zero-install via uvx (no clone, no venv):

uvx blast-scope        # runs the MCP server on stdio

Claude Code users — one line wires up both the MCP tools and the advisory hook:

/plugin marketplace add Atharva-Jayappa/blast-scope
/plugin install blast-scope

For development, or to pin a checkout:

git clone https://github.com/Atharva-Jayappa/blast-scope.git
cd blast-scope && uv sync --all-extras

Usage

As an MCP server

Add to your MCP client config (e.g. Claude Code settings.json):

{
  "mcpServers": {
    "blast-scope": { "command": "uvx", "args": ["blast-scope"], "type": "stdio" }
  }
}

Tools exposed:

Tool	Purpose
`assess_command(command, cwd?, project_root?)`	Score a (possibly chained) command. Returns score, severity, rationale, evidence, recoverability, affected nodes, and a per-segment `chain` breakdown.
`index_project(project_root)`	Force a dependency-graph rebuild (auto-built on first use otherwise).
`list_snapshots(project_root)`	List undo snapshots, newest first.
`restore_snapshot(snapshot_id, project_root)`	Undo a risky command by restoring its snapshot.

As a hook (tiered advice + auto-snapshot)

Intercept Bash commands before they run — advisory, never blocking. Volume scales with stakes: silent on low/medium, advise on high, advise + snapshot on critical. The snapshot skips what's already recoverable (git-clean, regenerable) and warns rather than tars anything over a hard size cap, so the undo net stays fast and trustworthy.

The hooks also keep the dependency graph alive on their own — no MCP call needed: SessionStart cold-builds it in a detached background process, and every PreToolUse refreshes it incrementally before scoring (a ~20 ms stat sweep when nothing changed), so verdicts track the current tree even after a burst of agent edits. Add to .claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      { "hooks": [{ "type": "command", "command": "python -m blast_scope.hook" }] }
    ],
    "PreToolUse": [
      { "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "python -m blast_scope.hook" }] }
    ]
  }
}

Full details and the undo flow: docs/hook.md.

Example output

A filesystem command, scored against the dependency graph:

// assess_command("rm -rf ./config", project_root="/proj")
{
  "score": 0.93,
  "severity": "critical",
  "recommendation": "block",
  "recoverability": "untracked",
  "rationale": "rm targets config. 8 direct importer(s), 14 total affected. not git-tracked. recursive deletion. CRITICAL risk.",
  "evidence": [
    "8 importer(s), 14 affected node(s)",
    "high centrality (PageRank 0.91) — a hub other code routes through",
    "untracked — not in git history",
    "recursive — applies to every file underneath"
  ],
  "affected_nodes": [ /* ... */ ],
  "chain": [ /* per-segment breakdown */ ]
}

A command class that couldn't probe — note the labeled estimate (no Postgres driver, server possibly remote, so the tool refuses to guess silently):

// assess_command('psql -c "DROP TABLE users"')
{
  "score": 0.9,
  "severity": "critical",
  "recommendation": "block",
  "evidence": [
    "drops users — its schema and all rows, irreversible (estimated — no read-only probe for postgres)"
  ]
}
// the same DROP against a local SQLite file probes for real:
//   "drops users — its schema and 42 row(s), irreversible"   (estimated: false)

Development

uv sync --all-extras
uv run pytest -q              # full suite
uv run python -m blast_scope.eval   # scoring accuracy report

Project structure

blast-scope/
├── src/blast_scope/
│   ├── server.py            # MCP server + tools (assess, index, snapshots)
│   ├── command_parser.py    # shell → structured intent (POSIX + PowerShell)
│   ├── command_effects.py   # command/flag/operand → intent + weight
│   ├── recoverability.py    # path → how recoverable if destroyed
│   ├── graph_resolver.py    # paths → dependency-graph impact (+ PageRank)
│   ├── centrality.py        # pure-Python weighted PageRank
│   ├── risk_scorer.py       # signals → score + severity + evidence
│   ├── classes/             # command-class probes behind one protocol
│   │   ├── __init__.py      #   Candidate · ConsequenceClass · registry
│   │   ├── git.py           #   reflog / upstream-divergence / protected branch
│   │   ├── docker.py        #   volume / container / system-prune probes
│   │   ├── packages.py      #   pip·uv uninstall vs. lockfile presence
│   │   └── sql.py           #   DROP/TRUNCATE/DELETE — SQLite probe + estimates
│   ├── consequences.py      # coordinator: class probes + path analyzers
│   ├── vcs.py / infra.py / config_refs.py   # git base + path analyzers
│   ├── hook.py              # PreToolUse advisory hook
│   ├── snapshot.py          # tarball snapshot / restore / list
│   ├── eval.py              # evaluation harness + metrics
│   └── vendor/crg/          # vendored from code-review-graph (MIT)
├── tests/                   # 298 tests incl. eval regression guard
│   └── fixtures/eval_corpus.jsonl   # labeled calibration corpus
└── docs/
    ├── heuristics.md        # scoring model + per-class tables + calibration
    └── hook.md              # hook registration + undo

Roadmap

Lift recall on the destruction classes (glob targets over tracked files, find-based deletion variants) — the SABER per-category table is the worklist.
Optional live probes for Postgres/MySQL (in-process, read-only) once a driver policy is settled — today those engines degrade to labeled estimates.
PowerShell-shell awareness in the hook path (the MCP tool already supports it).
Optional richer interception modes beyond advisory.

See CLAUDE.md for the full spec, contracts, and design rules.

License

Apache 2.0 (versions ≤ 0.3.1 were MIT). The vendored code-review-graph sources remain MIT under their upstream notice — see NOTICE.

Available Tools

4 tools

assess_commandA

Assess the blast radius of a shell command.

Splits chained commands on &&, ||, ;, and |, then parses, resolves, and scores each segment independently. The top-level fields surface the worst step's score and recommendation; the chain field contains every step's individual breakdown.

When project_root is provided and no graph database exists yet, the graph is built automatically on the first call. Use index_project to force a rebuild.

Args: command: Raw shell command string to analyze. cwd: Working directory for resolving relative paths. Defaults to the server's current working directory. project_root: Root directory of the project for graph-based scoring. If provided, the graph is auto-built when missing.

Returns: Structured risk assessment with worst-step score, severity, recommendation, and per-step chain breakdown.

Example::

assess_command("cd /tmp && rm -rf .", cwd="/home/user", project_root="/project")

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`command`	Yes
`project_root`	No

TDQS

A4.6/5.0

Behavior4/5

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

Discloses key behaviors: splits chains on separators, resolves paths, scores independently, auto-builds graph when project_root provided. No annotation provided, so description carries full burden; could mention if there are side effects beyond graph building.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise yet comprehensive: first sentence states purpose, then details on chain processing, project_root behavior, Args/Returns/Example. Every sentence serves a clear purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains return structure (worst-step score, severity, recommendation, per-step chain). Example and parameter details make it complete for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds rich meaning: command as raw string, cwd for relative path resolution, project_root triggers auto-graph building. Far exceeds schema's types and names.

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 states that the tool assesses the blast radius of a shell command, splitting chained commands and scoring each segment. It distinguishes from sibling tools like index_project by focusing on analysis.

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?

Provides context on when to use (assessing blast radius) and explicitly mentions one alternative (use index_project to force rebuild). Lacks explicit 'when not to use', but example and parameter details guide usage.

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

index_projectA

Build or refresh the dependency graph for a project.

Forces a graph rebuild for the given project root. Normally not required — assess_command auto-builds the graph on first use — but useful to refresh after a large code change.

Args: project_root: Absolute path to the project root directory.

Returns: Status dict confirming the project was indexed.

Example::

index_project("/home/user/my-project")

ParametersJSON Schema

Name	Required	Description	Default
`project_root`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states 'forces a graph rebuild' and returns a status dict, implying a mutation. However, it does not disclose whether the operation is idempotent, requires specific permissions, or has any side effects on the project files. The description is adequate but lacks depth on behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, uses a clear structure with an opening statement, usage guidance, args, returns, and an example. Every sentence adds value and there is no redundancy. It is well front-loaded with the core purpose.

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 simplicity (one required parameter, no output schema, no nested objects), the description covers the essential aspects: purpose, when to use, parameter explanation, return type, and an example. It lacks error scenarios or format validation, but overall it is complete enough for an AI agent to select and invoke correctly.

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 coverage is 0%, so the description must compensate. It explains project_root as 'Absolute path to the project root directory.' This adds basic meaning but does not specify constraints like path must exist, format, or that the project must already be recognized. The description is minimal and barely adds value beyond the parameter name.

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 states the tool builds or refreshes the dependency graph for a project. It specifies the verb 'build or refresh' and resource 'dependency graph for a project'. It also distinguishes itself from the sibling tool 'assess_command' by noting that this tool forces a rebuild, while assess_command auto-builds on first use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides usage guidance: 'Normally not required — assess_command auto-builds the graph on first use — but useful to refresh after a large code change.' This tells the agent when to use this tool and when not to, directly addressing the alternative sibling tool.

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

list_snapshotsA

List undo snapshots captured before risky commands, newest first.

Snapshots are taken automatically by the PreToolUse hook before a medium-or-higher risk command and stored under <project_root>/.blast-scope/snapshots.

Args: project_root: The project root the snapshots were taken under.

Returns: {"snapshots": [{id, created, reason, paths}, ...]}.

Example::

list_snapshots("/home/user/my-project")

ParametersJSON Schema

Name	Required	Description	Default
`project_root`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Without annotations, the description fully carries the transparency burden. It discloses that snapshots are automatic, stored under a specific directory, and sorted newest first. It also details the return format. No side effects are needed for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with no wasted words. It uses a docstring format with clear sections (Args, Returns, Example) and front-loads the purpose. Every sentence provides value.

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?

For a simple listing tool with one parameter and no output schema, the description covers purpose, trigger, location, ordering, and return format, plus an example. It is practically complete, though it could mention that restore_snapshot is the complementary sibling.

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?

The single parameter 'project_root' is described as 'The project root the snapshots were taken under,' which adds meaningful context beyond the schema's generic 'Project Root' title. With schema description coverage at 0%, the description compensates well.

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 explicitly states 'List undo snapshots captured before risky commands, newest first.' This clearly defines the verb (list), resource (undo snapshots), and ordering. It distinguishes itself from siblings like restore_snapshot by focusing on listing.

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 that snapshots are taken automatically before medium-or-higher risk commands, giving clear context for when to use this tool. It does not explicitly state when not to use it, but the purpose is well-defined.

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

restore_snapshotA

Undo a risky command by restoring a snapshot's files in place.

Overwrites whatever currently exists at each snapshotted path with the archived copy. Use list_snapshots to find the id.

Args: snapshot_id: The snapshot id to restore. project_root: The project root the snapshot was taken under.

Returns: {"status": "restored", "paths": [...]} or an error entry.

Example::

restore_snapshot("20260530T101500-a1b2c3", "/home/user/my-project")

ParametersJSON Schema

Name	Required	Description	Default
`snapshot_id`	Yes
`project_root`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It states 'Overwrites whatever currently exists at each snapshotted path,' disclosing destructive behavior. It also mentions return format. However, it lacks details on permissions, atomicity, or error handling for missing paths.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: front-loaded purpose, followed by args, returns, and an example. Every sentence adds value with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 required params, no output schema), the description covers purpose, parameter semantics, return format, usage context, and provides an example. It is complete for an agent to understand and invoke correctly.

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 0%, but the description adds meaning: snapshot_id is described as 'The snapshot id to restore' and project_root as 'The project root the snapshot was taken under.' The example shows a timestamp format for snapshot_id, going beyond schema titles.

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 states the tool's purpose: 'Undo a risky command by restoring a snapshot's files in place.' The verb 'restoring' and resource 'snapshot' are specific. Siblings like list_snapshots and assess_command are distinct in function, so no confusion.

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 advises to 'Use list_snapshots to find the id,' guiding the agent to a prerequisite step. It implies usage after a risky command. However, it does not explicitly exclude alternative scenarios or mention when not to use.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.5.2Jul 8, 2026
- First observedassess_command
- First observedindex_project
- First observedlist_snapshots
- First observedrestore_snapshot

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct action: assessing commands, rebuilding the graph, listing snapshots, and restoring them. No functional overlap exists.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with lowercase and underscores (assess_command, index_project, list_snapshots, restore_snapshot).

Tool Count5/5

Four tools cover the essential operations on the blast radius domain without redundancy or missing core functionality.

Completeness4/5

The set covers assessment, graph indexing, and snapshot retrieval/restoration. Snapshot lifecycle management (e.g., deletion) is not exposed, but the core workflow is complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
26
api-governance A
io.github.coderifts
API governance for AI agents. Detects breaking changes, scores blast radius, blocks unsafe calls.
API Testing Security Autonomous Agents
32
governance-platform A
ai.geodesiclabs
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
AI & Machine Learning Testing & QA Tools Monitoring
373
Evidra
io.github.vitas
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
Autonomous Agents Security Cloud Platforms
2

Related MCP Servers

Shell Executor MCP Server
Shell Access Code Execution Developer Tools
kosiew
F
license
Not graded
quality
D
maintenance
Provides safe shell command execution capabilities for AI agents and tools like VS Code Copilot through a whitelist-based filtering system.
Updated a year ago (2025-06-22 10:18 UTC)
-
Capsule Bash Serverofficial
Command Line Shell Access
capsulerun
A
license
A
quality
F
maintenance
Sandboxed Bash for Agents. Full state capture on every command.
Updated 4 months ago (2026-05-16 10:07 UTC)
3
30
15
Apache 2.0
bash-vet-mcp
Security Command Line Shell Access
temurkhan13
A
license
A
quality
B
maintenance
MCP server that vets LLM-emitted shell commands BEFORE execution — detects rm -rf nested deep in chains, package-manager glob removal (apt remove 'nvidia'), dd/mkfs filesystem destruction, chmod 777 / chown -R privilege blast, network-exfil via curl | bash, chained shutdown/reboot, git destructive ops. 30 detection rules across 8 families. Sub-second, local, free, MCP-native.
Updated 4 months ago (2026-05-10 22:44 UTC)
3
MIT
terminal-guardian-mcp
Shell Access Command Line
7Majesty-M
A
license
Not graded
quality
D
maintenance
Provides secure, sandboxed terminal access for AI assistants via the Model Context Protocol, with multi-layer risk analysis and auditable command execution.
Updated 3 months ago (2026-05-28 07:22 UTC)
15
7
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Atharva-Jayappa/blast-scope'

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

Blast Scope

How it works

The five command classes

Status

Installation

Usage

As an MCP server

As a hook (tiered advice + auto-snapshot)

Example output

Development

Project structure

Roadmap

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Capsule Bash Serverofficial

Latest Blog Posts

MCP directory API