Which integrations are available for this server?

Provides authentication capabilities via OAuth2 for testing secured GitHub API endpoints to identify security vulnerabilities in authentication flows, token handling, and data access controls. Supports the installation and dependency management through package.json, allowing the MCP server to be installed and run for cybersecurity API testing purposes. Provides TypeScript integration for implementing strongly-typed security testing tools and utilities, with configuration through tsconfig.json to support the MCP server development.

How do I use CyberMCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CyberMCP test the /api/users endpoint for SQL injection vulnerabilities" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

CyberMCP

by ricauts

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

🔒 CyberMCP

AI-powered Cybersecurity API Testing with Model Context Protocol (MCP)

License: MIT Node.js TypeScript

CyberMCP is a Model Context Protocol (MCP) server that enables AI agents to perform comprehensive security testing on backend APIs. It provides 14 specialized security tools and 10 resources for identifying vulnerabilities like authentication bypass, injection attacks, data leakage, and security misconfigurations.

🚀 Quick Start

# Clone and setup
git clone https://github.com/your-username/CyberMCP.git
cd CyberMCP
npm install
npm run build

# Test the server
npm run test-server

# Start interactive testing
npm run test-interactive

Related MCP server: MCPwner

✨ Features

🔐 Authentication Testing - JWT analysis, bypass detection, OAuth2 flows
💉 Injection Testing - SQL injection, XSS vulnerability detection
📊 Data Protection - Sensitive data exposure, path traversal checks
⏱️ Rate Limiting - DoS vulnerability assessment
🛡️ Security Headers - OWASP security header validation
📚 Comprehensive Resources - Security checklists and testing guides

🛠️ Security Tools (14 Total)

Category	Tools
Authentication	`basic_auth`, `token_auth`, `oauth2_auth`, `api_login`, `auth_status`, `clear_auth`, `jwt_vulnerability_check`, `auth_bypass_check`
Injection Testing	`sql_injection_check`, `xss_check`
Data Protection	`sensitive_data_check`, `path_traversal_check`
Infrastructure	`rate_limit_check`, `security_headers_check`

🎯 IDE Integration

CyberMCP works with all major AI-powered IDEs:

Claude Desktop - Direct MCP integration
Cursor IDE - Built-in MCP support
Windsurf (Codeium) - Native MCP protocol
VS Code + Cline - Extension-based integration

📖 Complete Setup Guide - Detailed configuration for each IDE

📋 Usage Example

"Use basic_auth with username 'admin' and password 'secret123' 
then use auth_bypass_check on https://api.example.com/users 
to test for authentication bypass vulnerabilities"

The AI agent will:

Configure authentication credentials
Test the protected endpoint for bypass vulnerabilities
Provide detailed security analysis and recommendations

📊 Testing & Validation

# Comprehensive tool testing
npm run test-tools

# Manual interactive testing  
npm run test-interactive

# Quick setup verification
npm run quick-start

# MCP Inspector (GUI)
npm run inspector

📁 Project Structure

CyberMCP/
├── src/                    # TypeScript source code
│   ├── tools/             # 14 security testing tools
│   ├── resources/         # Security checklists & guides
│   └── utils/             # Authentication & utilities
├── docs/                  # Documentation
├── scripts/               # Testing & utility scripts  
├── examples/              # Configuration examples
├── dist/                  # Built JavaScript (generated)
└── README.md              # This file

🔧 Development

# Development mode with hot reload
npm run dev

# Build TypeScript
npm run build

# Start server (stdio mode)
npm start

# Start HTTP server
TRANSPORT=http PORT=3000 npm start

📖 Documentation

Setup Guide - Detailed installation and configuration
Project Summary - Complete feature overview
Testing Results - Validation and test coverage

🤝 Contributing

Fork the repository
Create a feature branch: git checkout -b feature/new-security-tool
Make your changes and add tests
Submit a pull request

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🔗 Resources

Model Context Protocol - Official MCP documentation
OWASP API Security - API security best practices
MCP TypeScript SDK - Development framework

🔒 Secure your APIs with AI-powered testing!

For support and questions, please create an issue.

Available Tools

14 tools

api_loginD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

auth_bypass_checkD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

auth_statusD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

basic_authD

ParametersJSON Schema

Name	Required	Description	Default
`password`	Yes	Password for authentication
`username`	Yes	Username for authentication

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

clear_authD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

jwt_vulnerability_checkD

ParametersJSON Schema

Name	Required	Description	Default
`jwt_token`	Yes	JWT token to analyze for vulnerabilities

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

oauth2_authD

ParametersJSON Schema

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)

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

path_traversal_checkD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

rate_limit_checkD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

security_headers_checkD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

sensitive_data_checkD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

sql_injection_checkD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

token_authD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

xss_checkD

ParametersJSON Schema

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

TDQS

D1/5.0

Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

14 tool updatesv1.0.0Aug 15, 2025
- First observedapi_login
- First observedauth_bypass_check
- First observedauth_status
- First observedbasic_auth
- First observedclear_auth
- First observedjwt_vulnerability_check
- First observedoauth2_auth
- First observedpath_traversal_check
- First observedrate_limit_check
- First observedsecurity_headers_check
- First observedsensitive_data_check
- First observedsql_injection_check
- First observedtoken_auth
- First observedxss_check

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.1/5.0

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Apideck MCP A
dev.apideck.mcp
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
Developer Tools
42
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

MockLoop MCP Serverofficial
API Testing Developer Tools Code Analysis
MockLoop
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server that generates and runs mock API servers from API documentation like OpenAPI/Swagger specs, enabling developers and AI assistants to quickly spin up mock backends for development and testing.
Updated 13 hours ago (2026-09-05 19:47 UTC)
17
MIT
MCPwner
Penetration Testing Code Analysis
nedlir
A
license
Not graded
quality
A
maintenance
Model Context Protocol server for security research automation, integrating multiple security testing tools into LLM-driven workflows for secret scanning, static analysis, and vulnerability discovery.
Updated 16 days ago (2026-08-20 21:42 UTC)
55
Apache 2.0
Ghost Security MCP Serverofficial
Security Penetration Testing
ghostsecurity
A
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server for the Ghost Security API, providing secure access to security findings and repository data through standardized tools.
Updated 3 months ago (2026-06-12 22:31 UTC)
7
62
3
MIT
AI Fuzz Testing MCP Server
Testing & QA Tools AI & Machine Learning API Testing
ThatOneDevGuy
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server for LLM fuzzing and testing, providing secure access to multiple AI providers through a standardized interface.
Updated a year ago (2025-08-02 06:37 UTC)
-

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ricauts/CyberMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🔒 CyberMCP

🚀 Quick Start

✨ Features

🛠️ Security Tools (14 Total)

🎯 IDE Integration

📋 Usage Example

📊 Testing & Validation

📁 Project Structure

🔧 Development

📖 Documentation

🤝 Contributing

📄 License

🔗 Resources

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

MockLoop MCP Serverofficial

Ghost Security MCP Serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API