CyberMCP es un servidor de Protocolo de Contexto de Modelo (MCP) diseñado para evaluar las API backend en busca de vulnerabilidades de seguridad. Proporciona un conjunto de herramientas y recursos especializados que los LLM pueden usar para identificar problemas de seguridad comunes en las API.
Prueba de vulnerabilidad de autenticación : verifique vulnerabilidades de JWT, omisión de autenticación y mecanismos de autenticación débiles
Pruebas de inyección : prueba de inyección SQL, XSS y otras vulnerabilidades de inyección
Pruebas de fuga de datos : identifique problemas de exposición de datos confidenciales
Pruebas de limitación de velocidad : prueba para eludir la limitación de velocidad y vulnerabilidades DDoS
Prueba de encabezados de seguridad : verifique si hay encabezados de seguridad faltantes o mal configurados
Recursos completos : listas de verificación de acceso y guías para pruebas de seguridad de API
Compatibilidad con autenticación : múltiples métodos de autenticación para probar puntos finales seguros
Related MCP server: MCPwner
CyberMCP/
├── src/
│ ├── tools/ # MCP tools for security testing
│ ├── resources/ # MCP resources (checklists, guides)
│ ├── transports/ # Custom transport implementations
│ ├── utils/ # Utility functions and auth management
│ └── index.ts # Main entry point
├── package.json # Dependencies and scripts
├── tsconfig.json # TypeScript configuration
└── README.md # This fileClonar el repositorio:
git clone https://github.com/your-username/CyberMCP.git
cd CyberMCPInstalar dependencias:
npm installConstruir el proyecto:
npm run buildPuede ejecutar el servidor utilizando el transporte stdio (predeterminado) o el transporte HTTP:
Uso del transporte stdio (para integración con plataformas LLM):
npm startUsando el transporte HTTP (para desarrollo y pruebas locales):
TRANSPORT=http PORT=3000 npm startEl servidor MCP se puede conectar a cualquier cliente MCP, incluidas las plataformas LLM que admiten el Protocolo de contexto de modelo.
CyberMCP admite varios métodos de autenticación para probar API seguras:
Autenticación básica : configure la autenticación básica HTTP con nombre de usuario y contraseña
Autenticación de token : utilice tokens de portador, JWT o formatos de token personalizados
Autenticación OAuth2 : Compatibilidad total con el flujo OAuth2 con diferentes tipos de concesiones
Inicio de sesión de API personalizado : autentífiquese contra cualquier punto final de API de inicio de sesión
Herramientas de autenticación:
basic_auth : Autenticar con nombre de usuario/contraseña
token_auth : Configurar la autenticación basada en token
oauth2_auth : Realizar la autenticación OAuth2
api_login : Iniciar sesión usando un punto final de API personalizado
auth_status : Verifica el estado de autenticación actual
clear_auth : Borra el estado de autenticación actual
Comprobación de vulnerabilidades de JWT : analiza tokens JWT para detectar problemas de seguridad.
Comprobación de omisión de autenticación : prueba los puntos finales para detectar vulnerabilidades de omisión de autenticación
Comprobación de inyección SQL : prueba parámetros para detectar vulnerabilidades de inyección SQL
XSS Check : Pruebas para detectar vulnerabilidades de secuencias de comandos entre sitios
Verificación de datos confidenciales : identifica información personal identificable, credenciales e información confidencial filtradas
Comprobación de recorrido de ruta : prueba vulnerabilidades de recorrido de directorio
Comprobación de encabezados de seguridad : analiza los encabezados HTTP para conocer las mejores prácticas de seguridad.
Acceda a las listas de verificación de seguridad a través de cybersecurity://checklists/{category} , donde la categoría puede ser:
authentication
injection
data_leakage
rate_limiting
general
Acceda a guías de pruebas detalladas a través de guides://api-testing/{topic} , donde el tema puede ser:
jwt-testing
auth-bypass
sql-injection
xss
rate-limiting
Para probar eficazmente una API en busca de vulnerabilidades de seguridad, necesitará:
Puntos finales de API : URL de los puntos finales para probar
Información de autenticación : credenciales o tokens para acceder a puntos finales seguros
Nombres de parámetros : nombres de los parámetros que aceptan la entrada del usuario
Datos de prueba : Muestra de datos válidos para los parámetros
Comportamiento esperado : cómo debería ser la respuesta normal
Flujo de autenticación : cómo funciona la autenticación en la API de destino
basic_auth:
username: "admin"
password: "secure_password"token_auth:
token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
token_type: "Bearer"
expires_in: 3600oauth2_auth:
client_id: "client_123"
client_secret: "secret_456"
token_url: "https://example.com/oauth/token"
grant_type: "client_credentials"
scope: "read write"api_login:
login_url: "https://example.com/api/login"
credentials:
username: "admin"
password: "secure_password"
token_path: "data.access_token"Instituto Tecnológico de Massachusetts (MIT)
| Name | Required | Description | Default |
|---|---|---|---|
| credentials | Yes | Login credentials as key-value pairs | |
| header_name | No | Header name to use for the token | Authorization |
| login_url | Yes | API login endpoint URL | |
| method | No | HTTP method to use | post |
| token_path | No | Path to token in the response (e.g., 'data.accessToken') | token |
| token_prefix | No | Token prefix to use in Authorization header | Bearer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| auth_header | No | Authentication header name (if different from standard) | |
| auth_token | No | Authentication token (if not using the currently authenticated session) | |
| endpoint | Yes | API endpoint to test | |
| http_method | No | HTTP method to use | GET |
| use_session_auth | No | Whether to use the current session authentication if available |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | Password for authentication | |
| username | Yes | Username for authentication |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| jwt_token | Yes | JWT token to analyze for vulnerabilities |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| authorization_url | No | OAuth2 authorization endpoint URL (for authorization code flow) | |
| client_id | Yes | OAuth2 client ID | |
| client_secret | No | OAuth2 client secret | |
| grant_type | No | OAuth2 grant type | client_credentials |
| password | No | Password (for password grant type) | |
| redirect_uri | No | Redirect URI (for authorization code flow) | |
| scope | No | OAuth2 scope | |
| token_url | Yes | OAuth2 token endpoint URL | |
| username | No | Username (for password grant type) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | API endpoint to test | |
| http_method | No | HTTP method to use | GET |
| parameter_name | Yes | Name of the parameter to test for path traversal | |
| use_auth | No | Whether to use current authentication if available |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| auth_header | No | Authentication header (if any) | |
| endpoint | Yes | API endpoint to test | |
| http_method | No | HTTP method to use | GET |
| request_body | No | Request body (for POST/PUT requests) | |
| request_count | No | Number of requests to send | |
| request_delay_ms | No | Delay between requests in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | API endpoint to test | |
| http_method | No | HTTP method to use | GET |
| use_auth | No | Whether to use current authentication if available |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | API endpoint to test | |
| http_method | No | HTTP method to use | GET |
| request_body | No | Request body (for POST/PUT requests) | |
| use_auth | No | Whether to use current authentication if available |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | API endpoint to test | |
| http_method | No | HTTP method to use | GET |
| original_value | Yes | Original value for the parameter | |
| parameter_name | Yes | Name of the parameter to test for SQL injection | |
| use_auth | No | Whether to use current authentication if available |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| expires_in | No | Token expiration time in seconds | |
| refresh_token | No | Refresh token (if available) | |
| token | Yes | Authentication token | |
| token_type | No | Token type (Bearer, JWT, etc.) | Bearer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | API endpoint to test | |
| http_method | No | HTTP method to use | GET |
| parameter_name | Yes | Name of the parameter to test for XSS | |
| use_auth | No | Whether to use current authentication if available |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.0api_loginauth_bypass_checkauth_statusbasic_authclear_authjwt_vulnerability_checkoauth2_authpath_traversal_checkrate_limit_checksecurity_headers_checksensitive_data_checksql_injection_checktoken_authxss_checkScored across 14 tools
Each tool has a clearly distinct purpose focused on specific security testing or authentication functions, with no overlap between authentication methods (e.g., api_login, basic_auth, oauth2_auth) and vulnerability checks (e.g., sql_injection_check, xss_check, path_traversal_check). The tools are well-differentiated by their target areas, making misselection unlikely.
The naming follows a consistent snake_case pattern throughout, with most tools using clear descriptive names (e.g., sql_injection_check, security_headers_check). However, there are minor deviations like 'auth_bypass_check' versus 'jwt_vulnerability_check' where some use underscores more consistently than others, but overall the pattern is predictable and readable.
With 14 tools, the count is well-scoped for a cybersecurity testing server, covering a comprehensive range of authentication methods and common vulnerability checks. Each tool appears to earn its place by addressing a specific aspect of security assessment, avoiding both excessive bloat and insufficient coverage.
The tool set provides strong coverage for security testing, including authentication (e.g., api_login, basic_auth, token_auth) and vulnerability checks (e.g., sql_injection_check, xss_check). Minor gaps might exist, such as lack of tools for specific advanced attacks or reporting features, but core workflows for authentication and basic security assessments are well-covered without dead ends.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
