La URL de un servidor MCP es la dirección web a la que llama tu cliente de IA para conectarse a un servidor remoto del Model Context Protocol. Este artículo explica cómo se construye esa dirección, muestra ejemplos reales de Notion, GitHub y Sentry, e indica dónde encontrar la exacta que necesitas.
Pegas un enlace en un cliente de IA, pulsas conectar y no pasa nada. O una pantalla de configuración te pide una "URL de servidor MCP" y no tienes ni idea de dónde sale esa dirección. La respuesta corta: una URL de servidor MCP es la dirección web de un servidor remoto del Model Context Protocol. Es el endpoint exacto al que llama tu cliente de IA para listar herramientas, leer datos y ejecutar acciones en tu nombre.
Este artículo explica qué significa esa dirección, cómo se construye, qué ejemplos reales puedes comparar y dónde encontrar la que necesitas. También verás los errores detrás de la mayoría de las conexiones fallidas y una forma rápida de revisar una configuración antes de culpar al servidor.
El Model Context Protocol (MCP) es un estándar abierto que permite a una aplicación de IA comunicarse con herramientas externas a través de un lenguaje predecible. Intervienen tres roles: el host (la aplicación de IA que usas), el cliente que funciona dentro de esa aplicación y el servidor que expone herramientas, recursos y prompts. Los mensajes entre cliente y servidor viajan como JSON-RPC.
Cuando el servidor está en internet en lugar de en tu propio equipo, el cliente necesita saber a dónde enviar esos mensajes. Esa ubicación es la URL del servidor MCP. Piensa en ella como el número de teléfono de un proveedor de herramientas concreto: lo llamas y el servidor responde con una lista de lo que puede hacer.
La especificación oficial llama a esta dirección endpoint de MCP. Es una única ruta HTTP, y la especificación exige que admita tanto POST como GET. Cada mensaje de tu cliente es un POST nuevo a esa ruta. Opcionalmente, el cliente abre un GET sobre la misma ruta para escuchar los mensajes que el servidor quiera enviarle. Una sola dirección, sin una larga lista de rutas que memorizar.
💡 Consejo: Si una página de configuración dice "server URL", "endpoint URL", "connector URL" o "remote MCP URL", casi siempre se refiere a esta misma dirección única.
La URL no describe las herramientas. No guarda tu inicio de sesión. Es solo la puerta. Lo que ofrece el servidor aparece después de que el cliente se conecta y lo pregunta. Por eso dos servidores con direcciones parecidas pueden comportarse de formas muy distintas, y por eso una URL que funciona no demuestra por sí sola que la configuración sea correcta.
Una URL de servidor MCP es una URL web estándar. La sintaxis no tiene sorpresas. La propia especificación usa este ejemplo:
https://example.com/mcp
Divide ese ejemplo en partes y cada una tiene una función.
| Parte | Ejemplo | Qué hace |
|---|---|---|
| Esquema | https:// | Indica al cliente que use HTTP cifrado. Los servidores remotos deberían usarlo siempre. |
| Host | mcp.example.com | El nombre de dominio del servidor. A menudo empieza por mcp. o api.. |
| Puerto (opcional) | :8443 | Solo aparece cuando el servidor no usa el puerto HTTPS predeterminado. |
| Ruta | /mcp | El único endpoint que gestiona el tráfico de MCP. |
| Query (opcional) | ?workspace=123 | Poco frecuente, pero algunos proveedores añaden ajustes como un workspace. |
Los servidores de desarrollo locales suelen usar http://localhost:3000/mcp sin cifrar. Eso está bien en tu propio equipo. Nunca expongas una dirección sin cifrar a internet.
La especificación solo dice que el endpoint "podría ser una URL como" el ejemplo de arriba. La ruta es una convención, no una norma. Aun así, en la práctica dominan dos sufijos:
/mcp suele apuntar a un servidor Streamable HTTP, el transporte estándar actual./sse suele apuntar al transporte HTTP+SSE anterior, de la versión de protocolo 2024-11-05.Trata el sufijo como una pista, no como una garantía. Un proveedor puede publicar su endpoint en /v1/mcp o en la raíz de un subdominio. Copia la URL exactamente como aparece, incluida cualquier barra final. El servidor remoto de GitHub, por ejemplo, termina en /mcp/.
Streamable HTTP sustituyó al antiguo transporte HTTP+SSE. Con el diseño nuevo, el cliente siempre envía un POST con una cabecera Accept que enumera application/json y text/event-stream. El servidor responde con un único objeto JSON o con un flujo de eventos. Un servidor también puede devolver una cabecera Mcp-Session-Id, que el cliente repite en cada petición posterior, y los clientes envían una cabecera MCP-Protocol-Version para que ambas partes acuerden la revisión de la especificación.
La documentación de Claude Code ya describe SSE como obsoleto y recomienda servidores HTTP siempre que existan. Muchos proveedores mantienen activa una dirección /sse para clientes antiguos, por eso todavía te encuentras con los dos estilos.
💡 Consejo: Un cliente que quiera ser compatible con servidores antiguos acepta una URL del usuario e intenta primero un POST. Si el servidor responde con un error 4xx, recurre a un GET y espera un flujo SSE. Esa alternativa explica por qué la misma URL pegada a veces funciona en una app y falla en otra.
No todos los servidores MCP tienen URL. Esto sorprende a mucha gente y explica por qué algunas configuraciones piden un comando en lugar de una dirección.
Con el transporte stdio, el cliente lanza el servidor como un subproceso en tu equipo. Los mensajes circulan por la entrada y la salida estándar. No hay salto de red ni dirección. Proporcionas un comando y sus argumentos, por ejemplo npx más el nombre de un paquete, y eso es todo lo que necesita el cliente. La especificación indica que los clientes deben admitir stdio siempre que sea posible, así que sigue siendo el valor predeterminado para herramientas locales.
Con Streamable HTTP, el servidor funciona como un proceso independiente y puede atender a muchos clientes a la vez. Es la configuración en la que una URL se vuelve imprescindible, porque el cliente tiene que encontrar el servidor a través de la red.
| Transporte | ¿Tiene URL? | Configuración típica | Estado |
|---|---|---|---|
| stdio | No | command y args en un archivo de configuración | Estándar, los clientes deberían admitirlo |
| Streamable HTTP | Sí, un endpoint | Pegar https://…/mcp | Transporte remoto estándar |
| HTTP+SSE | Sí, a menudo /sse | Pegar https://…/sse | Obsoleto, se mantiene para clientes antiguos |
Usa la segunda columna como regla para decidir. Si tu proveedor te da una línea de comandos, estás con stdio. Si te da un enlace, estás con un transporte remoto.
Cuando un servidor se ejecuta en tu propio equipo por HTTP, la especificación indica que debe vincularse a 127.0.0.1 en lugar de a 0.0.0.0, y que debe validar la cabecera Origin para bloquear los ataques de DNS rebinding. Dicho en pocas palabras: un servidor MCP local en localhost nunca debería ser accesible desde otros dispositivos de tu red, salvo que lo quieras expresamente.
Las direcciones de abajo proceden de páginas de documentación oficiales y listas públicas. Los proveedores cambian sus endpoints, así que trata esta tabla como una referencia de patrones y confirma cada URL en la documentación actual del proveedor antes de usarla.
| Proveedor | URL de ejemplo | Estilo |
|---|---|---|
| Ejemplo de la especificación | https://example.com/mcp | Streamable HTTP |
| Notion | https://mcp.notion.com/mcp | Streamable HTTP |
| GitHub | https://api.githubcopilot.com/mcp/ | Streamable HTTP |
| Sentry | https://mcp.sentry.dev/mcp | Streamable HTTP |
| Supabase | https://mcp.supabase.com/mcp | Streamable HTTP |
| PostHog | https://mcp.posthog.com/mcp | Streamable HTTP |
| Asana | https://mcp.asana.com/sse | SSE heredado |
| Servidor de prueba local | http://localhost:3000/mcp | Streamable HTTP en tu propio equipo |
mcp. dedicado: mcp.notion.com, mcp.sentry.dev, mcp.supabase.com.api.githubcopilot.com.Authorization.La documentación de Claude Code muestra estas formas exactas para Notion y Asana:
claude mcp add --transport http notion https://mcp.notion.com/mcp
claude mcp add --transport sse asana https://mcp.asana.com/sse
La única diferencia está en el valor de --transport y en la ruta. Todo lo demás, incluido el nombre que elijas, depende de ti.
Como la URL pertenece al propietario del servidor, la fuente más fiable es siempre el propietario. Este orden es el que más tiempo ahorra.
Busca en la documentación del proveedor "MCP", "remote MCP" o "connectors". Los portales para desarrolladores suelen tener una página dedicada, a menudo con un botón de copiar junto a la dirección. Esa página indica claramente el sufijo /mcp o /sse, así que no tienes que adivinarlo.
Algunos productos muestran la dirección en tu cuenta. Una página de ajustes de integraciones, conexiones o herramientas para desarrolladores puede listarla junto con los pasos de configuración para cada cliente. Si la página pide iniciar sesión, es normal: muchos proveedores vinculan la conexión a tu cuenta.
Los servidores de código abierto se describen en un archivo README. Busca una sección titulada "Usage", "Installation" o "Configuration". Si el README solo muestra un command y un args, el servidor es solo stdio y no tiene URL pública hasta que alguien lo despliegue.
Los directorios públicos como MCPservers.org mantienen listas de servidores MCP remotos y sus endpoints. Úsalos para encontrar candidatos y luego confirma la dirección en la documentación del propio proveedor. Las entradas de los directorios pueden quedar desactualizadas.
Si un compañero de equipo ya conectó el servidor, pídele que ejecute claude mcp list o claude mcp get <name> en Claude Code. Ambos comandos muestran cómo está configurado un servidor, y ahí puedes identificar la dirección. Dentro de una sesión en curso, el comando /mcp muestra el estado de cada servidor.
Cuando tienes la dirección correcta, la configuración lleva menos de un minuto. Tres vías sirven para casi cualquier cliente.
Claude Code pide un transporte, un nombre y la URL:
claude mcp add --transport http <name> <url>
Para enviar un token con cada petición, añade una cabecera:
claude mcp add --transport http secure-api https://api.example.com/mcp \
--header "Authorization: Bearer your-token"
La mayoría de los clientes también leen un archivo JSON. Los nombres de los campos cambian de una app a otra, así que consulta la documentación de tu cliente, pero la estructura se parece a esta:
{
"mcpServers": {
"notion": {
"type": "http",
"url": "https://mcp.notion.com/mcp"
},
"local-files": {
"command": "npx",
"args": ["-y", "example-mcp-package"]
}
}
}
La primera entrada es remota y usa url. La segunda es stdio y usa command. Usa un solo estilo por entrada.
Las apps de chat con una pantalla de conectores personalizada suelen pedir dos cosas: un nombre y la URL. Pega la dirección, guarda y completa el aviso de inicio de sesión si aparece. No hace falta nada más, porque la app encuentra las herramientas por sí sola en cuanto se abre la conexión.
La mayoría de las conexiones fallidas se deben a una lista corta de causas. Revísalas en este orden antes de tocar cualquier otra cosa.
Un nombre de host solo, como https://mcp.example.com, a menudo no basta. El cliente necesita la ruta exacta del endpoint. Si recibes un 404, copia de nuevo la dirección desde la documentación actual del proveedor y compárala carácter por carácter, incluida la barra final.
La URL base de una API REST normal no es una URL de MCP. Una base como https://api.example.com/v1 atiende peticiones ordinarias y no habla JSON-RPC sobre el transporte MCP. Si un proveedor ofrece ambas, la documentación las lista en páginas separadas. Nunca pegues una base de API en un campo llamado URL de servidor MCP esperando que aparezcan herramientas.
Una URL correcta sigue fallando sin permiso para usarla. Los servidores responden con 401 cuando tu token falta o ha caducado, y con 403 cuando tu cuenta no puede acceder a ese workspace. Vuelve a iniciar sesión desde el cliente o renueva el token Bearer que pasas en la cabecera Authorization.
💡 Consejo: No pongas tokens en la URL. Si un proveedor te pide que pegues un secreto en una query string, trata ese enlace como una contraseña y nunca lo compartas en capturas de pantalla ni en tickets.
| Síntoma | Causa probable | Solución |
|---|---|---|
| 404 Not Found | Ruta incorrecta, o el proveedor movió el endpoint | Copia de nuevo la URL desde la documentación actual |
| 405 Method Not Allowed | Se envió POST a una dirección solo SSE, o GET a una que solo admite POST | Prueba la dirección /mcp o cambia el transporte a sse |
| 401 Unauthorized | Token ausente o caducado, OAuth sin terminar | Vuelve a iniciar sesión o renueva el token Bearer |
| 403 Forbidden | La cuenta no tiene acceso a ese servidor o workspace | Revisa el plan, el workspace y los permisos |
| Connection refused | El servidor local no está en marcha, o el puerto es incorrecto | Inicia el servidor y revisa el puerto |
| Error de certificado | Certificado HTTPS autofirmado o que no coincide | Usa un certificado válido |
| Funciona solo en una app | Distinto soporte de transporte | Ajusta el transporte (http o sse) al cliente |
Un matiz evita mucha confusión: la especificación permite que un servidor responda a un GET con 405 para indicar que no ofrece un flujo SSE en ese endpoint. Por tanto, un 405 en un GET por sí solo no siempre es un fallo.
PicassoIA publica una API para desarrolladores en https://api.picassoia.com/v1. Usa endpoints al estilo de Replicate, como POST /v1/models/{owner}/{name}/predictions y GET /v1/predictions/{id}, y se autentica con un token Bearer que empieza por pia_sk_. Esa dirección pertenece a la API REST. No es una URL de servidor MCP, así que no la pegues en un campo de MCP.
Las conexiones MCP se gestionan desde tu cuenta en picassoia.com/en/mcp/accounts, que requiere inicio de sesión. La URL del servidor MCP no aparece en las páginas públicas, así que empieza por ahí en lugar de adivinarla. Se aplican las reglas de cada plan, así que consulta la página de precios para ver qué incluye el tuyo.
Cuatro modelos están disponibles tanto por la API como por MCP:
Los trabajos se ejecutan de forma asíncrona: creas una predicción, consultas su estado y luego obtienes el resultado. El límite es de 5 predicciones simultáneas por cuenta, compartidas entre tokens y conexiones MCP, con prompts de hasta 4000 caracteres.
El modelo Claude Sonnet 5 se ocupa de tareas de programación y uso de herramientas, lo que lo convierte en una segunda opinión útil para un archivo de configuración. Esta es una rutina corta en PicassoIA:
💡 Consejo: Toma la respuesta como una pista, no como un veredicto. Si las dos difieren, manda la documentación del proveedor.
GPT 5.6 Sol funciona igual si prefieres una segunda opinión.
Un servidor conectado solo es útil cuando tienes algo que construir con él. Abre Picasso IA, elige PicassoIA Image o Seedance 2.5 Lite, escribe un prompt que describa la escena que imaginas y genera tu primer resultado en pocos minutos. Prueba con una foto para tu próximo artículo, una imagen de producto o un clip corto, y luego afina la redacción y vuelve a ejecutarlo. La plataforma premia la experimentación, así que empieza hoy tu primer prompt y descubre lo que pueden generar tus propias palabras.
Elige tu idioma
