Sentinel Gateway
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 |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": true,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sentinel_register_serverB | Register a new downstream MCP server with Sentinel Gateway. The gateway will discover all tools, fingerprint their descriptions, and begin monitoring for drift. |
| sentinel_list_serversB | List all registered downstream MCP servers and their connection status. |
| sentinel_list_toolsB | List all discovered tools across all registered servers, with their fingerprint status and trust level. |
| sentinel_setup_demoA | Quick setup: Register all 3 demo mock servers (filesystem, CRM, email) with the gateway in one step. Useful for demo initialization. |
| sentinel_add_policy_ruleB | Grant an agent access to a specific tool on a specific server. Use toolName="*" to grant access to all tools on that server. |
| sentinel_remove_policy_ruleA | Revoke an agent's access to a specific tool. |
| sentinel_list_policy_rulesB | List all RBAC policy rules. Optionally filter by agent ID. |
| sentinel_check_agent_accessB | Test whether a specific agent is allowed to call a specific tool. Returns the policy decision and reason. |
| sentinel_setup_demo_policiesA | Quick setup: Create demo RBAC policies for demonstration. Grants "sales-bot" access to CRM and email, "data-analyst" access to filesystem, and leaves "rogue-agent" with no access. |
| sentinel_call_toolB | Route a tool call through Sentinel Gateway's security pipeline. The gateway verifies tool integrity (fingerprint check), enforces RBAC policy, logs to the provenance ledger, and only then forwards the call to the downstream MCP server. |
| sentinel_query_ledgerB | Search and filter the provenance ledger. Returns cryptographically linked entries with hash-chain validation. |
| sentinel_verify_chain_integrityA | Verify the cryptographic integrity of the entire provenance ledger. Each entry is hash-chained to the previous one — if any entry has been tampered with, this check will detect it. |
| sentinel_get_dashboard_statsB | Get summary statistics for the Sentinel Gateway dashboard — total calls, blocks, drift detections, chain status. |
| sentinel_get_call_historyB | Get recent tool call history through the gateway, with status and timing information. |
| sentinel_get_review_queueA | Get all items in the human review queue. Shows pending drift detections, injection flags, and policy violations that need human approval. |
| sentinel_approve_reviewB | Approve a review item. For drift detections, this re-pins the tool fingerprint with the new description. For injection flags, this allows the call to proceed. |
| sentinel_deny_reviewA | Deny a review item. The block remains active — the flagged tool/call stays blocked. |
| sentinel_run_attackC | Run a simulated attack scenario to demonstrate Sentinel Gateway's security capabilities. Scenarios: tool_poisoning (rewrites a tool description), rbac_violation (unauthorized agent call), ledger_tampering (modifies a ledger entry), description_injection (hidden instructions in tool description). |
| sentinel_reset_demoA | Reset all mock servers to their original, clean state after running attack simulations. |
| sentinel_run_full_demoB | Run the complete demo sequence: setup servers → configure policies → normal traffic → tool poisoning attack → RBAC violation. Shows the full security pipeline in action. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Health Checks | Current health status of all registered health checks |
| Server Topology | UI component for Server Topology |
| Ledger Viewer | UI component for Ledger Viewer |
| Dashboard Stats | UI component for Dashboard Stats |
| Review Queue | UI component for Review Queue |
| Attack Demo | UI component for Attack Demo |
| Widget Examples | Provides metadata and examples for all registered UI widgets |
TDQS
Scored across 20 tools
Tools are largely distinct, each targeting a specific operation: registration, RBAC policies, ledger queries, review queue, demo setup, attacks. However, sentinel_call_tool, sentinel_get_call_history, and sentinel_run_full_demo have some conceptual overlap (all involve executing calls), and the demo/attack/reset tools blur boundaries for agents trying to pick between setup, run, and attack flows.
All tools follow a consistent sentinel_[verb]_[noun] pattern with snake_case throughout, which is excellent. Minor inconsistency exists with get_dashboard_stats vs get_call_history (both use 'get') and the setup tools using 'setup' vs 'run' verbs that could be more uniform, but the pattern is strongly predictable overall.
At 20 tools, this sits at the upper edge of the acceptable range. The core security pipeline (register, list, policy, call, ledger, review) is about 12 tools, but the demo helpers (setup_demo, setup_demo_policies, run_full_demo, reset_demo, run_attack) add 5 tools that are more for demonstration than real operation, inflating the count beyond what a production gateway would need.
The surface covers the full security workflow: server registration, RBAC management, call routing, ledger querying/integrity, review queue with approve/deny, and attack simulation. Minor gaps include no tool to unregister/remove a server, and no tool to view all agents' detailed permissions in one place, but the core lifecycle is largely complete.