CyberMCP는 백엔드 API의 보안 취약점을 테스트하도록 설계된 모델 컨텍스트 프로토콜(MCP) 서버입니다. LLM이 API의 일반적인 보안 문제를 파악하는 데 사용할 수 있는 전문 도구와 리소스를 제공합니다.
인증 취약성 테스트 : JWT 취약성, 인증 우회 및 취약한 인증 메커니즘 확인
주입 테스트 : SQL 주입, XSS 및 기타 주입 취약점 테스트
데이터 유출 테스트 : 민감한 데이터 노출 문제 식별
속도 제한 테스트 : 속도 제한 우회 및 DDoS 취약성 테스트
보안 헤더 테스트 : 누락되었거나 잘못 구성된 보안 헤더 확인
포괄적인 리소스 : API 보안 테스트를 위한 체크리스트 및 가이드에 액세스하세요
인증 지원 : 보안 엔드포인트를 테스트하기 위한 다양한 인증 방법
Related MCP server: MCPwner
지엑스피1
저장소를 복제합니다.
git clone https://github.com/your-username/CyberMCP.git
cd CyberMCP종속성 설치:
npm install프로젝트를 빌드하세요:
npm run buildstdio 전송(기본값) 또는 HTTP 전송을 사용하여 서버를 실행할 수 있습니다.
stdio 전송 사용(LLM 플랫폼과 통합용):
npm startHTTP 전송 사용(로컬 개발 및 테스트용):
TRANSPORT=http PORT=3000 npm startMCP 서버는 모델 컨텍스트 프로토콜을 지원하는 LLM 플랫폼을 포함한 모든 MCP 클라이언트에 연결할 수 있습니다.
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} 통해 보안 체크리스트에 액세스하세요. 여기서 category는 다음과 같습니다.
authentication
injection
data_leakage
rate_limiting
general
guides://api-testing/{topic} 통해 자세한 테스트 가이드에 액세스하세요. 여기서 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"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
