Cybersecurity AI MCP
Cybersecurity AI MCP is an AI-powered cybersecurity analysis server providing read-only, stateless security assessment tools:
Classify Vulnerabilities (
classify_vulnerability): Analyze a vulnerability by type, severity, and OWASP category based on its description, affected component, exploit availability, network accessibility, and authentication requirements.Look Up CVEs (
lookup_cve): Retrieve CVE details from a vulnerability database by CVE ID, product name, or severity filter (critical/high/medium/low).Check Security Headers (
check_security_headers): Evaluate HTTP response headers against security best practices to identify misconfigurations or missing protections.Analyze Password Strength (
analyze_password_strength): Assess a password's strength and receive improvement suggestions ā processed locally and never stored or transmitted.Generate Threat Models (
generate_threat_model): Produce a STRIDE-based threat model for a system by specifying its components, data types, external interfaces, authentication method, and deployment environment.
All tools are read-only, idempotent, and stateless. A free tier offers 10 calls/day per tool; Pro/Enterprise tiers require a MEOK API key for unlimited usage. The server is MCP protocol compliant and built with EU AI Act compliance in mind.
Cybersecurity Ai MCP
cybersecurity-ai-mcp MCP ā AI-powered automation tool
cybersecurity-ai-mcp MCP ā AI-powered automation tool. MIT.
š Quick Start
# Install via pip
pip install cybersecurity_ai_mcp
# Or install via Smithery
npx -y @smithery/cli@latest install cybersecurity-ai-mcp --client claudeRelated MCP server: ISO 27001 AI MCP
⨠Features
MCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance
š Documentation
š”ļø Compliance
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 ā
š¢ Enterprise
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 ā
š¤ Part of the MEOK Ecosystem
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 |
š License
MIT Ā© CSOAI-ORG
Pairs with MEOK Governance Suite
Build something that touches users? You need compliance. MEOK ships 38 governance MCPs that drop in alongside this tool ā EU AI Act, DORA, NIS2, CRA, GDPR, ISO 42001, FDA SaMD, MDR, Basel, MiFID II, MiCA, COPPA, and more.
# One-shot install of the governance pack
npx meok-setup --pack governanceFree tier: 10 calls/day per MCP. Pro tier (Ā£79/mo): unlimited + cryptographically signed compliance attestations your auditor verifies independently.
ā Full catalogue: councilof.ai/catalogue ā MEOK AI Labs: meok.ai
šø Try MEOK in 30 seconds ā instant buy ladder
Tier | Price | What you get | Stripe |
Smoke test | £1 | Signed sample MCP-Hardening report + Article 50 PDF | |
Quick Kit | £9 | EU AI Act Article 50 implementation guide (C2PA + EU-Icon) | |
Founder Call | £29 | 30-min 1-on-1 with the founder |
Refundable. UK Stripe ā VAT-clean. Builds on the 81-MCP MEOK fleet. Verify any signed report at https://meok.ai/verify.
Configuration
Add to your claude_desktop_config.json (Claude Desktop) or your MCP client config:
{
"mcpServers": {
"cybersecurity-ai-mcp": {
"command": "uvx",
"args": ["cybersecurity-ai-mcp"]
}
}
}Or: pip install cybersecurity-ai-mcp then run the cybersecurity-ai-mcp command (stdio transport).
Examples
Once configured, ask your assistant, for example:
"Use
classify_vulnerabilityto ā¦""Use
lookup_cveto ā¦""Use
check_security_headersto ā¦"
Available Tools
5 toolsanalyze_password_strengthA
Analyze password strength and provide improvement suggestions.
Args: password: The password to analyze (processed locally, never stored or transmitted).
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 |
|---|---|---|---|
| password | Yes | ||
| api_key | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: read-only and stateless, idempotent, rate limits (free 10/day, pro unlimited), authentication needs, error handling, and data privacy (local processing only). This addresses all key transparency concerns.
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 (Args, Behavior, When to use, etc.), but it is somewhat verbose. However, every sentence contributes value and the structure aids readability.
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 tool's simplicity (one required parameter, no output schema), the description covers all necessary context: purpose, parameters, behavioral traits, error handling, and rate limits. An agent can confidently invoke this tool based on the description alone.
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 schema has 0% description coverage, but the description adds essential meaning: password is processed locally and never stored (privacy), and api_key is referenced in authentication context (MEOK_API_KEY environment variable). This compensates fully for the schema gap.
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 'Analyze password strength and provide improvement suggestions.' This specific verb+resource combination, along with sibling tool names (security headers, vulnerability classification, threat model, CVE lookup), distinguishes it effectively.
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 context for tool invocation, including that it should not be used as the sole basis for production security decisions. This guides the agent on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_security_headersA
Analyze HTTP security headers against best practices.
Args: headers: Dict of HTTP response headers. Example: {"Strict-Transport-Security": "max-age=31536000"}.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| headers | Yes | ||
| api_key | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses read-only, stateless, idempotent nature, rate limits (free vs pro), and authentication requirements, offering comprehensive behavioral insight.
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-organized into clear sections (Args, Behavior, When to use/not), each sentence is purposeful and concise without redundancy.
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 behavior, rate limits, and usage warnings well, but omits output format/return value details (no output schema provided) and error handling, a minor gap for a simple analysis 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?
The description adds value for the 'headers' parameter with an example and format, but fails to mention the 'api_key' parameter, leaving part of the schema uncovered despite low schema coverage.
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 analyzes HTTP security headers against best practices, a specific verb-resource pair that distinguishes it from sibling tools like analyze_password_strength or classify_vulnerability.
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 context for appropriate usage and cautions against sole reliance for production decisions, guiding the agent effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
classify_vulnerabilityA
Classify a vulnerability by type, severity, and OWASP category.
Args: description: Description of the vulnerability. affected_component: Component or service affected. has_exploit: Whether a known exploit exists. network_accessible: Whether the vuln is network-accessible. auth_required: Whether authentication is required to exploit.
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 |
|---|---|---|---|
| description | Yes | ||
| affected_component | No | ||
| has_exploit | No | ||
| network_accessible | No | ||
| auth_required | No | ||
| api_key | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses side effects (none, read-only, stateless), authentication needs (none for basic, pro requires API key), rate limits (free 10/day, pro unlimited), error handling (structured errors), idempotency, and data privacy. This is comprehensive and exceeds 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 well-structured with clear sections and front-loaded purpose. However, there is redundancy between the 'Behavior' and 'Behavioral Transparency' sections, and the length could be trimmed without losing meaning.
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 covering purpose, parameters, and behavior thoroughly, the description lacks explicit output specification (e.g., what the classification returns). With no output schema, this is a notable gap. Overall, it provides a good foundation but misses key details for a complete understanding.
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 description lists all parameters except api_key (present in schema) with brief descriptions, partially compensating for 0% schema coverage. However, meanings for boolean fields are not elaborated, and one parameter is missing from the textual description. It adds some clarity but not enough to fully compensate.
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 'classify' and resource 'vulnerability', specifying classification by type, severity, and OWASP category. It distinguishes the tool from siblings like lookup_cve and analyze_password_strength by focusing on classification rather than lookup or analysis of other aspects.
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 context for security assessment and cautioning against sole reliance for production decisions. However, it does not compare directly with sibling tools to guide selection, missing a chance to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_threat_modelA
Generate a STRIDE-based threat model for a system.
Args: system_name: Name of the system being modeled. components: System components (e.g. web_app, api_server, database, cache). data_types: Types of data processed (e.g. pii, financial, health, credentials). external_interfaces: External integrations (e.g. payment_gateway, email_service). authentication_method: password | mfa | sso | api_key | oauth. deployment: cloud | on_premise | hybrid | serverless.
Behavior: This tool generates structured output without modifying external systems. Output is deterministic for identical inputs. No side effects. 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 |
|---|---|---|---|
| system_name | Yes | ||
| components | Yes | ||
| data_types | Yes | ||
| external_interfaces | No | ||
| authentication_method | No | password | |
| deployment | No | cloud | |
| api_key | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details side effects (read-only, no modifications), authentication (basic usage no auth, pro requires API key), rate limits (10/day free tier), error handling (structured error objects), idempotency, and data privacy. Very comprehensive.
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 labeled sections (Args, Behavior, When to use, When NOT to use, Behavioral Transparency) and is front-loaded with purpose. It contains multiple sections that add value, though could be slightly trimmed without losing substance.
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 exists, but the description mentions structured output without side effects, rate limit headers, and error objects. It covers authentication, rate limits, error handling, idempotency, and data privacy. Explicit output format details would increase 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?
With 0% schema description coverage, the description adds meaning to each of the 7 parameters by listing them with explanations and examples (e.g., 'components: System components (e.g. web_app, api_server)'). It also mentions defaults for authentication_method and deployment, and notes required fields.
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 generates a STRIDE-based threat model for a system, specifying the type of output. It distinguishes from sibling tools like analyze_password_strength and lookup_cve, which focus on different security tasks.
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: use for security assessment, threat detection, vulnerability analysis; but not solely for production decisions, always combine with manual review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_cveA
Look up CVE details from the vulnerability database.
Args: cve_id: Specific CVE identifier (e.g. CVE-2024-3094). product: Product name to search for. severity: Filter by severity (critical|high|medium|low).
Behavior: This tool generates structured output without modifying external systems. Output is deterministic for identical inputs. No side effects. 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 |
|---|---|---|---|
| cve_id | No | ||
| product | No | ||
| severity | No | ||
| api_key | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Comprehensive disclosure of side effects (read-only), authentication (no auth basic, API key for pro), rate limits (10/day free, unlimited pro), error handling, idempotency, and data privacy. No annotations provided, so description carries full burden and exceeds expectations.
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 (Args, Behavior, When to use, etc.). Some redundancy in behavioral details, but overall organized and front-loaded with purpose.
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 purpose, parameters, behavior, and limitations. Lacks description of output format (no output schema), but mentions structured error objects. Sufficient for a look-up tool with behavioral 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?
Schema description coverage is 0%. Description lists three parameters with examples but omits 'api_key' parameter (though mentions API key in behavioral section). Partially compensates but missing parameter reduces clarity.
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 'Look up CVE details' with specific verb and resource. Distinct from sibling tools like analyze_password_strength, check_security_headers, classify_vulnerability, generate_threat_model.
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 on appropriate contexts and limitations, e.g., 'Do not rely solely on this tool for production security decisions.'
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. Dates show when Glama detected each change.
5 tool updates
v1.0.0- First observed
analyze_password_strength - First observed
check_security_headers - First observed
classify_vulnerability - First observed
generate_threat_model - First observed
lookup_cve
TDQS
Each tool targets a distinct cybersecurity task: password analysis, HTTP header checking, vulnerability classification, threat modeling, and CVE lookup. There is no functional overlap, making it easy for an agent to select the correct tool.
All tool names follow the verb_noun convention with underscores (e.g., analyze_password_strength, lookup_cve), providing a predictable and clear pattern across the entire set.
With 5 tools, the server is well-scoped for its cybersecurity purpose. Each tool addresses a common security evaluation need without being too few or overly numerous.
The tool set covers a broad range of security analysis tasks including password strength, headers, vulnerability classification, threat modeling, and CVE lookup. Missing active scanning or reporting tools, but the core workflow is well-supported.
Maintenance
Related MCP Connectors
MEOK MCP Hardening MCP ā automated security red-team for any MCP server. Maps OWASP LLM Top 10
Agent Orchestrator MCP Server by MEOK AI Labs
Agent Identity Trust MCP Server by MEOK AI Labs
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceNIST RMF AI - MCP server providing AI-powered tools and automation by MEOK AI Labs24MIT

ISO 27001 AI MCPofficial
AlicenseNot gradedqualityBmaintenanceISO 27001 AI - MCP server providing AI-powered tools and automation by MEOK AI Labs183MIT
SOC2 Compliance AI MCPofficial
AlicenseAqualityCmaintenanceSOC2 Compliance AI - MCP server providing AI-powered tools and automation by MEOK AI Labs616MIT- AlicenseNot gradedqualityBmaintenanceAI Ops - MCP server providing AI-powered tools and automation by MEOK AI Labs16MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CSOAI-ORG/cybersecurity-ai-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server