This server provides file system operations, web search, and application deployment functionality through a protected MCP gateway.
Read File: Read the contents of a file by specifying its path
Write File: Write or overwrite content to a file at a specified path
Delete File: Permanently remove a file from the filesystem by path
Web Search: Search the internet for information using a query string
Deploy: Deploy applications to staging or production environments, with an optional deployment reason
All operations are enhanced by the protect-mcp gateway, which adds shadow logging, policy enforcement (block, rate limit, tier requirements), signed audit trails (Ed25519), and support for external policy engines (OPA, Cerbos, Cedar, HTTP endpoints).
Provides specialized security policy packs to protect against prompt injection and malicious tool abuse within GitHub-integrated agent workflows.
Enables safety guardrails and enforcement policies for infrastructure-as-code tools, preventing autonomous agents from executing destructive commands like unauthorized production deletions.
⚠️ This repository has moved. Active development continues at ScopeBlind/scopeblind-gateway.
This personal fork may be behind the canonical repository. Please use the org repo for issues, pull requests, and the latest code.
Security gateway for MCP servers. Shadow-mode logs by default, per-tool policies, optional local Ed25519 receipts, and verification-friendly audit output.
Current CLI path: wrap any stdio MCP server as a transparent proxy. In shadow mode it logs every tools/call request and allows everything through. Add a policy file to enforce per-tool rules. Run protect-mcp init to generate local signing keys and config so the gateway can also emit signed receipts.
# Wrap an existing OpenClaw / MCP config into a usable pack
npx @scopeblind/passport wrap --runtime openclaw --config ./openclaw.json --policy email-safe
# Shadow mode — log every tool call, enforce nothing
npx protect-mcp -- node my-server.js
# Generate keys + config template for local signing
npx protect-mcp init
# Shadow mode with local signing enabled
npx protect-mcp --policy protect-mcp.json -- node my-server.js
# Enforce mode
npx protect-mcp --policy protect-mcp.json --enforce -- node my-server.js
# Export an offline-verifiable audit bundle
npx protect-mcp bundle --output audit.jsonRelated MCP server: protect-mcp
protect-mcp sits between your MCP client and server as a stdio proxy:
MCP Client ←stdin/stdout→ protect-mcp ←stdin/stdout→ your MCP serverIt intercepts tools/call JSON-RPC requests and:
Shadow mode (default): logs every tool call and allows everything through
Enforce mode: applies per-tool policy rules such as block, rate_limit, and min_tier
Optional local signing: when signing is configured, emits an Ed25519-signed receipt alongside the structured log
All other MCP messages (initialize, tools/list, notifications) pass through transparently.
Per-tool policies — block destructive tools, rate-limit expensive ones, and attach minimum-tier requirements
Structured decision logs — every decision is emitted to stderr with [PROTECT_MCP]
Optional local signed receipts — generated when you run with a policy containing signing.key_path, persisted to .protect-mcp-receipts.jsonl, and exposed at http://127.0.0.1:9876/receipts
Offline verification — verify receipts or bundles with npx @veritasacta/verify
No account required — local keys, local policy, local process
These are important before you roll this out or talk to users:
Signing is not automatic on the bare npx protect-mcp -- ... path. That path logs decisions in shadow mode. For local signing, run npx protect-mcp init and then start the gateway with the generated policy file.
Tier-aware policy checks are live, but manifest admission is not wired into the default CLI/stdio path. The CLI defaults sessions to unknown unless a host integration calls the admission API programmatically.
Credential config currently validates env-backed credential references and records credential labels in logs/receipts. Generic per-call injection into arbitrary stdio tools is adapter-specific and is not performed by the default proxy path.
External PDP adapters and audit bundle helpers exist as exported utilities. They are not yet fully wired into the default CLI path.
{
"default_tier": "unknown",
"tools": {
"dangerous_tool": { "block": true },
"admin_tool": { "min_tier": "signed-known", "rate_limit": "5/hour" },
"read_tool": { "require": "any", "rate_limit": "100/hour" },
"*": { "rate_limit": "500/hour" }
},
"signing": {
"key_path": "./keys/gateway.json",
"issuer": "protect-mcp",
"enabled": true
},
"credentials": {
"internal_api": {
"inject": "env",
"name": "INTERNAL_API_KEY",
"value_env": "INTERNAL_API_KEY"
}
}
}Field | Values | Description |
|
| Explicitly block this tool |
|
| Basic access requirement |
|
| Minimum tier required if your host sets admission state |
|
| Rate limit (e.g. |
Tool names match exactly, with "*" as a wildcard fallback.
Add to claude_desktop_config.json:
{
"mcpServers": {
"my-protected-server": {
"command": "npx",
"args": [
"-y", "protect-mcp",
"--policy", "/path/to/protect-mcp.json",
"--enforce",
"--", "node", "my-server.js"
]
}
}
}Same pattern — replace the server command with protect-mcp wrapping it.
protect-mcp [options] -- <command> [args...]
protect-mcp init
Commands:
init Generate Ed25519 keypair + config template
status Show decision stats and local passport identity
digest Generate a local human-readable summary
receipts Show recent persisted signed receipts
bundle Export an offline-verifiable audit bundle
Options:
--policy <path> Policy/config JSON file
--slug <slug> Service identifier for logs/receipts
--enforce Enable enforcement mode (default: shadow)
--verbose Enable debug logging
--help Show helpThe library also exposes the primitives that are not yet wired into the default CLI path:
import {
ProtectGateway,
loadPolicy,
evaluateTier,
meetsMinTier,
resolveCredential,
initSigning,
signDecision,
queryExternalPDP,
buildDecisionContext,
createAuditBundle,
} from 'protect-mcp';Use these if you want to add:
manifest admission before a session starts
an external PDP (OPA, Cerbos, or a generic HTTP webhook)
custom credential-brokered integrations
audit bundle export around your own receipt store
Every tool call emits structured JSON to stderr:
[PROTECT_MCP] {"v":2,"tool":"read_file","decision":"allow","reason_code":"observe_mode","policy_digest":"none","mode":"shadow","timestamp":1710000000}When signing is configured, a signed receipt follows:
[PROTECT_MCP_RECEIPT] {"v":2,"type":"decision_receipt","algorithm":"ed25519","kid":"...","issuer":"protect-mcp","issued_at":"2026-03-22T00:00:00Z","payload":{"tool":"read_file","decision":"allow","policy_digest":"...","mode":"shadow","request_id":"..."},"signature":"..."}Verify with the CLI: npx @veritasacta/verify receipt.json
Verify in browser: scopeblind.com/verify
The package exports a helper for self-contained audit bundles:
{
"format": "scopeblind:audit-bundle",
"version": 1,
"tenant": "my-service",
"receipts": ["..."],
"verification": {
"algorithm": "ed25519",
"signing_keys": ["..."]
}
}Use createAuditBundle() around your own collected signed receipts.
Shadow first. See what agents are doing before you enforce anything.
Receipts beat dashboard-only logs. Signed artifacts should be independently verifiable.
Keep the claims tight. The default CLI path does not yet do everything the long-term architecture will support.
Layer on top of existing auth. Don't rip out your stack just to add control and evidence.
Ship with protect-mcp — each prevents a real attack:
Policy | Incident | OWASP Categories |
| CVE-2025-6514: MCP OAuth proxy hijack (437K environments) | A01, A03 |
| Autonomous Terraform agent destroys production | A05, A06 |
| Prompt injection via crafted GitHub issue | A01, A02, A03 |
| Agent data theft via outbound tool abuse | A02, A04 |
| Unauthorized financial transaction | A05, A06 |
npx protect-mcp --policy node_modules/protect-mcp/policies/clinejection.json -- node server.jsFull OWASP Agentic Top 10 mapping: scopeblind.com/docs/owasp
Supports OPA, Cerbos, Cedar (AWS AgentCore), and generic HTTP endpoints:
{
"policy_engine": "hybrid",
"external": {
"endpoint": "http://localhost:8181/v1/data/mcp/allow",
"format": "cedar",
"timeout_ms": 200,
"fallback": "deny"
}
}IETF Internet-Draft: draft-farley-acta-signed-receipts-00 — Signed Decision Receipts for Machine-to-Machine Access Control
Patent Status: 4 Australian provisional patents pending (2025-2026) covering decision receipts with configurable disclosure, tool-calling gateway, agent manifests, and portable identity
Verification: MIT-licensed — npx @veritasacta/verify --self-test
MIT — free to use, modify, distribute, and build upon without restriction.
scopeblind.com · npm · GitHub · IETF Draft
Delete a file from the filesystem
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose that deletion is irreversible or mention behavior for missing paths or directories, which is critical for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but could be improved by including context about irreversibility without significant length increase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema or annotations, the description lacks completeness: no mention of return values, errors, or required permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description 'File path to delete' is already clear; the description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'file from the filesystem', distinguishing it from sibling tools like read_file (read) and write_file (write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy the application to production
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Deployment reason | |
| environment | Yes | Target environment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose behavioral traits like destructiveness, auth requirements, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (5 words), but underspecified – conciseness should not sacrifice necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not explain return values, side effects, or deployment process outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. Description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'deploy the application to production' – clear verb and resource, but slightly misleading as schema allows staging also. No confusion with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or when-not-to-use mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a file
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions reading without specifying encoding, size limits, existence requirements, or return format, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single-sentence description that is front-loaded and efficient with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simplicity, description lacks details on return format, error handling, and behavioral constraints, which are critical for an agent invoking a file read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'path' described as 'File path to read'; description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'read' and resource 'contents of a file', distinguishing it from sibling tools like write_file and delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; usage is implied by the name and description but lacks context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web for information
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks details on behavior such as rate limits, result format, or limitations, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but fails to include necessary details, balancing brevity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the description does not adequately cover what the agent needs to know for successful use, such as result types or response details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'query' with a schema description, and the tool description adds no additional meaning beyond what the schema already provides; high schema coverage baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search the web for information' clearly states the verb and resource, and it distinguishes from siblings (file operations and deploy) which are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, and no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to a file
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path to write | |
| content | Yes | Content to write |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose important behavioral traits such as whether the file is overwritten, permissions required, or error handling. Without annotations, the description carries the full burden, and it is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, to-the-point sentence with no wasted words. It earns its place by conveying the core action concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple file write tool, the description lacks completeness. It does not mention return values, overwrite behavior, or any constraints, making it less useful for an AI agent to fully understand the tool's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the description adds no extra meaning. Baseline 3 is appropriate; the schema already documents path and content adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Write content to a file' clearly states the verb 'Write' and the resource 'content to a file', distinguishing it from sibling tools like read_file and delete_file. However, it does not specify whether it overwrites or appends, which would add more precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. An explicit mention of use cases or exclusions (e.g., when to use deploy instead) is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
delete_filedeployread_fileweb_searchwrite_fileEach tool targets a distinct action: file operations (delete, read, write), deployment, and web search. There is no overlap or ambiguity between them.
Most tools follow verb_noun pattern (delete_file, read_file, write_file, web_search), but 'deploy' lacks a noun, breaking the consistent pattern slightly.
5 tools is a reasonable count, but the mix of file management, deployment, and web search seems odd for a single server scope.
The tool set lacks obvious necessary operations for any single domain: e.g., no update for files, no environment or config for deployment, making it incomplete for a coherent purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tomjwxf/scopeblind-gateway'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
