This server scans MCP (Model Context Protocol) servers for prompt-injection, tool-poisoning, SSRF, and other security vulnerabilities using 30+ pattern rules, and provides auditing, reporting, and pricing information.
scan_mcp_url(url): Fetches a remote MCP server's tool listing and scans each tool's name, description, and input schema against 30+ injection rules (RCE, credential exfiltration, shell metacharacters, etc.). Returns a structured report with per-tool findings, severity counts, a 0–100 score, verdict, and remediation hints (free tier: 5 scans/day).
audit_tool_descriptions(tools_json): Scans a pasted JSON tool list directly — useful for auth-walled or offline servers — using the same full rule catalogue.
signed_safety_report(subject, findings_json, score, note): Issues a cryptographically signed safety certificate with a public verification URL for auditors and procurement teams (Pro/Enterprise tier only).
list_rules(): Lists all 30+ detection rules across severity tiers (CRITICAL, HIGH, MEDIUM, LOW) so you can inspect the catalogue before subscribing.
pricing(): Shows subscription tiers (Free, Starter, Pro, Enterprise) with purchase links.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@meok-mcp-injection-scan-mcp scan https://example.com/mcp for vulnerabilities"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP injection-scanner — 30+ canonical detection rules across 5 severity tiers for the April 2026 ...
MCP injection-scanner — 30+ canonical detection rules across 5 severity tiers for the April 2026 Anthropic MCP RCE class. By MEOK AI Labs.
# Install via pip
pip install meok_mcp_injection_scan_mcp
# Or install via Smithery
npx -y @smithery/cli@latest install meok-mcp-injection-scan-mcp --client claudeRelated MCP server: agent-audit
MCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance
This MCP server is built with EU AI Act compliance built-in:
✅ Article 9 — Risk Management System
✅ Article 13 — Transparency & Instructions for Use
✅ Article 15 — Bias Detection & Testing
✅ Article 26 — FRIA Support (where applicable)
✅ Article 50 — AI Content Watermarking (where applicable)
Need help getting compliant? Book a free 15-min diagnostic →
Need custom development, SLA guarantees, or white-label deployment?
Pro: $99/mo — Full MCP suite + EU AI Act tracking
Enterprise: $499/mo — Custom dev + SLA + Dedicated support
View Pricing → | Contact Sales →
This server is part of the MEOK AI Labs ecosystem — 300+ MCP servers for sovereign AI governance.
Domain | Purpose |
EU AI Act compliance marketplace | |
AI safety & monitoring | |
Sovereign AI platform | |
Legacy modernization |
MIT © CSOAI-ORG
Audit a JSON string containing a tool list (paste from your own MCP server's tools/list output). Same rule catalogue as scan_mcp_url — useful when the server is behind auth or not yet deployed.
tools_json accepts either: a raw list, or {"tools": [...]}, or
{"result": {"tools": [...]}}.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool for security assessment, threat detection, or vulnerability analysis. Suitable for automated security scanning and risk evaluation.
When NOT to use: Do not rely solely on this tool for production security decisions. Always combine with manual security review.
Args: tools_json (str): The tools json to analyze or process. api_key (str): The api key to analyze or process.
| Name | Required | Description | Default |
|---|---|---|---|
| tools_json | Yes | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description states it is read-only, stateless, idempotent, and mentions rate limits (10/day free, unlimited pro) and that no authentication is required for basic usage. This covers key behavioral traits, though it could specify error handling or what happens on rate limit exceed.
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?
Well-structured with clear sections (main description, behavior, when to use/not, args). Most sentences add value, though the 'Args' section essentially repeats parameter names and types without additional insight, slightly bloating length.
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?
Given no annotations and no output schema, description provides context about when to use (behind auth, not deployed), behavioral traits, and parameter formats. Lacks details on exact security checks performed or output structure, but covers sufficient ground for selection.
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 0%, so description must compensate. It explains tools_json accepts multiple formats (raw list, object with tools, etc.) and briefly mentions api_key's purpose. However, the api_key description is vague ('to analyze or process') and doesn't clarify usage, leaving ambiguity.
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 the tool audits a JSON string containing a tool list for security assessment. It distinguishes from sibling scan_mcp_url by noting it uses the same rule catalogue but is useful when the server is behind auth or not yet deployed. The verb 'audit' and specific resource 'tool list' make purpose unambiguous.
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?
Explicit 'When to use' and 'When NOT to use' sections provide clear guidance. It advises use for security assessment, threat detection, and automated scanning, while cautioning against sole reliance for production decisions and recommending manual review. Also suggests alternative scan_mcp_url for URL-based scanning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every detection rule in the canonical catalogue. Useful for buyers auditing what we check before subscribing.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool for security assessment, threat detection, or vulnerability analysis. Suitable for automated security scanning and risk evaluation.
When NOT to use: Do not rely solely on this tool for production security decisions. Always combine with manual security review. Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Thoroughly describes read-only, stateless, idempotent behavior, authentication, rate limits, error handling, and data privacy. With no annotations, the description fully informs the agent.
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?
Well-structured with sections, but somewhat verbose. Some behavioral points are repeated across sections, reducing conciseness.
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?
Covers all relevant aspects: purpose, usage, behavior, error handling, rate limits, idempotency, and data privacy. Very complete for a parameterless list 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?
Input schema has 0 parameters, so schema coverage is 100%. Description adds no parameter details but doesn't need to; baseline score of 4 applies.
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?
Clearly states 'List every detection rule in the canonical catalogue' with a specific verb and resource. It distinguishes itself from siblings like 'pricing' or 'signed_safety_report'.
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?
Includes explicit 'When to use' and 'When NOT to use' sections, providing actionable guidance. However, it does not mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pricing + subscribe links for this MCP.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool for security assessment, threat detection, or vulnerability analysis. Suitable for automated security scanning and risk evaluation.
When NOT to use: Do not rely solely on this tool for production security decisions. Always combine with manual security review. Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers an exceptionally detailed 'Behavioral Transparency' section covering side effects (read-only, stateless), authentication needs, rate limits, error handling, idempotency, and data privacy. This far exceeds minimal requirements.
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 extensively detailed but contains redundancy (e.g., read-only and stateless repeated across sections). It could be more concise while retaining key points. Front-loading with 'Pricing + subscribe links' is misleading given the actual content.
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 a wealth of behavioral detail, the description fails to coherently specify what the tool's output actually is (pricing info vs. security analysis). For a tool with no parameters and no output schema, a clear statement of return values is essential, and this is missing. The purpose confusion severely undermines completeness.
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?
The input schema has zero parameters, so schema coverage is 100% and the baseline is 4 per rubric. The description does not need to elaborate on parameters, and it does not contradict 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 initially claims to provide 'Pricing + subscribe links for this MCP', but the subsequent behavioral description and usage guidelines describe a security analysis tool (threat detection, vulnerability analysis). This contradiction makes the purpose unclear and misleading, failing to state what the tool actually does.
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?
The description includes explicit 'When to use' and 'When NOT to use' sections, advising usage for security assessment and cautioning against sole reliance for production decisions. However, it does not distinguish this tool from siblings such as 'audit_tool_descriptions' or 'scan_mcp_url', missing an opportunity to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a remote MCP server's /tools/list (or any JSON tool listing) and scan every tool's name + description + inputSchema against the canonical 30+ injection-pattern rules.
Returns a structured report: per-tool findings, severity counts, score 0-100, verdict, and remediation hints. Free tier: 5 scans/day per key.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool for security assessment, threat detection, or vulnerability analysis. Suitable for automated security scanning and risk evaluation.
When NOT to use: Do not rely solely on this tool for production security decisions. Always combine with manual security review.
Args: url (str): The url to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers a comprehensive 'Behavioral Transparency' section covering side effects, authentication, rate limits, error handling, idempotency, and data privacy. However, there is an inconsistency: the first paragraph states 'Free tier: 5 scans/day per key,' while the Behavioral section says 'Free tier: 10/day rate limit,' which may confuse the AI agent.
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 well-structured with headings, but contains redundancy (the 'Behavior' section repeats much of the 'Behavioral Transparency' section) and a contradiction in rate limit numbers. It could be more concise without losing essential 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?
Despite the lack of output schema, the description explains the return format (structured report with findings, severity, score, verdict, hints). It covers the tool's purpose, usage, behavioral details, error handling, and privacy, making it complete for an AI agent to use effectively.
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?
The input schema has 0% description coverage, so the description must compensate. The 'Args' section provides minimal explanations ('The url to analyze or process,' 'The api key to analyze or process') that add little beyond the schema's title and type. No format, constraints, or examples are given, leaving the agent with insufficient semantic guidance.
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 tool's action: fetch a remote MCP server's tool listing and scan tools against injection-pattern rules. It specifies the resource (remote MCP server's /tools/list) and the verb (scan), distinguishing it from sibling tools like audit_tool_descriptions or list_rules.
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?
The description includes explicit 'When to use' and 'When NOT to use' sections, providing clear guidance on appropriate contexts and cautions. It advises against sole reliance for production decisions, but lacks direct mention of alternative sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a cryptographically signed safety report for the scanned MCP server. Returns a cert with a public verify URL anyone can hit to confirm the audit happened on the date claimed.
Pro / Enterprise tier only.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool for security assessment, threat detection, or vulnerability analysis. Suitable for automated security scanning and risk evaluation.
When NOT to use: Do not rely solely on this tool for production security decisions. Always combine with manual security review.
Args: subject (str): The subject to analyze or process. findings_json (str): The findings json to analyze or process. score (int): The score to analyze or process. note (str): The note to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | ||
| findings_json | No | ||
| score | No | ||
| note | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and delivers extensively: it declares the tool read-only and stateless, explains authentication (none for basic, Pro/Enterprise requires MEOK API key), rate limits (10/day free, unlimited Pro), error handling, idempotency, and data privacy. This far exceeds typical descriptions.
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 well-structured with clear sections (purpose, tier, behavior, when to use/not, args, behavioral transparency). It is longer than necessary, but every sentence adds unique value. The front-loading of purpose is effective.
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?
Given the absence of annotations and output schema, the description covers all essential gaps: behavior, side effects, auth, rate limits, errors, idempotency, privacy. It even hints at the return format (cert and verify URL). The tool is complex with 5 parameters, and the description provides sufficient context for an agent to use it appropriately.
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 description coverage is 0%, yet parameter descriptions in the text only repeat the name and add generic phrasing like 'The subject to analyze or process.' No additional semantics or constraints are provided for any of the 5 parameters. The api_key parameter’s relation to tier is mentioned elsewhere but not in the parameter list.
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 opens with a clear action verb and object: 'Issue a cryptographically signed safety report for the scanned MCP server.' It further specifies the return (cert with public verify URL) and distinguishes from sibling tools like audit_tool_descriptions and scan_mcp_url by focusing on cryptographic signing.
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?
The description includes explicit 'When to use' and 'When NOT to use' sections, listing appropriate contexts (security assessment, threat detection) and caveats (not solely for production decisions, combine with manual review). It also notes the tier restriction (Pro/Enterprise only).
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.
v1.0.1audit_tool_descriptionslist_rulespricingscan_mcp_urlsigned_safety_reportScored across 5 tools
Each tool targets a distinct aspect of the security scanning workflow: 'audit_tool_descriptions' handles local JSON analysis, 'scan_mcp_url' handles remote scanning, 'list_rules' lists detection rules, 'pricing' provides subscription details, and 'signed_safety_report' generates a signed certificate. No two tools have overlapping purposes.
The naming convention is mostly snake_case but inconsistent in structure: three tools follow a verb_noun pattern ('audit_tool_descriptions', 'list_rules', 'scan_mcp_url'), while 'pricing' is a bare noun and 'signed_safety_report' uses a past participle adjective-noun form. This mix reduces predictability.
With 5 tools, the server is well-scoped for its purpose of scanning MCP servers for injection vulnerabilities. Each tool serves a clear function without overlap, and the count is appropriate for a focused security assessment tool.
The tool surface covers the core workflow: local audit, remote scan, rule listing, pricing, and signed reporting. Minor gaps exist (e.g., no tool for configuration or result history), but these are not essential for the primary use case. Overall, the surface is sufficiently complete for its domain.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.