mcp-bastion is a reliability, security, and audit proxy that sits between an MCP client and its upstream MCP servers, exposing four control tools so an agent can self-manage connections and review security/compliance.
Check server health — bastion__status reports every proxied server's state (connected / disconnected / reconnecting / failed), tool counts, and last error.
Recover dropped servers — bastion__reconnect takes a server name and reconnects it without human intervention.
Review tool security — bastion__security reports per-tool pin status (approved vs. changed, i.e. possible rug-pull), poisoning heuristics triggered, and cross-server name shadowing.
Get audit/compliance summaries — bastion__compliance returns recent tool activity mapped to NIST AI RMF functions and OWASP LLM Top 10 categories (requires audit.enabled).
Behind the tools, Bastion also aggregates and namespaces many upstream servers into one, auto-reconnects with backoff, health-checks periodically, blocks rug-pulls/injection/exfiltration, warns on poisoning, and writes tamper-evident audit events to pluggable sinks (console/file/webhook/OTLP).
Proxies and manages connections to the GitHub MCP server, providing tools for repository management, issue tracking, and other GitHub API operations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-bastion show me the status of all connected servers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A reliability & security proxy for the Model Context Protocol (MCP).
Self-healing connections, runtime tool-security, and a compliance-mapped audit trail for your MCP servers.
mcp-bastion sits between your MCP client (Claude Code, Cursor, Cline, Windsurf, Zed, Claude
Desktop, or any MCP-compliant agent) and your MCP servers. It is client-agnostic — it works with
any compliant client through configuration alone, with zero client-specific code — and non-invasive:
your servers run unchanged, and removing Bastion is a one-line config revert.
📦 Package: mcp-bastion on npm · 🗂️ Official MCP Registry: io.github.Gowthaman90/mcp-bastion
🔒 Security, measured: on the open, vendor-neutral mcp-defense-bench, Bastion covers 63% of the MCP attack surface (15.0/24 vectors; 11 enforced) at zero false positives — the broadest of the proxies measured.
📖 Launch story: Medium · dev.to
👤 Created & maintained by Gowthaman Arumugam — Independent Researcher. Companion benchmark: mcp-defense-bench.
Related MCP server: McpVanguard
When an MCP server disconnects mid-session, the agent only sees a generic "No such tool available" error — indistinguishable from a tool that never existed — and it cannot reconnect; only a human can. Long agent sessions silently lose capabilities and fail in confusing ways.
Bastion closes that gap. It health-checks every server, auto-reconnects with backoff, and — crucially — exposes control tools so the agent itself can inspect connection health and recover a dropped server without human intervention.
Bastion now spans three layers: reliability (v0.1), runtime security (v0.2 — tool pinning / rug-pull & poisoning detection), and audit & compliance (v0.3 — pluggable sinks mapped to NIST AI RMF / OWASP LLM Top 10). See the roadmap.
Today your client connects directly to each server. With Bastion, your client connects to Bastion, which connects to those same servers on your behalf — so it sits in the tool-call path and can add reliability (and, later, security) transparently.
Before: Client ─▶ server A / server B / server C
After: Client ─▶ mcp-bastion ─▶ server A
─▶ server B
─▶ server CBastion is a standard MCP server to your client and a standard MCP client to each upstream. Because it speaks the protocol faithfully, it works with every compliant client automatically — the only per-client difference is where you put a few lines of config.
🔌 Client-agnostic — one binary, config-only integration; no per-client plugins.
♻️ Self-healing — health checks + capped exponential-backoff auto-reconnect for stdio servers.
🧭 Agent-recoverable — bastion__status and bastion__reconnect let the agent detect and fix
drops itself, instead of hitting an opaque "no such tool" wall.
🧩 Transparent aggregation — merges many servers into one, with per-server tool namespacing to prevent collisions and tool-shadowing.
💬 Legible failures — a dropped server yields an actionable message, not a crash.
🛡️ Runtime security (new in v0.2) — pins each tool's definition and blocks "rug pulls" (a server changing a tool after approval); heuristically inspects descriptions for poisoning; detects cross-server shadowing. See Runtime security.
📝 Audit & compliance (new in v0.3, opt-in) — structured, integrity-hash-chained audit events to pluggable sinks (console / file / webhook), mapped to NIST AI RMF & OWASP LLM Top 10. See Audit & compliance.
🪶 Non-invasive & reversible — your servers run unchanged; uninstall is a config revert.
🧱 Enterprise-grade codebase — strict TypeScript, layered architecture, ESLint + Prettier, and unit + end-to-end tests.
Bastion is published on npm as mcp-bastion — the
npx command below fetches it automatically, so there's nothing to install first.
1. Add Bastion to your client, pointing it at a config file:
// your client's mcpServers config
{
"mcpServers": {
"bastion": {
"command": "npx",
"args": ["-y", "mcp-bastion", "--config", "bastion.config.json"],
},
},
}2. List your real servers in bastion.config.json (moved verbatim from the client):
{
"servers": {
"github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] },
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"],
},
},
"reconnect": { "auto": true },
"healthCheck": { "enabled": true },
}3. Restart your client. Your tools now appear namespaced (e.g. github__create_issue) alongside
Bastion's control tools. See bastion.config.example.json for the
full set of options.
🔒 Security is on by default. Out of the box, Bastion runs the
balancedenforcement profile: it blocks high-confidence attacks (rug-pulls, argument/command injection, cross-server exfiltration) and warns on heuristic ones (description/response poisoning), while redacting leaked secrets from tool results. Setsecurity.enforcementProfiletoobserve(warn-only) orstrict(block-all), or tune any individual control — see Runtime security.
See the whole thing in action — a server crashing mid-session and healing itself:
npm run demoIt boots Bastion in front of a server that crashes on command, shows the agent getting an actionable
"reconnect" message instead of a cryptic error, and then the connection auto-recovering with no human
involved. To record it as a GIF: asciinema rec demo.cast -c "npm run demo" && agg demo.cast assets/demo.gif.
Bastion injects control tools so the agent can manage connections and review security itself, using only standard MCP calls:
Tool | Purpose |
| Health of every proxied server: connected / disconnected / reconnecting / failed, tool counts, last error. |
| Reconnect a named server (argument: |
| Per-tool security report: pin status (approved vs changed), poisoning findings, and shadowing. |
| Audit summary of recent activity mapped to NIST AI RMF / OWASP LLM Top 10 (requires |
Re-approval is operator-only. Clearing a rug-pull block is a security authority, so it is not an agent-callable tool — a prompt-injected agent must not be able to re-approve the very tool it was blocked from. A changed tool stays blocked until an operator clears it out-of-band;
bastion__approveis not advertised and a client call to it is refused.
Key | Type | Default | Description |
| map | — | Upstream servers to proxy (required, at least one). |
| string | — | Executable to launch (e.g. |
| string[] |
| Arguments to |
| map | — | Env overrides merged over the process env. |
| string | — | Working directory for the spawned process. |
| boolean |
| Auto-reconnect after an unexpected disconnect. |
| number |
| Max attempts before giving up ( |
| number |
| Initial backoff, doubled each attempt. |
| number |
| Backoff ceiling. |
| boolean |
| Enable periodic liveness probing. |
| number |
| Interval between probes. |
| number |
| Per-probe timeout. |
|
|
| How upstream tool names are exposed. |
| string |
| Separator used by the |
| boolean |
| Pin tool definitions and detect later changes. |
|
|
| Action when a pinned tool's definition changed. |
| boolean |
| Run poisoning heuristics on tool descriptions. |
|
|
| Action on a high-severity poisoning finding. |
| boolean |
| Record an audit event for every tool call. |
|
|
| How tool arguments are recorded. |
| boolean |
| Hash-chain events so tampering is detectable. |
| array | console | Destinations: |
|
|
| Local subprocess or remote endpoint. |
| string | — | Remote MCP URL (required for |
| map | — | Headers for |
|
|
| Serve Bastion over stdio or Streamable HTTP. |
| string / number |
| Bind address for |
| boolean |
| Reject |
| number (ms) |
| Ceiling on upstream |
|
|
| Era negotiation per upstream (probe 2026-07-28, fall back; or pin). |
|
|
| Serve pre-2026-07-28 clients statelessly, or refuse them ( |
| boolean |
| Gate |
|
|
| Action on a high-severity MRTR finding ( |
| string (≥16) | random per process | HMAC key sealing |
| number |
| Lifetime of a sealed |
Bastion runs on the MCP TypeScript SDK 2.0 and speaks both protocol eras — the stateless
2026-07-28 revision and the pre-2026 initialize handshake — on both faces, per upstream and per
client. When the protocol is stateless, the gateway is the only component that can still hold security
state, which is why v1.0 adds requestState custody and an input_required consent gate (see
CHANGELOG.md).
Bastion speaks two transports on both faces:
stdio (default) — the client spawns Bastion, and Bastion spawns local servers.
Streamable HTTP — connect to remote MCP servers (servers.<name> with transport: "http",
a url, and optional auth headers), and/or serve Bastion over HTTP to multiple/remote clients
(listen.mode: "http", or --http <port>).
HTTP upstreams configured without an authentication header are flagged (authenticated: false) in
bastion__status and warned at connect time.
New in v0.2. Bastion adds a security layer in the tool-call path (an interceptor pipeline), enabled by default:
Rug-pull detection (tool pinning). Each tool's definition is pinned on first use. If a server
later changes that definition, the tool is blocked (onRugPull: "block") until an operator reviews it
and re-approves it out-of-band (operator-only — not an agent-callable tool). This catches a server that
looks benign at install time and turns malicious afterward.
Poisoning inspection. Tool names and descriptions are scanned for manipulation heuristics
(instruction override, secret access, data exfiltration, covert instructions, embedded directives,
hidden/zero-width characters). Because heuristics can false-positive, the default is warn (logged
and reported, not blocked); set onPoisoning: "block" to enforce.
Shadowing. When two servers expose a tool with the same name, it's surfaced in the report.
Review everything with the bastion__security tool. These checks apply to local stdio servers today;
authentication checks for remote servers arrive with HTTP transport support.
New in v0.3, opt-in. Enable audit to record a structured, versioned event for every tool call —
including calls blocked by the security layer:
"audit": {
"enabled": true,
"includeArgs": "redacted", // none | redacted | full
"tamperEvident": true, // integrity hash-chain (detects naive edits; unkeyed, not signed)
"sinks": [
{ "type": "file", "path": "./bastion-audit.jsonl" },
{ "type": "webhook", "url": "https://collector.example/v1/audit" }
]
}Pluggable sinks. console (stderr JSONL), file (JSONL append), webhook (batched POST), and
otlp (native OpenTelemetry logs export — point it at an OTel Collector to fan out to any SIEM/cloud
backend). The sink interface makes new destinations additive.
Compliance mapping. Each event is mapped to NIST AI RMF functions and OWASP LLM Top 10
categories; bastion__compliance returns an aggregate report of recent activity.
Integrity hash chain. With tamperEvident, events are linked by a SHA-256 hash chain, and the
exported verifyChain helper detects naive or partial edits within an intact log. The chain is
unkeyed: a party who can rewrite the log file can recompute a consistent chain, and truncating the
most-recent events links cleanly — so treat this as corruption-detection, not cryptographic
tamper-proofing. For stronger guarantees, ship events to an append-only external sink (webhook / OTLP →
a WORM store or SIEM). Keyed/signed attestation is on the roadmap.
Redaction (best-effort). Arguments are omitted by default; includeArgs: "redacted" keeps structure
while masking values under known credential key-names and common secret patterns. It is a heuristic, not
a guarantee — a secret under an unrecognized key can still be recorded, so prefer none for
high-sensitivity deployments.
Every security check maps to recognized frameworks — the NIST AI Risk Management Framework (a U.S. federal standard), the OWASP Top 10 for LLM (2025) and Agentic (2026) Applications, and STRIDE. The full per-check mapping (with reference links to the MCP-security literature the checks are drawn from) is in docs/CHECKS-MAPPING.md.
Coverage is measured independently — bastion is scored against a 22-vector attack surface by the vendor-neutral mcp-defense-bench benchmark, with a public leaderboard and framework mapping.
The steps are identical for every client — only the config file location differs:
Client | Where to add the |
Claude Code | project |
Cursor |
|
Claude Desktop |
|
Cline |
|
Windsurf |
|
Gradual adoption: you don't have to route every server through Bastion — put only your flaky or untrusted servers behind it and leave the rest connected directly.
Bastion is organized into clear layers with a one-directional dependency flow, so each concern is independently testable and easy to evolve:
src/
├── cli.ts # thin CLI entrypoint (parse → wire → serve)
├── index.ts # public library API
├── errors.ts # error hierarchy (BastionError, …)
├── config/ # schema (Zod) + loader
├── core/ # domain: upstream connection lifecycle, aggregation & routing
├── proxy/ # client-facing MCP server + control tools
├── observability/ # logging (audit sinks in v0.3)
└── internal/ # small cross-cutting utilitiesDesign details — including the client-agnostic rationale, the interceptor pipeline, and the audit-sink strategy — live in the project's design docs.
npm install
npm run check # format:check + lint + typecheck + test (the full gate)
npm test # unit + end-to-end (in-memory transport) tests
npm run build # bundle to dist/ (CLI + library)
npm run dev -- --config bastion.config.jsonScript | Does |
| Bundle CLI + library with |
| Run the CLI from source with |
|
|
| ESLint (flat config). |
| Prettier. |
| Vitest. |
| Everything above, as one gate. |
Version | Theme | Highlights |
v0.1 ✅ | Reliability | Aggregating proxy, auto-reconnect, |
v0.2 ✅ | Runtime security | Tool-definition pinning (rug-pull detection), poisoning inspection, shadowing detection. |
v0.3 ✅ | Audit & compliance | Pluggable audit sinks (console / file / webhook), NIST AI RMF / OWASP LLM Top 10 mapping. |
Both stdio and Streamable HTTP transports are supported (see Transports).
Contributions are very welcome — this project is built to be community-owned. Please read CONTRIBUTING.md for the dev setup, project layout, and PR workflow, and our Code of Conduct.
In short: open an issue for non-trivial changes, keep PRs focused with tests, and make sure
npm run check passes (CI runs it on Node 18/20/22). Good first areas: additional client setup
recipes, more upstream test fixtures, and Streamable HTTP transport support.
mcp-bastion is security-adjacent software, so we hold it to a high bar. Please report
vulnerabilities privately — do not open a public issue. See SECURITY.md for
the disclosure process.
Apache-2.0 © Gowthaman Arumugam and mcp-bastion contributors
Report an audit/compliance summary of recent tool activity, mapped to governance frameworks (NIST AI RMF functions and OWASP LLM Top 10 categories). Requires audit to be enabled.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It mentions the output is a summary mapped to frameworks, but does not disclose whether the tool is read-only, any side effects, authentication needs, or rate limits. The behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It conveys the purpose, mapping, and prerequisite efficiently, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is fairly complete. It states what the tool does and a key requirement. However, it lacks detail on what 'recent tool activity' means or the format of the summary, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty schema). Per guidelines, baseline is 4. The description adds no parameter info, which is acceptable given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports an audit/compliance summary of recent tool activity, mapped to specific governance frameworks (NIST AI RMF and OWASP LLM Top 10). It distinguishes from the sibling 'bastion__approve' by focusing on compliance reporting rather than approval actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that audit must be enabled, providing a clear prerequisite. It implies when to use (when an audit summary is needed), but does not explicitly state when not to use or list alternatives beyond the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attempt to reconnect a disconnected or failed MCP server by name. Use this after bastion status shows a server is not connected, to restore its tools without human intervention.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | Name of the upstream server to reconnect (as shown by bastion status). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully signals that success is not guaranteed ('attempt') and frames itself as a no-human-intervention recovery path, but does not disclose failure modes, timeout/retry behavior, or any side effects on existing tool state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with zero filler, front-loading the core action before the usage condition. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter recovery tool with no output schema, the definition covers action, trigger, and actor. It could say more about what happens on failure (since 'attempt' implies a possible negative result), but the essentials for correct invocation are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'server' parameter is already documented as the upstream server name shown by bastion status. The description's 'by name' adds no information beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('reconnect a disconnected or failed MCP server') with the scoping constraint 'by name'. It is clearly distinguishable from sibling tools bastion__status, bastion__security, and bastion__compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the trigger condition ('after bastion status shows a server is not connected') and the goal ('restore its tools without human intervention'), which routes the agent correctly from the status sibling into this one. No alternatives are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the security state of every proxied tool: whether its definition matches what was first approved (or changed — a possible 'rug pull'), any poisoning heuristics its description triggered, and whether another server exposes a tool with the same name (shadowing).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningfully: it explains that it detects definition drift ('rug pull'), poisoning heuristics, and cross-server shadowing — real behavioral content rather than a restatement of the name. It stops short of stating that it is strictly read-only and non-mutating, which would have closed the loop.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with a colon introducing the three report categories — dense but readable, and no filler. The nested parenthetical asides make it slightly clunky, but every clause maps to a distinct output dimension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey what the agent receives; it does so by naming the three classes of findings. It does not describe the shape or granularity of the result (per-tool entries, severity levels, empty-state behavior), leaving a modest gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; per the baseline this lands at 4. No parameter-related omissions exist to penalize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Report') and a precise resource ('the security state of every proxied tool'), then enumerates the three findings it produces: definition drift/rug pull, poisoning heuristics, and name shadowing. This is clearly distinguishable from siblings like bastion__status and bastion__compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The security-audit framing implies when to call it, but there is no explicit guidance on when to prefer it over bastion__status or bastion__compliance, nor any stated preconditions (e.g. must tools be proxied already). Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the health of every MCP server proxied by Bastion: which are connected, disconnected, reconnecting, or failed; how many tools each exposes; and the last error. Call this when a tool seems to be missing or a server may have dropped mid-session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose what the call returns: per-server connection state, exposed tool count, and the last error. Because there is no output schema, this return-content disclosure is valuable. It stops short of stating read-only/safety semantics or cost, but the verb 'Report' plus the diagnostic payload makes the non-mutating nature clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the first front-loads what is reported and the second front-loads when to call it. Nothing repeats the name or restates structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param diagnostic with no annotations and no output schema, the description supplies both the return payload shape and the invocation trigger, which is most of what an agent needs. Minor gaps remain: it never explicitly confirms the operation is read-only or notes any auth/rate-limit constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly does not invent argument semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Report) and resource (health of every MCP server proxied by Bastion) and enumerates the exact statuses returned: connected, disconnected, reconnecting, failed. It is unmistakably distinct from siblings like bastion__reconnect, bastion__security, and bastion__compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete trigger: 'Call this when a tool seems to be missing or a server may have dropped mid-session.' That is clear when-to-use guidance, but it names no when-not condition or explicit alternative (e.g. reconnect) for the agent to route between.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bastion__approvebastion__reconnectbastion__securitybastion__statusv0.6.3bastion__approvebastion__complianceScored across 4 tools
Each tool has a clearly distinct purpose: status reports server connectivity health, reconnect performs a remediation action, security reports tool definition integrity and poisoning, and compliance provides audit reporting. There is no overlap in the problems they solve.
All tools use a consistent `bastion__` prefix and lowercase snake_case, which is predictable. The only minor deviation is that three names are nouns (status, security, compliance) while one is a verb (reconnect), but this does not impede understanding.
Four tools is well-scoped for a monitoring and management proxy. Each tool earns its place by addressing a distinct concern: health, remediation, security, and compliance, with no redundant or missing basics.
Core monitoring and reconnection are covered, and security/compliance reporting is present. However, there is no way to act on security findings (e.g., re-approve a changed tool definition or block a poisoned one) and no explicit server configuration management, which are minor gaps agents can work around.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
