Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCPFP Run a guided security assessment on the lab target and generate a Markdown report."
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.
Servidor MCP (Model Context Protocol, SDK oficial de Python) para practicar evaluación de seguridad contra una máquina virtual de laboratorio (VulnHub u otra). Valida el OWASP Top 10, escanea red y protocolo, y guía al estudiante paso a paso.
Regla de oro: el MCP describe vulnerabilidades y sugiere acercamientos, pero nunca las explota. Los hallazgos se entregan en el chat y se guardan como reporte Markdown en el directorio desde donde se invocó el MCP. Úsalo solo en laboratorios propios o con autorización explícita.
python -m venv .venv
.venv\Scripts\python -m pip install -e .
copy .env.example .envEdita .env con los datos del laboratorio (ver comentarios en .env.example):
MCPFP_TARGET_HOST: IP/host de la VM.
MCPFP_AUTHORIZED=true: confirma que tienes permiso (obligatorio para operar).
MCPFP_PORT_RANGE, MCPFP_REPORT_DIR, credenciales de lab (opcionales).
Nunca subas .env a un repositorio.
Herramientas externas recomendadas (el MCP valida su existencia y sugiere cómo
instalarlas): nmap, nikto, whatweb, openssl, curl, dig.
Related MCP server: VibeDefender MCP Server
Correrlo manualmente (stdio), invocando el módulo del servidor:
.venv\Scripts\python -m mcpfp.serverPara registrarlo en Claude Code:
claude mcp add mcpfp -s user -- "<ruta>\.venv\Scripts\python.exe" -m mcpfp.servero para otro cliente MCP (Claude Desktop, etc.), agrega este bloque a la config
de mcpServers del cliente, ajustando las rutas a tu máquina:
{
"mcpServers": {
"mcpfp": {
"command": "C:\\ruta\\a\\MCPFP\\.venv\\Scripts\\python.exe",
"args": ["-m", "mcpfp.server"],
"cwd": "C:\\ruta\\a\\MCPFP"
}
}
}cwd define dónde se escribe el reporte Markdown (por defecto en reports/).
Tool | Descripción | ¿Explota? |
| Carga y valida el objetivo del | No |
| Verifica herramientas externas y sugiere instalación | No |
| Puertos/servicios/versiones (nmap no intrusivo) | No |
| Cabeceras de seguridad HTTP | No |
| Certificado y protocolo TLS | No |
| Fingerprinting + mapeo OWASP Top 10 | No |
| Tutor: acercamientos obvios y no obvios | No |
| Guarda hallazgos en Markdown en el cwd | No |
Además, el prompt MCP metodologia describe el flujo completo.
src/mcpfp/guardrails.py aplica lista blanca de binarios y lista negra de
argumentos intrusivos (exploit, brute, dos, dump, etc.). Herramientas de
explotación (sqlmap, hydra, metasploit, …) están prohibidas.
skills/ciberseguridad-owasp-iso27001/SKILL.md: metodología de abordaje
defensivo siguiendo OWASP + ISO/IEC 27001.
src/mcpfp/
├── server.py # FastMCP: tools, prompt
├── config.py # objetivo único desde .env
├── guardrails.py # anti-explotación
├── tools/ # environment, recon, protocol, web_owasp, guidance, report
└── knowledge/ # referencias OWASP / protocolo
skills/ # Skill de Claude (OWASP + ISO 27001)Herramienta educativa y defensiva. El uso contra sistemas sin autorización es ilegal. El autor y los contribuyentes no se responsabilizan del mal uso.
Evalua las cabeceras de seguridad HTTP del objetivo.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| use_https | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. 'Evalua' suggests read-only assessment, but it does not disclose that the tool likely makes HTTP requests to the target, the role of port/use_https, or any potential network impact. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff, which is concise. However, it is under-specified for a tool with two parameters and no annotations; a slightly longer description with usage or parameter context would be more appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, 0% parameter coverage, and a security-scanning context, the description is far too minimal. It omits how port and use_https affect the scan, whether the tool is active or passive, and any target prerequisites, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not mention port or use_https at all. The parameter names and defaults are somewhat self-explanatory, yet the description adds no semantic meaning beyond what the schema's titles and defaults already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Evalua' and a clear resource 'cabeceras de seguridad HTTP del objetivo', making the tool's function apparent. It is implicitly distinct from sibling analyze_tls, which targets TLS rather than HTTP headers, but it does not explicitly differentiate itself from any sibling.
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?
There is no guidance on when to use this tool compared to alternatives such as analyze_tls or assess_owasp. No prerequisites, target context, or exclusions are mentioned, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspecciona el certificado y protocolo TLS del objetivo.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Inspect' suggests a non-destructive operationcca and clarifies what is examined, but it does not disclose whether an active network connection is made, whether credentials are needed, or what side effects might occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and object, and contains no wasted words. It is slightly under-specified rather than verbose, which prevents a top score.
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?
The tool is simple, with one optional parameter and an output schema, so return values are covered elsewhere. However, the description lacks usage context, port semantics, and behavioral caveats, leaving gaps that the agent must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the optional 'port' parameter or explain how it is used. The default of 443 and the property name provide partial inference, but the description adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Inspecciona') and a specific resource ('certificado y protocolo TLS del objetivo'). It clearly identifies the tool's focus as TLS inspection, which distinguishes it from siblings like analyze_http_headers, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as a loaded target or a specific port. The usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fingerprinting web y mapeo pasivo a OWASP Top 10.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| use_https | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It does disclose the key trait of passivity ('mapeo pasivo') and that the operation is fingerprinting/reconnaissance, which is meaningful. It omits target preconditions, potential side effects, and any environment requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler, and the key concepts are front-loaded. Brevity is achieved, though at the cost of some clarity and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and there are only two simple parameters, the definition is close to adequate. However, it does not explain that the target itself is not a parameter, so an agent is left to infer that target information must come from elsewhere, such as load_target_info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention port or use_https at all. The parameter names and defaults are self-explanatory, but the description adds no semantic value and fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (web) and the framework (OWASP Top 10) and states the method (fingerprinting/passive mapping), making the tool's role reasonably distinct from active scanning or header analysis. However, it is a noun phrase rather than an explicit verb statement, and it does not directly contrast with sibling tools.
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?
There is no guidance about when to use assess_owasp versus scan_network, analyze_http_headers, or analyze_tls. The word 'pasivo' weakly implies a non-active reconnaissance context, but no explicit when/when-not conditions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifica que herramientas externas de reconocimiento estan instaladas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure. It states that a check occurs but does not specify what exactly is inspected, whether the operation is side-effect free, or what a failure means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that delivers the core purpose without filler. The key verb and object are front-loaded.
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?
With zero parameters and an output schema present, the description does not need to explain return values. However, it does not identify which specific external reconnaissance tools are checked or give any workflow context, leaving moderate room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information needed beyond the schema. With no params, the baseline of 4 applies and the description does not need to compensate for undocumented arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verifica') and resource ('herramientas externas de reconocimiento estan instaladas'), making the tool's purpose clear. It is easily distinguishable from sibling tools like scan_network or analyze_http_headers.
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?
There is no guidance about when to call this tool versus alternatives, such as running it before other reconnaissance steps. The intended workflow position is only implicit from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guia pedagogica paso a paso (obvios / no obvios / siguiente paso).
Temas: reconocimiento, a01, a02, a05, a06, bandera.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does disclose that the output is a pedagogical guide and lists topics, but it does not clarify whether the tool reads environment state, has side effects, or what the structure of the guidance actually is beyond the cryptic labels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core purpose. The parenthetical notation is compact and slightly cryptic, but there is no wasted text.
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?
For a single-parameter tool with an output schema, the description is minimally adequate, but it lacks when-to-use guidance and definitions of the topic codes. An agent can call the tool with a plausible topic, but may not know exactly what to expect or when it is the right choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'topic' as a bare string with 0% description coverage, so the description is the sole source of valid values. Listing 'reconocimiento, a01, a02, a05, a06, bandera' is genuinely useful, though it does not define each code or state explicitly that these are the allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool provides a step-by-step pedagogical guide and enumerates supported topics, which gives the agent a reasonable idea of what it does. However, the meaning of 'obvios / no obvios / siguiente paso' is cryptic, and it does not explicitly differentiate it from siblings beyond being guidance-oriented.
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?
There is no guidance on when to use this tool versus the siblings like load_target_info, assess_owasp, or write_report. The topic list hints at scope, but no selection conditions, exclusions, or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Carga y valida el objetivo unico desde .env, confirmando autorizacion.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does communicate that the tool reads from .env, validates the target, and checks authorization. However, it does not state whether the operation is read-only, what happens if validation or authorization fails, or whether there are side effects, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with the main action front-loaded ('Carga y valida') followed by the source and validation purpose. There is no filler or redundancy—every clause earns its place.
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?
For a zero-parameter tool with an output schema, the description covers the essential function: source, validation, and authorization. The output schema likely handles return-value details, so the description adequately supports invocation. Minor omissions like error behavior and timing are secondary given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage is trivially satisfied. Per the baseline for zero-parameter tools, the description adds meaning by clarifying that the target is sourced from .env and that validation and authorization checks occur, which the empty schema cannot convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Carga y valida' (loads and validates) with a clear resource 'objetivo único desde .env' (unique target from .env), plus the purpose of confirming authorization. This makes the tool's function unmistakable. It does not explicitly contrast with siblings like check_environment or scan_network, but the resource/action combination is specific enough to stand apart.
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?
There is no guidance about when to use this tool versus any alternative. The description only states what it does, without mentioning prerequisites, typical invocation context, or exclusions. An agent must infer the appropriate use case from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Descubre puertos y servicios del objetivo (nmap no intrusivo).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the scan is non-intrusive and uses nmap, which are valuable safety signals. However, it does not mention potential side effects like network noise, detectability, or permission requirements, leaving part of the behavioral profile undisclosed.
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?
A single, well-structured sentence conveys the action, target, and method with no filler. The key terms are front-loaded, making the purpose immediately recognizable.
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?
For a zero-parameter tool with an output schema, this description covers the essential what, how, and safety indication. It lacks explicit guidance on where this fits in the workflow, but that gap is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter semantics are needed; the description adds no parametric confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Descubre'), a clear resource ('puertos y servicios del objetivo'), and the method ('nmap'), making the tool's purpose immediately understandable. It distinguishes itself from sibling analysis/guidance tools by focusing on active network discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied: scan the target's ports/services before deeper analysis like HTTP header or TLS inspection. However, there is no explicit statement of when to use this tool vs. others, nor any mention of prerequisites or contexts where scanning would not be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guarda hallazgos en un reporte Markdown en el directorio de invocacion.
| Name | Required | Description | Default |
|---|---|---|---|
| append | No | ||
| findings | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral disclosure burden. It discloses that a Markdown report is written in the invocation directory, but it omits the append/overwrite behavior and file naming, which are important side effects for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to the core purpose and output location.
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?
For a tool with an append parameter and no annotations, the description leaves key invocation details unexplained, such as whether reports accumulate across calls or overwrite previous content. The output schema helps with return values but not with file side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It echoes 'findings' as 'hallazgos' but adds no meaning for the append parameter or the expected format of the findings string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Guarda hallazgos') and a specific resource ('reporte Markdown en el directorio de invocacion'). It clearly differentiates this tool from the sibling analysis tools, none of which write a report.
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?
Usage is implied: call this tool to persist findings as a Markdown report after analysis. However, there is no explicit when-to-use guidance, no mention of alternatives, and no explanation of how repeated calls interact with the append parameter.
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.
v0.1.0analyze_http_headersanalyze_tlsassess_owaspcheck_environmentget_guidanceload_target_infoscan_networkwrite_reportScored across 8 tools
Each tool targets a distinct stage or concern: target setup, environment checks, network scanning, HTTP header analysis, TLS inspection, OWASP mapping, guidance, and reporting. Even the two analyze tools are clearly separated by layer, so no agent should confuse one tool for another.
All tool names follow a consistent snake_case verb_noun pattern: load_, check_, scan_, analyze_, assess_, get_, and write_. The verb clearly signals the action and the noun signals the target, making the naming predictable and easy to extend.
Eight tools is a well-scoped set for a reconnaissance and OWASP assessment workflow. Each tool has a clear responsibility and no tool feels redundant or extraneous.
The workflow is complete for the stated passive-assessment and pedagogical purpose: it covers target validation, environment readiness, network discovery, HTTP/TLS inspection, OWASP mapping, guidance, and report generation. There are no obvious dead ends or missing core operations.
Offline methodology engine for authorized penetration testing, CTF, and security research.
Scan a website for vulnerabilities: OWASP Top 10, CVEs, SSL, headers - with plain-English fixes
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
DNS resolution, HTTP security headers, and SPF/DMARC email hygiene audits.
