Bastion

What apatureai/bastion MCP server does

apatureai/bastion MCP server exposes an MCP workflow for reviewing rendered interfaces at authorized HTTPS preview URLs. A coding agent submits a review request and receives a job rather than an immediate critique. The resulting Critique can include a grade, findings, routes, viewports, element references, severity levels, and suggested fixes.

The server does not modify source code, operate a browser, or create pull requests. It supplies observations and verification results; the coding agent remains responsible for applying changes. The workflow is therefore suited to an agent loop in which UI changes are made externally and then checked again.

How it works

design_review starts an asynchronous review for selected routes, viewports, and either triage or deep depth. design_review_get can return only the job status or retrieve the critique through summary, findings, focus, or evidence views. The focus view keeps actionable blocker and should_fix findings while omitting nits. The evidence view also includes MCP content blocks and presentation information for content the client could not render.

After changes are made, design_recheck accepts between one and 20 findings from a completed review. It checks whether the target remains valid and rejects a changed host or an unchanged target. design_review_cancel provides best-effort cancellation for queued or running jobs when the caller has the reviews:cancel scope. design_review_panel_action handles panel interactions, such as returning a grounded fix or references to verify again.

Every critique includes provenance and coverage information. Agents should trust a result only when provenance.model_backed is true and coverage.state is not nothing. Coverage distinguishes full, partial, nothing, and unstated review surfaces, so an apparently clean result is not automatically evidence that every requested route was inspected.

Setup and configuration

Run apatureai/bastion MCP server with Node 24 or newer and pnpm 9.15.0. The repository's documented setup is:

git clone https://github.com/apatureai/bastion.git
cd bastion
corepack enable
pnpm install --frozen-lockfile
pnpm build

The project requires the npm registry during installation, but the documented local workflow does not require an API key, database, Docker, or an ongoing external connection. After building, pnpm demo starts a real MCP client that launches the server as a child process over stdio and exercises the review flow. It writes out/review.json and a self-contained out/panel.html.

With no review backend configured, the output comes from a golden fixture describing a fictional pricing page. The payload identifies that source through provenance, so fixture findings should not be treated as judgments of the submitted URL. The README also notes that changing one environment variable can switch to a real critique, but the excerpt does not specify that variable or the remote deployment procedure.

Tools and capabilities

• design_review: submit an authorized HTTPS preview for asynchronous review.
• design_review_get: poll status or retrieve the critique in five views.
• design_recheck: re-evaluate selected findings after UI changes.
• design_review_cancel: attempt to stop a queued or running review.
• design_review_panel_action: return a finding fix or verification references from a panel interaction.

The generated panel contains embedded evidence and makes no external requests. Result records use freshly generated job and review identifiers. Read-only MCP annotations apply to result retrieval and panel actions; submission, recheck, and cancellation represent state-changing or metered operations.

Limitations and notes

The local fixture path is not a real assessment of the supplied page, and fixture or mock-style verdicts use an unjudged grade with null confidence. Rechecks currently run against the fixture engine, so their outcomes are also marked unjudged. A remote verdict may identify that a real judgment exists without exposing which model deployment performed it.

The server enforces an authorized-host boundary for HTTPS previews. The documented demo rejects an unauthorized host as an SSRF protection check. The server also identifies itself on the MCP wire as apature-mcp-review, despite the repository name being bastion; existing client configurations may therefore need to use that wire name.