opsecforge-mcp
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| redact_fileA | Reads a local text file on this machine and returns its content with secrets (API keys, tokens, passwords, private keys, connection-string credentials, JWTs, cookies) replaced by [REDACTED], plus a findings summary (type, count, line numbers). The original values are read inside the local MCP server process only and are never returned, so use this instead of Read or cat for .env files, config files, logs, key files and similar. Pass a path, not file contents. Only regular files are accepted (no directories, pipes or devices), up to 1 MiB, and binary files are refused. The response starts with a notice that the original values did not leave the machine or reach the model. Redaction is heuristic and can miss custom formats. |
| scan_secretsA | Pre-commit check. Scans files or directories (paths) and/or the lines added in the staged git diff (staged: true) for known secret patterns. Lists only file:line, the secret type and a masked preview (at most the first 4 characters of values of 20+ characters; short values are shown as an ellipsis), never the original value. Provide paths, staged, or both. Heuristic: a clean result is not proof that nothing sensitive is present. |
| redact_textA | Redacts secrets in text you ALREADY HAVE (for example before pasting logs into an issue, ticket, chat message or commit message) and returns the redacted copy with a findings summary. Honest limitation: the text you pass as the argument is already in the model context, and calling this tool does not remove it from there; it only produces a safer copy to share outward. To avoid putting a secret into the context at all, use redact_file with a path instead. Heuristic: can miss custom formats. |
| verify_webhookA | Verifies a GitHub, Stripe or generic HMAC webhook signature locally and explains why a mismatch happened. The signing secret is read ONLY from the environment variable named in secret_env; there is no parameter for a plaintext secret and one is rejected if supplied. The body is read as raw bytes from body_path. Returns match / no match plus diagnostics: whether the signature header is well-formed, whether the Stripe timestamp is outside the tolerance, whether the body looks reformatted (trailing newline, CRLF, re-serialized or pretty-printed JSON) and common secret mistakes (whitespace, wrong key type). It sends nothing over the network and never returns the secret or a computed signature. |
| inspect_jwtA | Decodes a JWT locally and returns its header, claims (field values whose names look like secrets are masked), time-claim status (exp, nbf, iat) and risk notes such as alg none, HMAC algorithms that cannot be verified offline, missing exp, and jku/jwk/x5u key-injection headers. DECODING IS NOT VERIFICATION: this tool has no key, never checks the signature and cannot tell you the token is genuine. Prefer token_env (the NAME of an environment variable) so the raw token does not pass through the model; a token passed as |
| file_checksumA | Computes the SHA-256 or SHA-512 digest of a local file (regular file, up to 32 MiB) and optionally compares it with an expected value. A match proves only that the file equals whatever the expected value was taken from, so it is only as trustworthy as the source of that value. |
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 6 tools
Each tool has a distinct action+target (redact text vs. file, verify webhook, inspect JWT, checksum, scan secrets). The only mild overlap is redact_file vs. scan_secrets, both reading local files for secrets, but descriptions clearly separate returning redacted content from reporting findings, so an agent can choose correctly.
Five tools follow a clean verb_noun pattern (redact_text, verify_webhook, inspect_jwt, redact_file, scan_secrets), with only file_checksum deviating into a noun_noun form. Minor inconsistency but overall predictable and readable.
Six focused tools is well-scoped for a security/opsec server, with each tool earning its place across redaction, verification, integrity, and scanning. No bloat or thinness.
The set covers the core opsec lifecycle: scanning, redacting (text and file), verifying webhooks/JWTs, and checksums. Minor gaps remain (e.g., no secret-detection over arbitrary in-context text without redaction, or config-driven allowlist management), but core workflows are complete.