mcp-bastion
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bastion__status | 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. |
| bastion__reconnect | 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. |
| bastion__security | 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). |
| bastion__approveA | Re-approve a tool whose definition changed, clearing a rug-pull block so it can be called again. Only do this after reviewing and trusting the change. |
| bastion__complianceA | 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. |
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 serve completely distinct purposes: one for re-approving changed tools to prevent rug-pull, the other for reporting audit/compliance summaries. There is no overlap or ambiguity.
Both tools follow a consistent 'bastion__<verb>' naming pattern (bastion__approve, bastion__compliance), making the action clear and predictable.
With only 2 tools, the server feels slightly thin, but for a focused governance purpose (rug-pull prevention and compliance reporting), the count is reasonable and not inappropriate.
The tools cover the core functions: approving changed tools and reporting compliance. Minor gaps exist, such as listing pending approvals or configuring audit settings, but the surface is adequate for the stated purpose.