Skip to main content
Glama
opsecforge-mcp

opsecforge-mcp

OpsecForge

OpsecForge is a Next.js site for privacy-first developer and security utilities. Its core product boundary is simple: values pasted into a tool are processed in the loaded browser page, not sent to an OpsecForge tool-processing backend.

MCP server for coding agents: opsecforge-mcp

This repository also contains a local Model Context Protocol (MCP) server in packages/opsecforge-mcp. It runs over stdio, is built with the official MCP TypeScript SDK (@modelcontextprotocol/sdk), and reuses the same tested code in lib/ that powers the browser tools. It makes no network requests.

The agent passes a file path or an environment variable name; the work happens on your machine and only redacted or derived results reach the model. MCP tools:

  • redact_file: read a local text file and return it with secrets replaced by [REDACTED], plus a findings summary.

  • scan_secrets: pre-commit check of files, directories or staged changes; returns file:line and the secret type, never the value.

  • redact_text, verify_webhook, inspect_jwt, file_checksum.

Install from npm (opsecforge-mcp, MIT; official MCP Registry name io.github.cyberdroid2077/opsecforge):

claude mcp add opsecforge -- npx -y opsecforge-mcp

Redaction is heuristic. Setup for Codex, Cursor and the Claude Code plugin (with a guard hook), plus the full limitations, is in the package README and at opsecforge.com/agents.

Related MCP server: ctxbleach

Privacy and analytics boundary

  • Tool inputs and generated outputs are not sent to OpsecForge analytics.

  • The public site uses aggregate Vercel Web Analytics for page-view measurement.

  • The site may load advertising resources.

  • Browser-local processing reduces an upload path; it does not make tool output correct, safe, or compliant by itself.

  • Each security-sensitive tool should state its limitations and require appropriate human review.

Never add logging, storage, analytics, error reporting, or network calls that can contain tool input, secrets, tokens, signatures, or generated credentials.

Tools

Try a real workflow

  • Compare a file checksum: select a file up to 8 GiB, calculate SHA-256 or SHA-512, and compare it with a trusted publisher's digest or SHA256SUMS line. No file upload. A match does not prove the file is safe or authenticate its publisher.

  • Sanitize a configuration before sharing: mask likely secrets in synthetic test data first. Detection is heuristic; review all output.

  • Check a webhook signature: compare supplied GitHub, Stripe, or generic HMAC fixtures. Matching supplied values does not replace a production receiver's replay controls.

For a reproducible checksum demo, create a text file containing exactly abc with no newline. Its SHA-256 is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Change one byte and the digest changes. File names, bytes, and digests are not included in analytics. Campaign labels on the public README link describe the distribution channel only.

The /tools hub groups the current utilities into:

  • Encoding and formatting

  • Credentials and security

  • Debugging and validation

The catalog is defined in lib/tool-catalog.ts. Preserve existing public tool URLs unless a reviewed redirect or canonical migration is part of the change.

Development

Requirements: a current Node.js release compatible with the lockfile and npm.

npm install
npm run dev

Before publishing:

npm run typecheck
npm test
npm run content:verify
npm run build

The production build runs content-source verification through prebuild.

Content and security boundaries

  • Use primary or authoritative sources for incident details, vulnerability status, statistics, standards, and vendor behavior.

  • Do not invent incidents, identities, credentials, measurements, reviews, certifications, or compliance claims.

  • Use synthetic fixtures in tests and documentation. Never commit real secrets, production payloads, or customer data.

  • Keep defensive tools browser-local. Do not add remote scanners, proxy behavior, or requests to user-supplied URLs.

  • Do not weaken the visible limitations of heuristic tools such as secret redaction.

Governance

  • Product Charter: the authoritative, stable product and operating constitution.

  • Operations Log: the chronological record of verified facts, deployments, experiments, measurements, risks, and decisions.

  • Current growth plan: dated experiments, distribution work, measurable decisions, and outstanding access needs.

When documentation conflicts, follow the hierarchy in the Product Charter and verify behavior against current code and production.

Contributing

Keep changes focused and preserve unrelated work. For a proposed feature or material behavior change, start with an issue describing the user need, privacy boundary, evidence, and test plan. Security reports should use the contact method published on the live site and must not include active credentials or unnecessary sensitive data.

Deployment, analytics access, active experiments, and operating decisions are recorded in the Operations Log.

Available Tools

6 tools
file_checksumCompute and compare a file checksumA
Read-onlyIdempotent

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.

Inputs: path (required), algorithm (required), expected.

inspect_jwtDecode a JWT and flag risksA
Read-onlyIdempotent

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 token is already in the context. The claims returned are in the model context either way.

Inputs: token, token_env.

redact_fileRedact a local fileA
Read-onlyIdempotent

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.

Inputs: path (required).

redact_textRedact text already in contextA
Read-onlyIdempotent

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.

Inputs: text (required).

scan_secretsScan files or staged changes for secretsA
Read-onlyIdempotent

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.

Inputs: paths, staged.

verify_webhookVerify a webhook signature offlineA
Read-onlyIdempotent

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.

Inputs: provider (required), body_path (required), signature (required), secret_env (required), +2 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.4/5.0

    Scored across 6 tools

    Disambiguation4/5

    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.

    Naming Consistency4/5

    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.

    Tool Count5/5

    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.

    Completeness4/5

    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.

    Maintenance

    ActivityActive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • F
      license
      Not graded
      quality
      D
      maintenance
      Local MCP server that scans code for security issues (secrets, dependencies, configurations, risky patterns) and integrates with GitHub Copilot in VS Code for automated pre-commit reviews.
      -
    • A
      license
      Not graded
      quality
      C
      maintenance
      Local CLI and MCP server that redacts secrets from logs, files, and diffs before sending them to AI agents, with stable placeholders and token-budgeted truncation.
      MIT
    • A
      license
      Not graded
      quality
      F
      maintenance
      Local stdio MCP server for working on Intern-hosted sites through guarded Git checkouts. It enables authentication, site preparation, testing, validation, and publishing via coding harnesses like Codex and Claude Code.
      10 npm
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      Local MCP server for AI agents and vibe coding safety: deterministic risk checks (payments, auth, database, secrets, infrastructure), sessions, checkpoints, policy inspection, and fix prompts. Runs over stdio against a local git repository; no language model judges risk.
      8
      Apache 2.0