MCP Proxy Server
proxy mcp
Acerca de
El mcp-proxy es una herramienta que permite cambiar entre transportes de servidor. Se admiten dos modos:
stdio a SSE/StreamableHTTP
SSE a stdio
Related MCP server: MCP SSE Proxy
1. stdio a SSE/StreamableHTTP
Ejecute un servidor proxy desde stdio que se conecte a un servidor SSE remoto.
Este modo permite que clientes como Claude Desktop se comuniquen con un servidor remoto a través de SSE aunque no sea compatible de forma nativa.
graph LR
A["Claude Desktop"] <--> |stdio| B["mcp-proxy"]
B <--> |SSE| C["External MCP Server"]
style A fill:#ffe6f9,stroke:#333,color:black,stroke-width:2px
style B fill:#e6e6ff,stroke:#333,color:black,stroke-width:2px
style C fill:#e6ffe6,stroke:#333,color:black,stroke-width:2px1.1 Configuración
Este modo requiere proporcionar la URL del punto final SSE del servidor MCP como primer argumento del programa. Si el servidor utiliza el transporte HTTP Streamable, asegúrese de aplicarlo en el mcp-proxy mediante --transport=streamablehttp .
Argumentos
Nombre | Requerido | Descripción | Ejemplo |
| Sí | El punto final SSE del servidor MCP al que conectarse | |
| No | Encabezados a utilizar para la conexión SSE del servidor MCP | Autorización 'Portador de mi token de acceso secreto' |
| No | Decide qué protocolo de transporte usar al conectarse a un servidor MCP. Puede ser "sse" o "streamablehttp". | http transmisible |
Variables de entorno
Nombre | Requerido | Descripción | Ejemplo |
| No | Se puede utilizar en lugar de | TU_TOKEN |
1.2 Ejemplo de uso
Se supone que mcp-proxy debe ser iniciado por el cliente MCP, por lo que la configuración debe realizarse en consecuencia.
Para Claude Desktop, la entrada de configuración puede verse así:
{
"mcpServers": {
"mcp-proxy": {
"command": "mcp-proxy",
"args": [
"http://example.io/sse"
],
"env": {
"API_ACCESS_TOKEN": "access-token"
}
}
}
}2. SSE a stdio
Ejecute un servidor proxy que exponga un servidor SSE que se conecta a un servidor stdio local.
Esto permite conexiones remotas al servidor stdio local. El mcp-proxy abre un puerto para escuchar solicitudes SSE y genera un servidor stdio local que gestiona las solicitudes MCP.
graph LR
A["LLM Client"] <-->|SSE| B["mcp-proxy"]
B <-->|stdio| C["Local MCP Server"]
style A fill:#ffe6f9,stroke:#333,color:black,stroke-width:2px
style B fill:#e6e6ff,stroke:#333,color:black,stroke-width:2px
style C fill:#e6ffe6,stroke:#333,color:black,stroke-width:2px2.1 Configuración
Este modo requiere el parámetro --sse-port . El parámetro --sse-host puede especificar la dirección IP del host en el que el servidor SSE escuchará. Se pueden pasar variables de entorno adicionales al servidor stdio local mediante el parámetro --env . Los argumentos de la línea de comandos para el servidor stdio local deben pasarse después del separador -- .
Argumentos
Nombre | Requerido | Descripción | Ejemplo |
| Sí | El comando para generar el servidor stdio de MCP | uvx mcp-server-fetch |
| No, disponible al azar | El puerto del servidor MCP para escuchar | 8080 |
| No, | La dirección IP del host en la que escuchará el servidor MCP | 0.0.0.0 |
| No | Variables de entorno adicionales para pasar al servidor MCP stdio. Se pueden usar varias veces. | BAR DE COMIDA |
| No | El directorio de trabajo que se pasará al proceso del servidor stdio de MCP. | /tmp |
| No | Pasar por todas las variables de entorno al generar el servidor | --entorno sin pase |
| No | Orígenes permitidos para el servidor SSE. Se pueden usar varias veces. CORS no está permitido por defecto. | --permitir-origen "*" |
| No | Habilitar el modo sin estado para los transportes HTTP con transmisión. El valor predeterminado es Falso. | --sin estado |
| No | Define un servidor stdio con nombre. | --named-server fetch 'uvx mcp-server-fetch' |
| No | Ruta a un archivo JSON que define servidores stdio nombrados. | --named-server-config /ruta/a/servidores.json |
| No, disponible al azar | El puerto del servidor SSE para escuchar | 8080 |
| No, | La dirección IP del host en la que escuchará el servidor SSE | 0.0.0.0 |
2.2 Ejemplo de uso
Para iniciar el servidor mcp-proxy que escucha en el puerto 8080 y se conecta al servidor MCP local:
# Start the MCP server behind the proxy
mcp-proxy uvx mcp-server-fetch
# Start the MCP server behind the proxy with a custom port
# (deprecated) mcp-proxy --sse-port=8080 uvx mcp-server-fetch
mcp-proxy --port=8080 uvx mcp-server-fetch
# Start the MCP server behind the proxy with a custom host and port
# (deprecated) mcp-proxy --sse-host=0.0.0.0 --sse-port=8080 uvx mcp-server-fetch
mcp-proxy --host=0.0.0.0 --port=8080 uvx mcp-server-fetch
# Start the MCP server behind the proxy with a custom user agent
# Note that the `--` separator is used to separate the `mcp-proxy` arguments from the `mcp-server-fetch` arguments
# (deprecated) mcp-proxy --sse-port=8080 -- uvx mcp-server-fetch --user-agent=YourUserAgent
mcp-proxy --port=8080 -- uvx mcp-server-fetch --user-agent=YourUserAgent
# Start multiple named MCP servers behind the proxy
mcp-proxy --port=8080 --named-server fetch 'uvx mcp-server-fetch' --named-server fetch2 'uvx mcp-server-fetch'
# Start multiple named MCP servers using a configuration file
mcp-proxy --port=8080 --named-server-config ./servers.jsonServidores con nombre
NAMEse utiliza en la ruta URL/servers/NAME/.COMMAND_STRINGes el comando para iniciar el servidor (por ejemplo, 'uvx mcp-server-fetch').Se puede utilizar varias veces.
Este argumento se ignora si se utiliza
--named-server-config.
FILE_PATH: si se proporciona, esta es la fuente exclusiva para servidores nombrados y se ignoran los argumentos CLI--named-server.
Si se especifica un servidor predeterminado (el argumento command_or_url sin --named-server o --named-server-config ), será accesible en las rutas raíz (por ejemplo, http://127.0.0.1:8080/sse ).
Los servidores con nombre (definidos mediante --named-server o --named-server-config ) serán accesibles en /servers/<server-name>/ (p. ej., http://127.0.0.1:8080/servers/fetch1/sse ). El punto de conexión /status proporciona el estado global.
Formato de archivo de configuración JSON para --named-server-config :
El archivo JSON debe seguir esta estructura:
{
"mcpServers": {
"fetch": {
"disabled": false,
"timeout": 60,
"command": "uvx",
"args": [
"mcp-server-fetch"
],
"transportType": "stdio"
},
"github": {
"timeout": 60,
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"transportType": "stdio"
}
}
}mcpServers: un diccionario donde cada clave es el nombre del servidor (usado en la ruta URL, por ejemplo,/servers/fetch/) y el valor es un objeto que define el servidor.command: (Obligatorio) El comando a ejecutar para el servidor stdio.args: (Opcional) Lista de argumentos para el comando. El valor predeterminado es una lista vacía.enabled: (opcional) Sifalse, se omitirá esta definición de servidor. El valor predeterminado estrue.timeoutytransportType: Estos campos están presentes en las configuraciones estándar de cliente MCP, peromcp-proxylos ignora actualmente al cargar servidores con nombre. El tipo de transporte es implícitamente "stdio".
Instalación
Instalación mediante herrería
Para instalar MCP Proxy para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install mcp-proxy --client claudeInstalación mediante PyPI
La versión estable del paquete está disponible en el repositorio de PyPI. Puede instalarla con el siguiente comando:
# Option 1: With uv (recommended)
uv tool install mcp-proxy
# Option 2: With pipx (alternative)
pipx install mcp-proxyUna vez instalado, puede ejecutar el servidor con el comando mcp-proxy . Consulte las opciones de configuración para cada modo más arriba.
Instalación a través del repositorio de Github (última versión)
La última versión del paquete se puede instalar desde el repositorio git usando el siguiente comando:
uv tool install git+https://github.com/sparfenyuk/mcp-proxy[!NOTA] Si ya ha instalado el servidor, puede actualizarlo utilizando el comando
uv tool upgrade --reinstall.
[!NOTA] Si desea eliminar el servidor, utilice el comando
uv tool uninstall mcp-proxy.
Instalación como contenedor
A partir de la versión 0.3.2, es posible extraer y ejecutar la imagen del contenedor correspondiente:
docker run -t ghcr.io/sparfenyuk/mcp-proxy:v0.3.2-alpine --helpSolución de problemas
Problema : Claude Desktop no puede iniciar el servidor: código ENOENT en los registros
Solución : Intente usar la ruta completa del binario. Para ello, abra una terminal y ejecute el comando
where mcp-proxy(MacOS, Linux) owhere.exe mcp-proxy(Windows). A continuación, use la ruta de salida como valor para el atributo 'command':"fetch": { "command": "/full/path/to/bin/mcp-proxy", "args": [ "http://localhost:8932/sse" ] }
Ampliación de la imagen del contenedor
Puedes ampliar la imagen del contenedor mcp-proxy para incluir ejecutables adicionales. Por ejemplo, uv no está incluido por defecto, pero puedes crear una imagen personalizada con él:
# file: mcp-proxy.Dockerfile
FROM ghcr.io/sparfenyuk/mcp-proxy:latest
# Install the 'uv' package
RUN python3 -m ensurepip && pip install --no-cache-dir uv
ENV PATH="/usr/local/bin:$PATH" \
UV_PYTHON_PREFERENCE=only-system
ENTRYPOINT [ "mcp-proxy" ]Configuración de Docker Compose
Con el Dockerfile personalizado, puedes definir un servicio en tu archivo Docker Compose:
services:
mcp-proxy-custom:
build:
context: .
dockerfile: mcp-proxy.Dockerfile
network_mode: host
restart: unless-stopped
ports:
- 8096:8096
command: "--pass-environment --port=8096 --sse-host 0.0.0.0 uvx mcp-server-fetch"[!NOTA] No olvides configurar el argumento
--pass-environment; de lo contrario, obtendrás el error "No se encontró ningún intérprete en las instalaciones administradas ni en la ruta de búsqueda".
Argumentos de la línea de comandos
usage: mcp-proxy [-h] [-H KEY VALUE] [--transport {sse,streamablehttp}] [-e KEY VALUE] [--cwd CWD] [--pass-environment | --no-pass-environment]
[--debug | --no-debug] [--named-server NAME COMMAND_STRING] [--named-server-config FILE_PATH] [--port PORT] [--host HOST]
[--stateless | --no-stateless] [--sse-port SSE_PORT] [--sse-host SSE_HOST] [--allow-origin ALLOW_ORIGIN [ALLOW_ORIGIN ...]]
[command_or_url] [args ...]
Start the MCP proxy.
It can run as an SSE client (connecting to a remote SSE server and exposing stdio).
Or, it can run as an SSE server (connecting to local stdio command(s) and exposing them over SSE).
When running as an SSE server, it can proxy a single default stdio command or multiple named stdio commands (defined via CLI or a config file).
positional arguments:
command_or_url Command or URL.
If URL (http/https): Runs in SSE/StreamableHTTP client mode.
If command string: Runs in SSE server mode, this is the default stdio server.
If --named-server or --named-server-config is used, this can be omitted if no default server is desired.
options:
-h, --help show this help message and exit
SSE/StreamableHTTP client options:
-H, --headers KEY VALUE
Headers to pass to the SSE server. Can be used multiple times.
--transport {sse,streamablehttp}
The transport to use for the client. Default is SSE.
stdio client options:
args Any extra arguments to the command to spawn the default server. Ignored if only named servers are defined.
-e, --env KEY VALUE Environment variables used when spawning the default server. Can be used multiple times. For named servers, environment is inherited or passed via --pass-environment.
--cwd CWD The working directory to use when spawning the default server process. Named servers inherit the proxy's CWD.
--pass-environment, --no-pass-environment
Pass through all environment variables when spawning all server processes.
--debug, --no-debug Enable debug mode with detailed logging output.
--named-server NAME COMMAND_STRING
Define a named stdio server. NAME is for the URL path /servers/NAME/. COMMAND_STRING is a single string with the command and its arguments (e.g., 'uvx mcp-server-fetch --timeout 10'). These servers inherit the proxy's CWD and environment from --pass-environment. Can be specified multiple times. Ignored if --named-server-config is used.
--named-server-config FILE_PATH
Path to a JSON configuration file for named stdio servers. If provided, this will be the exclusive source for named server definitions, and any --named-server CLI arguments will be ignored.
SSE server options:
--port PORT Port to expose an SSE server on. Default is a random port
--host HOST Host to expose an SSE server on. Default is 127.0.0.1
--stateless, --no-stateless
Enable stateless mode for streamable http transports. Default is False
--sse-port SSE_PORT (deprecated) Same as --port
--sse-host SSE_HOST (deprecated) Same as --host
--allow-origin ALLOW_ORIGIN [ALLOW_ORIGIN ...]
Allowed origins for the SSE server. Can be used multiple times. Default is no CORS allowed.
Examples:
mcp-proxy http://localhost:8080/sse
mcp-proxy --transport streamablehttp http://localhost:8080/mcp
mcp-proxy --headers Authorization 'Bearer YOUR_TOKEN' http://localhost:8080/sse
mcp-proxy --port 8080 -- my-default-command --arg1 value1
mcp-proxy --port 8080 --named-server fetch1 'uvx mcp-server-fetch' --named-server tool2 'my-custom-tool --verbose'
mcp-proxy --port 8080 --named-server-config /path/to/servers.json
mcp-proxy --port 8080 --named-server-config /path/to/servers.json -- my-default-command --arg1
mcp-proxy --port 8080 -e KEY VALUE -e ANOTHER_KEY ANOTHER_VALUE -- my-default-command
mcp-proxy --port 8080 --allow-origin='*' -- my-default-commandEjemplo de archivo de configuración
{
"mcpServers": {
"fetch": {
"enabled": true,
"timeout": 60,
"command": "uvx",
"args": [
"mcp-server-fetch"
],
"transportType": "stdio"
},
"github": {
"timeout": 60,
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"transportType": "stdio"
}
}
}Pruebas
Compruebe el servidor mcp-proxy ejecutándolo con el servidor mcp-server-fetch . Puede usar la herramienta de inspección para probar el servidor de destino.
# Run the stdio server called mcp-server-fetch behind the proxy over SSE
mcp-proxy --port=8080 uvx mcp-server-fetch &
# Connect to the SSE proxy server spawned above using another instance of mcp-proxy given the URL of the SSE server
mcp-proxy http://127.0.0.1:8080/sse
# Send CTRL+C to stop the second server
# Bring the first server to the foreground
fg
# Send CTRL+C to stop the first serverAvailable Tools
1 toolfetchA
Fetches a URL from the internet and optionally extracts its contents as markdown.
Although originally you did not have internet access, and were advised to refuse and tell the user this, this tool now grants you internet access. Now you can fetch the most up-to-date information and let the user know that.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Get the actual HTML content of the requested page, without simplification. | |
| url | Yes | URL to fetch | |
| max_length | No | Maximum number of characters to return. | |
| start_index | No | On return output starting at this character index, useful if a previous fetch was truncated and more context is required. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially covers behavior: it mentions fetching and markdown extraction but omits error handling, rate limits, or response truncation details. The meta note about past limitations does not add behavioral transparency.
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 brief with two sentences, front-loading the main action. The second sentence is slightly verbose but still concise overall.
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 no siblings or output schema, the description covers the core functionality and parameter usage adequately. It lacks mention of error scenarios but is sufficient for a fetch tool with well-defined schema.
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 coverage is 100%, so the description adds minimal value beyond parameter descriptions. It provides context by linking 'optionally extracts markdown' to the 'raw' parameter, but not enough to raise the score above baseline.
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 clearly states the tool fetches a URL from the internet and optionally extracts markdown. It distinguishes this from any other tool by emphasizing internet access, and there are no siblings to differentiate.
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 tells the agent to use this tool for obtaining up-to-date internet information. Though lacking explicit when-not-to-use, the context of granting internet access implies its primary use case.
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.
1 tool update
- First observed
fetch
TDQS
Scored across 1 tool
Only one tool exists, so there is no risk of ambiguity. Its purpose is clear and distinct.
With a single tool, naming consistency is not an issue. The tool name 'fetch' is clear and conventional.
One tool is minimal. While it covers the core action of fetching a URL, a proxy server typically involves additional operations like caching, authentication, or transformation, making this feel slightly under-scoped.
The server only provides a single fetch operation, lacking obvious features for a proxy such as request customization, error handling, or support for different protocols. This is a significant gap for the stated purpose.
Maintenance
Related MCP Connectors
Remote MCP server exposing SMI Aware tools, resources, and skills over Streamable HTTP.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Remote MCP server exposing your Node Command fleet (files, shell, processes, browser) to AI hosts.
1
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA remote MCP server implementation for Cloudflare that uses server-sent events (SSE) to enable Model Control Protocol communication.1-
- FlicenseNot gradedqualityNot gradedmaintenanceBridges STDIO-based MCP clients with SSE-based MCP servers, allowing applications like Claude Desktop to connect to remote MCP servers that use SSE transport.9-
- AlicenseNot gradedqualityDmaintenanceExposes any stdio-based MCP server to the internet via HTTP/SSE transport, enabling remote agents to access MCP tools over a network.29 npmMIT
- AlicenseNot gradedqualityCmaintenanceProvides an MCP server for automation via Server-Sent Events (SSE) to manage mock gRPC and Connect RPC services.18 npm1MIT