Skip to main content
Glama
tonysheesh

MCP-Shield Pro

by tonysheesh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

🛡️ MCP-Shield Pro — Enterprise MCP Supply Chain & Runtime Governance Shield

MCP-Shield Pro Banner

Enterprise-grade zero-dependency security shield and runtime governance engine for Model Context Protocol (MCP) servers, AI agent tool pipelines, and AIBOM compliance.

⚡ Key Highlights & Core Capabilities

  • ⚡ Zero External Runtime Dependencies: Pure Node.js ES Module runtime delivering sub-millisecond execution (< 2ms) with zero third-party npm package overhead.

  • 🛡️ OWASP MCP Top 10 Security Audit: Automated static & dynamic code inspection covering unauthenticated endpoints, tool signature gaps, prompt injection, and command injection.

  • 🔐 Cryptographic Tool Call Signing: HMAC-SHA256 tool request signing and replay attack prevention for agent execution pipelines.

  • 📄 Standardized AIBOM Generator: Automated AI Bill of Materials (AIBOM) generation tracking component file hashes, tools, and security provenance.

  • 🧱 Inline Runtime Parameter Firewall: Intercepts tool parameters in real-time to block path traversal, shell metacharacters, SSRF, and adversarial injection patterns.

  • 🔌 Native MCP Protocol Server: Stdio JSON-RPC 2.0 interface exposing mcp_scan, generate_aibom, and mcp_verify tools directly to OpenClaw, Codex, Claude Code, and Cursor.

  • 🎨 Interactive Browser Studio Dashboard: Embedded single-file studio (demo/index.html) featuring live security gauges, OWASP rule status, and parameter firewall sandbox.

  • 🔄 Error-Resuming Auto-Installer: Executable ./install.sh with checkpoint tracking (.install_checkpoint) and ./install.sh --resume recovery.

Related MCP server: mcp-security-scanner

📐 System Architecture

MCP-Shield Pro Architecture

🛡️ OWASP MCP Top 10 Security Rule Coverage

Rule ID

Threat Category

Description

Severity

Safeguard Mechanism

MCP-01

🔑 Authentication

Unauthenticated Endpoint Exposure

🔴 HIGH

Bearer/HMAC Auth Verification

MCP-02

🔐 Integrity

Missing Cryptographic Tool Signatures

🔴 HIGH

ToolSigner HMAC-SHA256 Enforcer

MCP-03

🧠 AI Security

Indirect Prompt Injection Vulnerability

🟣 CRITICAL

Delimiter Boundary Sanitization

MCP-04

🛡️ Authorization

Excess Tool Privileges & Over-scoping

🟡 MEDIUM

Principle of Least Privilege Inspector

MCP-05

📦 Supply Chain

Untrusted Supply Chain Dependency

🔴 HIGH

AIBOM Provenance & Hash Verification

MCP-06

⚡ Execution

Arbitrary Command & Shell Injection

🟣 CRITICAL

RuntimeFirewall Parameter Sanitizer

MCP-07

📁 File System

Path Traversal & Traversal Escapes

🔴 HIGH

Workspace Root Path Containment

MCP-08

🌐 Network

Server-Side Request Forgery (SSRF)

🔴 HIGH

URL Host Domain Allowlisting

MCP-09

🔒 Privacy

Unbounded Context & Credential Leak

🔴 HIGH

Secret Regex & Pattern Scrubber

MCP-10

📝 Logging

Missing Audit Trail & Session Identity

🟡 MEDIUM

Structured JSON Audit Logger

🚀 Quick Start & Installation

1️⃣ Automatic Installation with Error Resume

# Clone and run the self-healing auto-installer
git clone https://github.com/tonysheesh/mcp-shield-pro.git
cd mcp-shield-pro
./install.sh

# If any step is interrupted, resume automatically:
./install.sh --resume

2️⃣ Running Security Audits via CLI

# Run OWASP MCP Top 10 security audit on current codebase
node bin/mcp-shield.js --scan .

# Generate AI Bill of Materials (AIBOM)
node bin/mcp-shield.js --aibom .

# Run strict Quality Approval Gate checks
node bin/mcp-shield.js --quality .

⚡ Comparison & Superiority

Feature / Metric

Legacy Scanners & Python Tools

MCP-Shield Pro

Runtime Dependencies

Heavy (pip packages, native C++)

0 External Dependencies (Pure Node ESM)

Audit Execution Speed

~1.5s - 3.2s per codebase

< 2ms per scan (150x Faster)

Tool Call Integrity

Plaintext JSON / Unsigned

HMAC-SHA256 Cryptographic Signatures

Supply Chain Governance

Manual SBOMs

Automated AI Bill of Materials (AIBOM)

Runtime Protection

Static Analysis Only

Inline Parameter Firewall Sandbox

IDE & Agent Integration

Manual CLI invocation

Native Stdio MCP JSON-RPC Server

Installer Resiliency

Standard script (fails on error)

Checkpoint State Tracking (--resume)

💻 Programmatic API Usage

import { MCPScanner, ToolSigner, RuntimeFirewall, AIBOMGenerator } from 'mcp-shield-pro';

// 1. Audit an MCP tool file
const scanner = new MCPScanner();
const audit = scanner.scanFile('./lib/mcpServer.js');
console.log(`Security Score: ${audit.score}/100 | Passed: ${audit.passed}`);

// 2. Cryptographically sign a tool call
const signer = new ToolSigner('your-master-secret-key');
const signedPayload = signer.signToolCall('query_database', { query: 'SELECT 1' });

// 3. Verify signature
const verification = signer.verifyToolCall(signedPayload);
console.log(`Signature Valid: ${verification.valid}`);

// 4. Runtime parameter firewall inspection
const firewall = new RuntimeFirewall();
const inspection = firewall.inspectParams('read_file', { path: '../../etc/passwd' });
console.log(`Allowed: ${inspection.allowed}`); // false

🗺️ Roadmap

  • Support for Ed25519 asymmetric public-key signature verification for decentralized tool execution.

  • Real-time eBPF syscall filtering integration for containerized agent workloads.

  • Automated OWASP MCP Top 10 rule auto-fixer (--fix) to patch vulnerabilities in-place.

  • Multi-region threat intelligence feed synchronization for emerging prompt injection patterns.

  • Browser Studio web assembly (WASM) compiler for client-side zero-server scanning.

📜 License

MIT License © 2026 tonysheesh

Available Tools

3 tools
generate_aibomC

Generate an AI Bill of Materials (AIBOM) conforming to AI supply chain governance standards.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesPath to target project

TDQS

C2.7/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'conforming to standards' but no side effects, output location, required project structure, or any other behavioral traits. This is a significant gap for a generation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core action and resource. There is no redundancy or fluff, but it omits essential behavioral details, leaving it slightly under-specified for such an important tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description should explain return values and side effects. It does not mention what the generated AIBOM contains, where it is written, or any prerequisites, making the tool behaviorally incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents the only parameter (projectPath) with a description, achieving 100% coverage. The tool description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies a specific verb ('Generate') and resource ('AI Bill of Materials'), and adds a compliance context ('conforming to AI supply chain governance standards'). However, it does not explicitly distinguish this tool from siblings mcp_scan and mcp_verify, so it misses full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states what the tool does, leaving the agent without decision context relative to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_scanA

Audit an MCP server, codebase, or configuration file against OWASP MCP Top 10 vulnerabilities.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesFile or directory path to audit

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full burden. It conveys that the tool performs an audit (implying non-destructive analysis) and takes a local path, but it doesn't explicitly state whether it is read-only, what side effects it might have, or what output to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that is concise and information-dense. Every word contributes to understanding the tool's purpose and target.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one well-documented parameter and no output schema. The description sufficiently covers the main purpose and target types. It could mention return format or additional behavior, but given the simplicity, it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the single 'path' parameter with 100% coverage, but the description adds meaning by specifying the target types: 'MCP server, codebase, or configuration file.' This goes beyond the schema's generic 'File or directory path to audit.'

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Audit an MCP server, codebase, or configuration file against OWASP MCP Top 10 vulnerabilities.' It uses a specific verb (audit), identifies the resource types, and specifies the security standard, which distinguishes it from sibling tools like generate_aibom and mcp_verify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when an audit against OWASP MCP Top 10 is needed, providing clear context. However, it does not explicitly mention alternatives or exclusion criteria, so it stops short of the highest score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_verifyB

Cryptographically verify an MCP tool call request signature.

ParametersJSON Schema
NameRequiredDescriptionDefault
signedPayloadYesSigned payload containing toolName, parameters, and meta

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full responsibility for disclosing side effects or behavior. It does not mention whether the verification returns a boolean, raises errors, or has any security implications, leaving the agent uninformed about expected outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is a single, contained sentence that states the action without redundancy. It is front-loaded and every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only one nested parameter and no output schema, the description is too sparse. It lacks any mention of return values, failure modes, or how the signed payload should be structured beyond the schema, making it insufficient for an agent to confidently invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already includes a description for the sole 'signedPayload' parameter ('Signed payload containing toolName, parameters, and meta'), giving 100% schema coverage. The tool description itself adds no further parameter semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'verify' with a clear resource ('MCP tool call request signature'), which immediately distinguishes it from siblings like mcp_scan and generate_aibom. The cryptographic nature is also stated, leaving no ambiguity about the tool's core function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives, nor any mention of prerequisites or contexts where verification is needed. The description simply states the action without helping the agent decide when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

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

  1. 3 tool updatesv1.0.0
    • First observedgenerate_aibom
    • First observedmcp_scan
    • First observedmcp_verify
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Scored across 3 tools

Disambiguation5/5

Each tool serves a clearly distinct purpose: mcp_scan audits for vulnerabilities, generate_aibom produces a supply chain document, and mcp_verify checks cryptographic signatures. There is no overlap or ambiguity between these operations.

Naming Consistency4/5

All tool names use an imperative verb followed by an object (scan, generate, verify), but the prefixes are inconsistent: two use 'mcp_' and one uses 'generate_'. This is a minor deviation from a fully uniform naming pattern.

Tool Count5/5

With exactly 3 tools, the server is tightly scoped to its purpose of MCP security assurance. Each tool covers a distinct, valuable function without bloat or excessive overlap.

Completeness4/5

The set covers the core security lifecycle: vulnerability scanning, supply chain artifact generation, and request verification. A possible gap is a remediation or compliance-check tool, but for a focused security utility, the surface is quite complete.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-security-scanner

    badchars
    A
    license
    A
    quality
    A
    maintenance
    Security scanning for MCP servers from the inside out. Provides runtime inspection, AST-based static analysis, config audit, dependency analysis, and OWASP MCP Top 10 compliance in a single MCP server.
    55
    87
    5
    MIT

  • MCP Shield Runtime

    samsgates
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP Shield Runtime is a local-first security gateway that controls MCP tool calls with parameter-level policies, approval gates, secret redaction, rate limiting, contract drift detection, and tamper-evident auditing before they reach the upstream MCP server.
    1
    Apache 2.0