CyberMCP 是一个模型上下文协议 (MCP) 服务器，用于测试后端 API 的安全漏洞。它提供了一组专用工具和资源，可供 LLM 用来识别 API 中常见的安全问题。
身份验证漏洞测试：检查 JWT 漏洞、身份验证绕过和弱身份验证机制
注入测试：测试 SQL 注入、XSS 和其他注入漏洞
数据泄漏测试：识别敏感数据泄露问题
速率限制测试：测试速率限制绕过和 DDoS 漏洞
安全标头测试：检查缺失或配置错误的安全标头
综合资源：访问 API 安全测试的清单和指南
身份验证支持：多种身份验证方法来测试安全端点
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 file克隆存储库：
git clone https://github.com/your-username/CyberMCP.git
cd CyberMCP安装依赖项：
npm install构建项目：
npm run build您可以使用 stdio 传输（默认）或 HTTP 传输运行服务器：
使用 stdio 传输（用于与 LLM 平台集成）：
npm start使用 HTTP 传输（用于本地开发和测试）：
TRANSPORT=http PORT=3000 npm startMCP 服务器可以连接到任何 MCP 客户端，包括支持模型上下文协议的 LLM 平台。
CyberMCP 支持多种身份验证方法来测试安全的 API：
基本身份验证：使用用户名和密码设置 HTTP 基本身份验证
令牌认证：使用持有者令牌、JWT 或自定义令牌格式
OAuth2 身份验证：完整的 OAuth2 流程支持，具有不同的授权类型
自定义 API 登录：针对任何登录 API 端点进行身份验证
身份验证工具：
basic_auth ：使用用户名/密码进行身份验证
token_auth ：设置基于令牌的身份验证
oauth2_auth ：执行 OAuth2 身份验证
api_login ：使用自定义 API 端点登录
auth_status ：检查当前身份验证状态
clear_auth ：清除当前身份验证状态
JWT 漏洞检查：分析 JWT 令牌是否存在安全问题
身份验证绕过检查：测试端点是否存在身份验证绕过漏洞
SQL注入检查：测试SQL注入漏洞的参数
XSS 检查：测试跨站脚本漏洞
敏感数据检查：识别泄露的 PII、凭证和敏感信息
路径遍历检查：测试目录遍历漏洞
安全标头检查：分析 HTTP 标头以获取最佳安全实践
通过cybersecurity://checklists/{category}访问安全检查表，其中类别可以是：
authentication
injection
data_leakage
rate_limiting
general
通过guides://api-testing/{topic}访问详细的测试指南，其中主题可以是：
jwt-testing
auth-bypass
sql-injection
xss
rate-limiting
为了有效地测试 API 的安全漏洞，您需要：
API 端点：要测试的端点的 URL
身份验证信息：用于访问安全端点的凭证或令牌
参数名称：接受用户输入的参数的名称
测试数据：参数的样本有效数据
预期行为：正常响应应该是什么样的
身份验证流程：目标 API 中的身份验证如何工作
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"麻省理工学院
| 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
