Ops Guard MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPS_GUARD_CONFIG | Yes | Path to the Ops Guard configuration file (TOML). | |
| OPS_GUARD_APPROVAL_SECRET | Yes | Secret used for approval request signing/HMAC. | |
| OPS_GUARD_AGENT_SECRET_LOCAL | Yes | Local agent secret for HMAC verification. | |
| OPS_GUARD_DINGTALK_CLIENT_ID | No | DingTalk application client ID (AppKey). | |
| OPS_GUARD_HERMES_BRIDGE_SECRET | No | Shared secret for HMAC signing between Hermes DingTalk adapter and Ops Guard (used when callback_owner=hermes). | |
| OPS_GUARD_DINGTALK_CLIENT_SECRET | No | DingTalk application client secret (AppSecret). |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ops_list_hostsB | List server targets and their non-secret security posture. |
| ops_run_commandA | Submit a structured argv command. Known read-only diagnostics may run automatically. Mutations require external approval. Unknown commands, shell/interpreter launchers, pipelines, and escape primitives are denied. Approval routing is not model-controlled. DingTalk delivery targets come from administrator configuration (or a trusted integration path outside the MCP tool schema). |
| ops_stage_scriptA | Stage immutable script content and create an exact-SHA256 approval request. Scripts are disabled by default on production hosts. When enabled, every script is treated as arbitrary privileged code and never auto-approved. |
| ops_request_statusC | Get approval and execution status for a request. |
| ops_pending_approvalsB | List requests waiting for human approval. |
| ops_execute_approvedB | Execute a request only if the immutable digest has already been approved. Calling this tool cannot bypass approval. The SQLite state transition, exact digest, expiration, and remote agent nonce/signature are checked again. |
| ops_audit_tailB | Read recent redacted, hash-chained audit records. |
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 7 tools
Each tool targets a distinct operation: host listing, command submission, script staging, request status lookup, pending approval listing, approved execution, and audit reading. Although command and script submission both initiate approval flows, their artifact types and lifecycle stages are clearly separated.
All tools use the ops_ prefix and snake_case, which is highly consistent. Some names are verb_noun (ops_list_hosts, ops_run_command) while others are noun phrases (ops_pending_approvals, ops_audit_tail), but the pattern remains readable.
Seven tools are well-scoped for a guarded remote execution service with approval and audit requirements. Each tool clearly earns its place without redundancy or excessive breadth.
The surface covers host discovery, command/script submission, approval status, pending approvals, approved execution, and audit history. Minor gaps exist, such as no explicit cancel or revoke operation for pending requests, but core workflows are supported.