Servidor MCP que conecta la ingeniería inversa de Ghidra con herramientas de IA: 256 herramientas para descompilación, emulación P-code, depuración en vivo, análisis de flujo de datos, operaciones por lotes y aplicación de convenciones en modos headless y GUI.
# Servidor Ghidra MCP
[](https://mcptoplist.com/server/glama%2Fbethington%2Fghidra-mcp)
[](https://github.com/bethington/ghidra-mcp/actions/workflows/tests.yml)
[](https://github.com/bethington/ghidra-mcp/releases/latest)
[](LICENSE)
[](https://github.com/sponsors/bethington)
[](https://www.python.org/)
[](https://openjdk.org/projects/jdk/21/)
[](https://ghidra-sre.org/)
[](https://modelcontextprotocol.io/)
[](https://github.com/bethington/ghidra-mcp/stargazers)
[](https://github.com/bethington/ghidra-mcp/commits/main)
[](https://github.com/bethington/ghidra-mcp/discussions)
[](https://github.com/bethington/ghidra-mcp/issues)
[](https://scorecard.dev/viewer/?uri=github.com/bethington/ghidra-mcp)
> Si te resulta útil, por favor dale una ⭐ al repositorio — ¡ayuda a que otros lo descubran!
>
> Si Ghidra MCP te ahorra tiempo, considera [patrocinar el proyecto](https://github.com/sponsors/bethington). Tanto el apoyo puntual como el recurrente ayudan a financiar las actualizaciones de compatibilidad, el endurecimiento para producción, la documentación y las nuevas herramientas.
Un servidor Model Context Protocol (MCP) listo para producción que conecta las potentes capacidades de ingeniería inversa de Ghidra con herramientas de IA modernas y frameworks de automatización. **219 herramientas MCP**, flujos de trabajo de IA probados en batalla y la integración Ghidra-MCP más completa disponible — ahora incluyendo emulación de P-code, integración con depurador en vivo y análisis de flujo de datos mediante grafos PCode.
## Inicio rápido: instalar una versión publicada (sin clonar, sin compilar)
Cada [versión publicada](https://github.com/bethington/ghidra-mcp/releases) incluye las dos
piezas que necesitas: la extensión de Ghidra (`GhidraMCP-<version>.zip`) y el puente
MCP (`ghidra_mcp_bridge-<version>-py3-none-any.whl`).
1. **Instala los requisitos previos:** [Ghidra 12.1.4](https://github.com/NationalSecurityAgency/ghidra/releases),
Java 21 y [uv](https://docs.astral.sh/uv/getting-started/installation/).
La extensión solo se carga en la versión exacta de Ghidra para la que fue compilada.
2. **Instala la extensión:** en la ventana de proyecto de Ghidra, **File > Install
Extensions**, haz clic en **+**, selecciona el `GhidraMCP-<version>.zip` que descargaste
y reinicia Ghidra.
3. **Habilita el plugin:** en la ventana de proyecto, **File > Configure >
Utility > Configure**, marca **GhidraMCPPlugin**. Comprueba que responde:
```bash
curl http://127.0.0.1:8089/check_connection
# {"status": "ok", "server_kind": "gui", "version": "7.0.0"}
```
4. **Instalar el puente** (copie el enlace del wheel desde la misma página de la versión):
```bash
uv tool install https://github.com/bethington/ghidra-mcp/releases/download/v7.0.0/ghidra_mcp_bridge-7.0.0-py3-none-any.whl
```
5. **Apunte su cliente MCP hacia él**, usando la ruta absoluta (`which
bridge-mcp-ghidra`, o `where.exe bridge-mcp-ghidra` en Windows):
```json
{
"mcpServers": {
"ghidra-mcp": { "command": "/home/<you>/.local/bin/bridge-mcp-ghidra" }
}
}
```
En Windows: `"command": "C:\\Users\\<you>\\.local\\bin\\bridge-mcp-ghidra.exe"`.
Un cliente lanzado desde una GUI o un servicio no ve el PATH de tu shell,
por lo que un `bridge-mcp-ghidra` sin ruta falla con `spawn ENOENT`.
Abre un programa en Ghidra y pide a tu herramienta de IA que liste sus funciones. Capturas de pantalla
de los pasos 2-3: [docs/INSTALL_GUI.md](https://github.com/bethington/ghidra-mcp/blob/dev/docs/INSTALL_GUI.md). La compilación desde el código fuente,
Docker, los transportes HTTP y todas las opciones de bridge se explican más abajo.
**¿Qué versión debería ejecutar?** Las versiones etiquetadas (7.0.0, 7.1.0, ...) son
estables. Las versiones candidatas y `main` son beta: con todas las funciones y probadas en vivo, pero las formas aún pueden cambiar antes de la versión final. `dev` es experimental:
las herramientas se fusionan, renombran y refactorizan allí libremente, así que no construyas nada sobre su
API.
## ¿Por qué Ghidra MCP?
La mayoría de las implementaciones de Ghidra MCP te ofrecen un puñado de herramientas de solo lectura y ya está. Este proyecto es diferente: fue creado por un ingeniero inverso que lo usa a diario en binarios reales, no como una demo.
- **219 herramientas MCP** — 3 veces más que cualquier implementación competidora. No solo operaciones de lectura: acceso completo de escritura para renombrar, tipar, comentar, crear estructuras, ejecutar scripts, emulación de P-code y depuración en vivo.
- **Flujos de trabajo de IA probados en batalla** — Flujos de documentación probados (V5) refinados a lo largo de cientos de funciones. Incluye prompts paso a paso, referencia de notación húngara, guías de procesamiento por lotes y descubrimiento de código huérfano.
- **Fiabilidad de nivel de producción** — Transacciones atómicas, operaciones por lotes (93% de reducción en llamadas a la API), tiempos de espera configurables y manejo de errores elegante. Sin fallos silenciosos.
- **Transferencia de documentación entre binarios** — La coincidencia de hash de función SHA-256 propaga la documentación entre versiones de binarios automáticamente. Documenta una vez, aplica en todas partes.
- **Integración completa con Ghidra Server** — Conéctate a servidores Ghidra compartidos, gestiona repositorios, control de versiones, flujos de checkout/checkin y colaboración multiusuario.
- **Modos headless y GUI** — Ejecuta con o sin la GUI de Ghidra. Listo para Docker en pipelines de CI/CD y análisis automatizado a escala.
- **Con criterio por diseño** — v5.0 traslada las convenciones de nomenclatura, la seguridad de tipos y los estándares de documentación a la capa de herramientas. Los agentes de IA y los ingenieros humanos producen resultados consistentes sin guías de estilo en cada prompt.
## Aplicación de convenciones
Ya lo has vivido: seis meses dentro de un proyecto encuentras `ProcessItem`, `process_items`, `handleItem` e `ItemProc` en el mismo código base — cuatro funciones que hacen lo mismo, nombradas por cuatro sesiones o ingenieros distintos sin un contrato compartido. Arreglarlo lleva más tiempo del que debería, y el problema volverá a ocurrir.
v5.0 traslada las convenciones de "cosas que recordar" a la capa de herramientas, donde realmente se pueden aplicar.
| Nivel | Comportamiento | Ejemplo |
| ------ | ---------- | --------- |
| **Corrección automática** | Se aplica silenciosamente | Campo `count` en un `uint32` → se añade automáticamente el prefijo `dwCount` al guardar |
| **Advertencia** | El cambio se aplica, se devuelve una advertencia | `processData` → "el nombre debería ser PascalCase con un verbo: `ProcessData`" |
| **Rechazo** | El cambio se bloquea con una explicación | Cambio de tipo `undefined → undefined` → "no-op rechazado, tipo sin cambios" |
**Para los agentes de IA**, esto significa una salida consistente en cada sesión, cada modelo, cada ejecución — sin pegar una guía de estilo en cada prompt. La herramienta conoce las reglas; el modelo solo necesita hacer la llamada.
**Para los equipos**, elimina toda la clase de comentarios de revisión que dicen "esa no es nuestra convención de nomenclatura". El arbitraje de convenciones se queda en la herramienta, no en la revisión de código.
**Para el trabajo en solitario a escala**, `analyze_function_completeness` te da una puntuación de 0–100% que mide con honestidad: las deducciones estructurales (artefactos del compilador que no se pueden corregir) se perdonan en tu puntuación efectiva, el escalado logarítmico evita que una categoría mala entierre todo lo demás, y la calidad por niveles de los comentarios de placa significa que sabes exactamente qué falta y por qué.
## 🌟 Características
### Integración central de MCP
- **Compatibilidad total con MCP** — Implementación completa del Model Context Protocol
- **219 herramientas MCP** — Superficie de API integral que cubre todos los aspectos del análisis de binarios
- **Fiabilidad lista para producción** — Transacciones atómicas, operaciones por lotes, tiempos de espera configurables
- **Análisis en tiempo real** — Integración en vivo con el motor de análisis de Ghidra
> **Nota de compatibilidad:** Los nombres de las herramientas MCP se normalizan para GitHub Copilot CLI
> y la validación de CAPI. Los nombres de herramientas expuestos usan solo letras minúsculas, dígitos,
> guiones bajos y guiones; las rutas HTTP anidadas como `/debugger/status`
> se anuncian como nombres como `debugger_status_2` cuando es necesario para evitar
> colisiones con las herramientas de puente estáticas.
### Capacidades de análisis de binarios
- **Análisis de funciones** — Descompilación, grafos de llamadas, referencias cruzadas, puntuación de completitud
- **Análisis de flujo de datos** — Propagación de valores mediante grafos PCode (hacia adelante / hacia atrás) desde cualquier variable o registro
- **Descubrimiento de estructuras de datos** — Creación de struct/union/enum con análisis de campos y sugerencias de nombres
- **Extracción de cadenas** — Búsqueda con regex, filtrado de calidad y descubrimiento de funciones anclado a cadenas
- **Análisis de importaciones/exportaciones** — Tablas de símbolos, ubicaciones externas, resolución de importaciones por ordinal
- **Inspección de memoria y datos** — Lecturas de memoria en bruto, búsqueda de patrones de bytes, detección de límites de arrays
- **Documentación entre binarios** — Coincidencia de hashes de funciones y propagación de documentación entre versiones
### Análisis dinámico (v5.4.0)
- **Emulación de P-code** — Ejecuta cualquier función de forma aislada mediante `EmulatorHelper` de Ghidra; resolución de hashes de API por fuerza bruta en milisegundos
- **Integración con depurador en vivo** — 16 endpoints `/debugger/*` sobre el framework TraceRmi de Ghidra (solo plugin de GUI; dbgeng en Windows PE, gdb/lldb en caso contrario): lanzar, interrumpir/reanudar, step into/over/out, breakpoints, registros, lecturas de memoria, trazas de pila, traducción de direcciones estáticas↔dinámicas con reconocimiento de ASLR. El puente también puede hacer proxy de 22 herramientas `debugger_*` a un servidor de depuración externo; son opcionales (ver [más abajo](#optional-connect-an-external-debugger-server))
### Flujos de trabajo de ingeniería inversa impulsados por IA
- **Flujo de trabajo de documentación de funciones V5** — Proceso de 7 pasos para la documentación completa de funciones con notación húngara, auditoría de tipos y puntuación de verificación automatizada
- **Documentación por lotes** — Despacho paralelo de subagentes para documentar múltiples funciones simultáneamente
- **Descubrimiento de código huérfano** — Escáner automatizado que encuentra funciones no descubiertas en los huecos entre código conocido
- **Investigación de tipos de datos** — Flujos de trabajo sistemáticos para el descubrimiento de estructuras y el análisis de campos
- **Coincidencia entre versiones** — Coincidencia de funciones basada en hash entre diferentes versiones de binarios
### Desarrollo y automatización
- **Ejecución de scripts de Ghidra** — Lista y ejecuta scripts de Ghidra, o ejecuta código de script en línea, vía MCP (ejecutarlos es opcional: `GHIDRA_MCP_ALLOW_SCRIPTS=1`)
- **Soporte multiprograma** — Cambia entre y compara múltiples programas abiertos
- **Operaciones por lotes** — Renombrado, comentarios, tipado y gestión de etiquetas en masa (93% menos llamadas a la API)
- **Servidor headless** — Análisis completo sin la GUI de Ghidra — listo para Docker y CI/CD
- **Proyectos y control de versiones** — Crea proyectos, gestiona archivos, integración con Ghidra Server
- **Control del análisis** — Lista, configura y activa analizadores de Ghidra mediante programación
## 🚀 Instalar desde el código fuente
El [Inicio rápido](#quickstart-install-a-release-no-clone-no-build) anterior no necesita
nada de esto. Compila desde el código fuente para ejecutar `dev`, para contribuir o para usar
`python -m tools.setup deploy`, que instala, configura y reinicia Ghidra
por ti.
### Requisitos previos
- **Java 21 LTS** (se recomienda OpenJDK)
- **Apache Maven 3.9+** para los comandos `python -m tools.setup` a continuación (Maven es su backend predeterminado). No es necesario si compilas con el wrapper de Gradle incluido en su lugar — ver paso 6
- **Ghidra 12.1.4** (o versión compatible)
- **Python 3.10+** con [uv](https://docs.astral.sh/uv/) (recomendado) o pip + venv
> Usuarios de un Ghidra Server compartido: los clientes de Ghidra 12.1.4 requieren un Ghidra
> Server en 12.1, 12.0.5 o una versión compatible más reciente. Actualice el
> servidor antes de usar este plugin desde un cliente 12.1.
>
> Ghidra 12.1.4 incluye Jython como una extensión opcional. Los scripts Java funcionan
> de forma predeterminada, pero los scripts `.py` en `ghidra_scripts/` requieren instalar
> la extensión Jython desde **File > Install Extensions** y reiniciar
> Ghidra.
### Instalación
> Recomendado para todas las plataformas: use `python -m tools.setup` directamente.
>
> `ensure-prereqs` instala los requisitos de Python en tiempo de ejecución además de los JAR de Ghidra necesarios en el repositorio Maven local.
> `deploy` copia la salida de la compilación, instala la extensión del perfil de usuario y aplica parches a la configuración de usuario de Ghidra.
1. **Clone el repositorio:**
```bash
git clone https://github.com/bethington/ghidra-mcp.git
cd ghidra-mcp
```
2. **Recomendado: ejecutar primero la verificación previa del entorno:**
```text
python -m tools.setup preflight --ghidra-path "F:\ghidra_12.1.4_PUBLIC"
```
3. **Compilar y desplegar en Ghidra:**
```text
python -m tools.setup ensure-prereqs --ghidra-path "F:\ghidra_12.1.4_PUBLIC"
python -m tools.setup build
python -m tools.setup deploy --ghidra-path "F:\ghidra_12.1.4_PUBLIC"
```
`deploy` guarda/cierra una instancia de Ghidra coincidente que ya está en ejecución cuando
es necesario, instala la extensión, inicia Ghidra, espera la salud de MCP y ejecuta
comprobaciones de humo del esquema.
¿Prefieres hacer clic a través de los propios diálogos de Ghidra, o instalar un zip de versión
en una máquina sin el repositorio? Sigue la
[guía de instalación manual por GUI ilustrada](https://github.com/bethington/ghidra-mcp/blob/dev/docs/INSTALL_GUI.md).
4. **Modo estricto/manual opcional** (avanzado):
```text
# Skip automatic prerequisite setup
python -m tools.setup build
python -m tools.setup deploy --ghidra-path "F:\ghidra_12.1.4_PUBLIC"
```
5. **Mostrar la ayuda del comando**:
```text
python -m tools.setup --help
```
6. **Modo opcional de solo compilación** (avanzado/solución de problemas):
```text
python -m tools.setup build
```
Se admiten dos backends de Java. **Gradle es el predeterminado para el trabajo local** — lee los jars de Ghidra directamente desde la instalación, por lo que no hay un paso `install-file` ni nada que instalar más allá de un JDK. **CI compila y valida con Maven**, por lo que Maven es un par mantenido en lugar de una alternativa.
```bash
# Gradle (default) -- the wrapper is committed, so no Gradle install is needed.
# -PGHIDRA_INSTALL_DIR or the GHIDRA_INSTALL_DIR env var both work.
# In Git Bash use forward slashes; a backslash path is mangled before Gradle sees it.
./gradlew buildExtension -PGHIDRA_INSTALL_DIR=/path/to/ghidra
```
```bash
# Maven (peer backend; what CI uses). Needs Ghidra's jars in the local .m2 first:
# python -m tools.setup ensure-prereqs --ghidra-path /path/to/ghidra
mvn clean package assembly:single -DskipTests
```
`python -m tools.setup build` se dirige a Maven por defecto; establezca `TOOLS_SETUP_BACKEND=gradle` para dirigirlo a Gradle en su lugar.
### Instalación (Linux — Ubuntu/Debian)
1. **Clonar el repositorio:**
```bash
git clone https://github.com/bethington/ghidra-mcp.git
cd ghidra-mcp
```
2. **Instalar los requisitos previos del sistema** (si aún no están instalados):
```bash
sudo apt update && sudo apt install -y openjdk-21-jdk maven python3 python3-pip python3-venv curl jq unzip
```
> **Nota para Debian/Kali/Ubuntu 23.04+ (PEP 668):** estas distribuciones marcan el Python del sistema como *gestionado externamente*, por lo que un `pip install` sin más falla con
> `error: externally-managed-environment`. No lo sortees con
> `--break-system-packages` — puede corromper las herramientas gestionadas por apt. En su lugar usa
> [uv](https://docs.astral.sh/uv/) (recomendado — crea y gestiona un
> `.venv` local al proyecto automáticamente, y es lo que usan los comandos de este repo):
>
> ```bash
> curl -LsSf https://astral.sh/uv/install.sh | sh
> uv run bridge-mcp-ghidra # resolves deps into .venv and starts the bridge
> ```
>
> o un entorno virtual clásico:
>
> ```bash
> python3 -m venv .venv && source .venv/bin/activate
> pip install -e .
> bridge-mcp-ghidra
> ```
3. **Ejecuta la verificación previa del entorno:**
```bash
python -m tools.setup preflight --ghidra-path ~/ghidra_12.1.4_PUBLIC
```
4. **Compilar y desplegar en Ghidra (un solo comando):**
```bash
python -m tools.setup ensure-prereqs --ghidra-path ~/ghidra_12.1.4_PUBLIC
python -m tools.setup build
python -m tools.setup deploy --ghidra-path ~/ghidra_12.1.4_PUBLIC
```
Esto hará lo siguiente:
- Instalar las dependencias JAR de Ghidra en tu `~/.m2/repository` local
- Compilar `GhidraMCP-<version>.zip` con Maven
- Extraer la extensión a `~/.config/ghidra/ghidra_<version>_PUBLIC/Extensions/`
- Actualizar `preferences` con `LastExtensionImportDirectory`
- Instalar los requisitos de Python
5. **Opcional: configurar solo las dependencias de Maven:**
```bash
python -m tools.setup install-ghidra-deps --ghidra-path ~/ghidra_12.1.4_PUBLIC
```
6. **Mostrar la ayuda del comando:**
```bash
python -m tools.setup --help
```
> **Rutas de Linux:** La extensión se instala en `$HOME/.config/ghidra/ghidra_<version>_PUBLIC/Extensions/GhidraMCP/`.
> Los archivos de configuración de Ghidra están en `$HOME/.config/ghidra/ghidra_<version>_PUBLIC/`.
### Instalación (macOS — Homebrew)
1. **Instalar los requisitos previos:**
```bash
brew install openjdk@21 maven python ghidra
```
2. **Clona el repositorio:**
```bash
git clone https://github.com/bethington/ghidra-mcp.git
cd ghidra-mcp
```
3. **Instalar los JARs de Ghidra en el Maven local:**
```bash
python -m tools.setup install-ghidra-deps \
--ghidra-path /opt/homebrew/opt/ghidra/libexec
```
4. **Compilar y desplegar:**
```bash
python -m tools.setup ensure-prereqs \
--ghidra-path /opt/homebrew/opt/ghidra/libexec
python -m tools.setup build
python -m tools.setup deploy \
--ghidra-path /opt/homebrew/opt/ghidra/libexec
```
La extensión se instala en `~/Library/ghidra/ghidra_12.1.4_PUBLIC/Extensions/GhidraMCP/`.
> **Nota:** la ruta de Homebrew no contiene ninguna cadena de versión, por lo que `tools.setup` lee la versión de Ghidra desde `Ghidra/application.properties` dentro de la instalación.
5. **Inicia Ghidra y habilita el plugin:**
```bash
/opt/homebrew/opt/ghidra/libexec/ghidraRun
```
El servidor se inicia con el plugin. Compruébalo desde la ventana del proyecto:
**Tools > GhidraMCP > Server Status**
6. **Configurar Cursor/Claude MCP** (`~/.cursor/mcp.json`) — usa la **ruta
absoluta** a `uv` (`which uv`), no el nombre simple; los clientes lanzados desde la GUI no
heredan el PATH de tu shell ([#441](https://github.com/bethington/ghidra-mcp/issues/441)):
```json
{
"mcpServers": {
"ghidra": {
"command": "/opt/homebrew/bin/uv",
"args": ["run", "--directory", "/path/to/ghidra-mcp", "bridge-mcp-ghidra"]
}
}
}
```
macOS es el caso más claro: las aplicaciones iniciadas desde Finder/Dock obtienen el PATH de `launchd`, que nunca contiene `~/.local/bin` ni `/opt/homebrew/bin`.
### Instalación (Arch Linux — AUR)
[@Pandoriaantje](https://github.com/Pandoriaantje) mantiene paquetes AUR de la comunidad:
- [`ghidra-mcp-git`](https://aur.archlinux.org/packages/ghidra-mcp-git) — sigue `main`
- [`ghidra-mcp`](https://aur.archlinux.org/packages/ghidra-mcp) — sigue las versiones etiquetadas
Instala con tu asistente AUR preferido, por ejemplo:
```bash
yay -S ghidra-mcp # or ghidra-mcp-git
```
### Uso básico
#### Opción 1: Transporte Stdio (recomendado para herramientas de IA)
```bash
uv run bridge-mcp-ghidra # or: python -m bridge_mcp_ghidra
```
Configuración del cliente MCP (`.mcp.json`, `~/.cursor/mcp.json`, configuración de Claude Desktop, …).
**Utiliza la ruta absoluta a `uv`** — consulta la nota a continuación para saber por qué:
```json
{
"mcpServers": {
"ghidra-mcp": {
"command": "/home/<you>/.local/bin/uv",
"args": ["run", "--directory", "/path/to/ghidra-mcp", "bridge-mcp-ghidra", "--transport", "stdio"],
"env": { "GHIDRA_MCP_URL": "http://127.0.0.1:8089" }
}
}
}
```
En Windows, la misma configuración apunta a `uv.exe`, por ejemplo
`"command": "C:\\Users\\<you>\\.local\\bin\\uv.exe"`. Encuentra tu propia ruta con
`which uv` (POSIX) o `where.exe uv` (Windows), o simplemente ejecuta
`python -m tools.setup preflight`, que imprime la ruta absoluta resuelta y un
fragmento listo para pegar.
> **¿Por qué absoluta? `"command": "uv"` falla con lanzadores de servicios y de GUI.**
> El cliente MCP resuelve `command` con **su propio** PATH, no con el de tu shell. Un
> cliente iniciado desde un **servicio de usuario de systemd**, una entrada `.desktop` o cualquier
> otra sesión de GUI hereda el entorno de ese lanzador, que habitualmente carece de
> `~/.local/bin` y `~/.cargo/bin` — precisamente los directorios en los que se instala `uv`.
> El fallo se produce en el momento de generar el proceso como `spawn uv ENOENT`, antes de que se ejecute
> cualquier código del puente, así que no hay nada que leer en ningún registro. Una ruta absoluta
> hace que el PATH del cliente sea irrelevante y funciona al primer intento. Lo mismo
> se aplica a `python`, `python3` y el script de consola `bridge-mcp-ghidra`.
> ([#441](https://github.com/bethington/ghidra-mcp/issues/441))
Para añadir el puente a [Autohand Code](https://github.com/autohandai/code-cli/) desde un checkout clonado:
```bash
autohand mcp add ghidra /home/<you>/.local/bin/uv run --directory /path/to/ghidra-mcp bridge-mcp-ghidra
```
Añade `--scope project` antes de `ghidra` para guardar el servidor en la configuración `.autohand` del proyecto actual en lugar de tu configuración de usuario.
#### Opción 2: Transporte HTTP transmitible (recomendado para clientes web/HTTP)
```bash
uv run bridge-mcp-ghidra --transport streamable-http --mcp-host 127.0.0.1 --mcp-port 8081
```
Configuración del cliente MCP para el transporte HTTP (añadir al archivo de configuración MCP de tu cliente):
```json
{
"mcpServers": {
"ghidra-mcp-http": {
"url": "http://127.0.0.1:8081/mcp"
}
}
}
```
Los clientes basados en navegador (p. ej., [MCP Inspector](https://github.com/modelcontextprotocol/inspector)) funcionan sin configuración adicional: los transportes HTTP responden a las solicitudes de verificación previa CORS (`OPTIONS`) y exponen los encabezados `mcp-session-id` / `mcp-protocol-version` a los scripts. Los orígenes permitidos reflejan la política del encabezado Host: el loopback en cualquier puerto siempre está permitido, además del host de enlace y cualquier host listado en `GHIDRA_MCP_ALLOWED_HOSTS`.
`GHIDRA_MCP_ALLOWED_HOSTS` también admite clientes que enrutan un puente vinculado al loopback a través de otro espacio de nombres de red. Por ejemplo, un contenedor puede dirigirse al host como `host.containers.internal` sin exponer el puente en una interfaz LAN:
```bash
GHIDRA_MCP_ALLOWED_HOSTS=host.containers.internal \
uv run bridge-mcp-ghidra --transport streamable-http \
--mcp-host 127.0.0.1 --mcp-port 8081
```
La configuración solo amplía la validación de Host/Origin para DNS-rebinding; no
cambia la dirección de bind ni hace que el listener sea accesible en interfaces adicionales.
#### Opción 3: Transporte SSE (obsoleto — use streamable-http en su lugar)
```bash
uv run bridge-mcp-ghidra --transport sse --mcp-host 127.0.0.1 --mcp-port 8081
```
#### Flags avanzados del bridge
| Flag | Predeterminado | Descripción |
| ------ | --------- | ------------- |
| `--transport` | `stdio` | `stdio` (herramientas de IA), `streamable-http` (clientes web), `sse` (obsoleto) |
| `--mcp-host` | `127.0.0.1` | Host de enlace para transportes HTTP |
| `--mcp-port` | — | Puerto para transportes HTTP |
| `--lazy` | (predeterminado) | Carga solo los grupos de herramientas predeterminados al conectar y deja que el modelo incorpore el resto con `search_tools`/`load_tool_group`. |
| `--project` | sin definir | Nombre exacto del proyecto a seleccionar al iniciar, incluso cuando hay varias instancias en ejecución. Anula `GHIDRA_MCP_PROJECT`. |
| `--no-lazy` | desactivado | Carga todos los grupos de herramientas inmediatamente al conectar. Solo lo necesitan los clientes MCP que ignoran `tools/list_changed`; **rechazado de plano por la API de Gemini** (ver más abajo). |
| `--default-groups` | `listing,function,program` | Grupos separados por comas que se cargan al conectar bajo `--lazy`. |
| `--tools-page-size` | `0` | Sirve `tools/list` en páginas de este tamaño (`0` = una sola página). Solo para un cliente que no puede aceptar una respuesta grande; un cliente que ignora `nextCursor` solo ve la primera página. |
| `--json-response` | desactivado | streamable-http: responde a los POST con JSON simple en lugar de un flujo SSE. Los mensajes iniciados por el servidor, como `tools/list_changed`, entonces no se entregan. |
| `--stateless-http` | desactivado | streamable-http: sin id de sesión y sin notificaciones iniciadas por el servidor, para ejecutar varios workers del bridge detrás de un balanceador de carga. Combínalo con `--no-lazy`, ya que un grupo cargado posteriormente nunca podrá anunciarse. |
Para exigir un token a los clientes MCP de un transporte HTTP, establece
`GHIDRA_MCP_INBOUND_TOKEN=<secret>`; los clientes deberán entonces enviar
`Authorization: Bearer <secret>`. El bridge registra una advertencia cuando enlaza un
`--mcp-host` que no es de loopback sin uno. Por separado, cuando se establece `GHIDRA_MCP_AUTH_TOKEN`
(el token que el bridge envía a Ghidra) y el bridge enlaza un
host que no es de loopback, los clientes deben presentar ese mismo token, de modo que el bridge no
pueda usarse para retransmitirlo.
#### La carga diferida de herramientas es la predeterminada (issue #440)
Anunciar los 220 endpoints en un único `tools/list` supera un límite estricto para
al menos un proveedor importante. Gemini compila las declaraciones de funciones en una
máquina de estados de decodificación restringida y rechaza toda la solicitud antes de que se
llame a cualquier herramienta:
```text
400 INVALID_ARGUMENT
The specified schema produces a constraint that has too many states for serving
```
Eso no es una degradación, es una ruptura total, y ninguna configuración del lado del cliente podría sortear un servidor que solo ofrecía el conjunto completo. Por lo tanto, el puente ahora carga `listing,function,program` (70 endpoints más las 8 herramientas estáticas) al conectarse y registra el resto bajo demanda.
**Si tu cliente ignora `tools/list_changed`**, no notará las herramientas que se registren más tarde, y debería desactivar la carga diferida:
```bash
uv run bridge-mcp-ghidra --no-lazy # when you control the command line
export GHIDRA_MCP_LAZY=0 # when you don't (Docker, uvx, some client configs)
```
`GHIDRA_MCP_LAZY` acepta `0/false/no/off` y `1/true/yes/on`; un `--lazy`/`--no-lazy` explícito en la línea de comandos tiene prioridad sobre él. El arranque registra en el log qué modo está en efecto.
#### Enrutamiento estricto de programas (seguridad multiprograma)
Establezca `GHIDRA_MCP_REQUIRE_PROGRAM_SELECTORS=1` para que el puente rechace cualquier llamada con ámbito de programa que omita un selector de programa, devolviendo un error claro en lugar de permitir que la llamada se apoye en el "programa actual" compartido del servidor (el que mueven `switch_program` y la pestaña activa de la GUI).
```bash
export GHIDRA_MCP_REQUIRE_PROGRAM_SELECTORS=1
uv run bridge-mcp-ghidra
```
Sin esto, una llamada que omite `program=` se ejecuta contra el programa que esté activo en ese momento, lo cual está bien para un flujo de trabajo de un solo programa, pero es un riesgo cuando hay varios programas abiertos: la llamada puede leer o editar el binario equivocado sin producir ningún error. El riesgo es mayor cuando más de un cliente comparte un servidor, ya que cada uno mueve ese global de programa-actual por debajo de los demás.
Con el modo estricto activado, cada llamada con ámbito de programa debe nombrar su objetivo. Esto abarca todos los selectores que eligen un programa abierto: el simple `program=` y los `source_program`/`target_program` o `program_a`/`program_b` de las herramientas entre programas (declarados como obligatorios, pero el servidor aún recurre al programa actual cuando uno llega vacío). Un selector olvidado se manifiesta como un error ruidoso en la primera llamada incorrecta en lugar de una escritura silenciosa en el binario equivocado. Las herramientas sin selector de programa (`open_program` y `close_program` toman `path`/`name`) no se ven afectadas. Desactivado por defecto: con la variable sin definir, el puente envía las llamadas sin cambios.
#### Reducir la sobrecarga del contexto de herramientas
El puente expone un catálogo grande, por lo que solo carga `listing,function,program` al conectarse (ver arriba) y permite que el modelo **descubra** el resto bajo demanda en lugar de registrar todo:
- `search_tools("rename function")` — busca por palabra clave en el catálogo **completo**, incluidas las herramientas cuyo grupo no está cargado. Cada resultado indica si es invocable ahora y, si no lo es, la llamada exacta `load_tool_group(...)` para habilitarla.
- `list_tool_groups()` — lista todas las categorías y su estado de carga.
---
[Read more](https://github.com/bethington/ghidra-mcp)