# Servidor MCP

> Cómo se obtiene el acceso al servidor MCP de Tilopay y cómo se conecta un cliente MCP con OAuth.

- kind: mcp-index
- status: stable
- last_verified: 2026-08-29
- url: https://www.tilopay.com/developers/agentes/mcp

## Cómo se obtiene el acceso [#acceso]

El MCP no es autoservicio. El comercio envía la solicitud con el
[formulario de abajo](#solicitud). Tilopay crea un usuario dedicado, exclusivo para este
servicio y asociado a un comercio, y registra del lado del servidor las credenciales de API de
ese comercio, cifradas. El usuario recibe un correo de invitación y define su contraseña.

Tres cosas que conviene tener claras antes de pedir el acceso:

1. El usuario del MCP es distinto del usuario de API del comercio. Quien ya tiene credenciales
   de API no las reutiliza acá.
2. Como el usuario está asociado a un comercio, el agente sólo alcanza los datos y las
   operaciones de ese comercio.
3. El comercio nunca pega su `apiKey`, `apiUser` ni `apiPassword` en el cliente MCP.

<Callout type="warn">
Las credenciales de API del comercio viven cifradas en el servidor de Tilopay y se descifran en
cada llamada. No se pegan en el cliente MCP, ni en el archivo de configuración del asistente, ni
se le pasan al modelo. Ese es el argumento de seguridad de todo el diseño.
</Callout>

El consumo del MCP puede tener costos adicionales según el volumen utilizado. El equipo de
soporte da ese detalle después de validar el volumen transaccional del comercio.

## Solicitud de acceso [#solicitud]

El formulario de solicitud de acceso está en la página HTML: https://www.tilopay.com/developers/agentes/mcp — los campos obligatorios son nombre, apellido, correo del comercio y nombre del comercio. El consumo del MCP puede tener costos adicionales según el volumen utilizado.

## Conexión [#conexion]

El servidor es `https://mcp.tilopay.com/mcp`. Para un usuario ya aprobado:

1. Agregar el servidor en el cliente MCP con esa URL.
2. El cliente descubre la autenticación por el 401 con `WWW-Authenticate`, que apunta a
   `/.well-known/oauth-protected-resource`.
3. El cliente se registra dinámicamente y abre la pantalla de autorización.
4. El usuario inicia sesión con su cuenta y ve una pantalla de consentimiento con la aplicación
   que pide acceso, la URL de retorno y los permisos.
5. Al aprobar, el cliente queda conectado.

El modelo es OAuth 2.0 con `authorization_code` y `refresh_token`. El cliente descubre los
endpoints del proveedor de identidad por sí mismo: lo único que hay que configurar es la URL del
servidor.

## Desde los clientes MCP más usados [#clientes]

- **Claude** (escritorio y web): agregar un conector remoto con la URL del servidor y completar
  el inicio de sesión en la ventana que abre.
- **ChatGPT**: agregar el servidor como conector remoto con esa misma URL; la autorización se
  completa en el navegador.
- **Cursor, VS Code y otros editores**: declarar un servidor MCP remoto de tipo HTTP con la URL,
  sin token en el archivo de configuración; el editor abre el navegador para autorizar.
- **Cliente propio**: usar un cliente MCP con transporte Streamable HTTP y soporte de OAuth 2.0
  con registro dinámico. La secuencia es la de arriba: 401, descubrimiento, registro,
  autorización, conexión.

El transporte es Streamable HTTP. Las herramientas disponibles se listan por grupo:
[ventas y transacciones](/developers/agentes/mcp/ventas),
[enlaces de pago](/developers/agentes/mcp/enlaces-de-pago),
[catálogo](/developers/agentes/mcp/catalogo),
[contactos](/developers/agentes/mcp/contactos) y
[soporte y diagnóstico](/developers/agentes/mcp/soporte).
Antes de conectar un agente, leé [qué puede hacer](/developers/agentes/permisos).