Aceptación de acceso MCP remoto: descubrimiento de herramientas y requisitos pendientes

Actualización de estado del producto (revisión con hora de Pekín del 13-09-2026): la lista de seis herramientas conservada en este artículo corresponde a la observación histórica del 04-09-2026; entre ellas, everyinfra_chat se retiró junto con la API de texto general el 12-09-2026 y ya no constituye una nueva capacidad de integración en tools/list. El inventario actual de herramientas debe basarse en el descubrimiento MCP en tiempo real. Al procesar los resultados personales de EveryData, utiliza herramientas de depuración con fuentes asociadas, permisos independientes y fórmulas fijas.

Introducir una dirección MCP en un cliente y ver aparecer los nombres de las herramientas representa un avance útil, pero aún no responde si las claves se transmiten de forma correcta, si la invocación real pertenece al ámbito permitido, si el cliente reconoce los errores y si los datos devueltos cumplen con los requisitos de la tarea.

Este artículo toma como ejemplo el punto de acceso remoto de EveryInfra para dividir la aceptación de acceso en cuatro capas: descubrimiento de protocolos, coincidencia de autenticación, operaciones del cliente y resultados comerciales. Primero ofrece una sonda de descubrimiento sin clave y luego explica por qué tres clientes no pueden compartir la misma frase de configurar la dirección. Este tutorial de integración incluye límites comprobados empíricamente y no constituye una declaración de éxito en la instalación para Claude, ChatGPT y Cursor.

Una dirección remota, cuatro capas de evidencia independiente

El punto de acceso examinado en esta ocasión es https://api.everyinfra.com/mcp. El descubrimiento de protocolos indica cómo se autodescribe el servidor y qué herramientas publica; la coincidencia de autenticación resuelve cómo el cliente obtiene y transmite las credenciales autorizadas; la aceptación del cliente comprueba si las herramientas se incorporan realmente a la sesión actual; y la aceptación comercial verifica los resultados reales y los errores.

Registra las cuatro capas por separado. Que el servidor responda a la inicialización no significa que el cliente acepte las notificaciones posteriores; que el cliente visualice el catálogo no implica que posea permisos comerciales; que una herramienta devuelva contenido no garantiza la ausencia de errores comerciales. Evita resumir todas las situaciones con un único valor booleano de conexión exitosa.

Asimismo, MCP y REST representan formas de acceso diferentes. Las muestras de REST ayudan a verificar el significado comercial, pero no demuestran por sí solas que un cliente procese correctamente la autenticación, los bloques de contenido, los errores o los flujos de confirmación de MCP.

Tras la inicialización, queda una notificación

Este artículo revisa esta ruta de descubrimiento conforme a la versión 2025-06-18 de MCP, sin proclamar que sea la más reciente o la única para todos los clientes. El cliente envía primero initialize para verificar la versión seleccionada por el servidor, luego envía notifications/initialized y después procede al descubrimiento de herramientas. Las solicitudes HTTP posteriores deben incluir la versión de protocolo negociada. Ciclo de vida del protocolo

Cuando se acepta una notificación de Streamable HTTP, se debe devolver HTTP 202 sin cuerpo de respuesta. Si el servidor devuelve Mcp-Session-Id durante la inicialización, el cliente necesita conservarlo en las solicitudes posteriores; sin dicha cabecera de respuesta, no inventes una sesión de forma arbitraria. Las respuestas de las solicitudes pueden adoptar el formato JSON o SSE, y los clientes reales deben admitir las formas de transporte requeridas por el protocolo. Especificación de transporte

El script siguiente examina únicamente la bifurcación de respuesta JSON empleada por el servidor en esta ocasión y no actúa como un cliente MCP universal. Al encontrar SSE, catálogos paginados o versiones no compatibles, se detendrá para que un cliente completo continúe la aceptación; no finge cubrir todo el protocolo mediante el análisis exclusivo de un objeto JSON.

Un script de diagnóstico centrado exclusivamente en el descubrimiento

Utiliza Node.js 22 o una versión posterior compatible con fetch integrado. El script no lee claves del entorno, no envía tools/call ni instala o modifica ningún cliente. La salida conserva únicamente el estado, los nombres de las herramientas y los problemas de compatibilidad, omitiendo la promoción comercial descrita en las especificaciones del servidor.

node --input-type=module <<'JS'
const endpoint = 'https://api.everyinfra.com/mcp';
const supportedVersion = '2025-06-18';
const headers = {
  'Content-Type': 'application/json',
  Accept: 'application/json, text/event-stream',
};
const issues = [];
async function post(message) {
  const response = await fetch(endpoint, {
    method: 'POST', headers, redirect: 'error',
    body: JSON.stringify(message),
    signal: AbortSignal.timeout(20000),
  });
  return { response, text: await response.text() };
}
function rpcResult(reply, id) {
  if (reply.response.status !== 200) {
    throw new Error('RPC HTTP ' + reply.response.status);
  }
  if (!reply.response.headers.get('content-type')?.includes('application/json')) {
    throw new Error('This probe only handles JSON; use a full MCP client');
  }
  const body = JSON.parse(reply.text);
  if (body.jsonrpc !== '2.0' || body.id !== id ||
      body.error || !body.result || typeof body.result !== 'object') {
    throw new Error('Invalid or failed RPC response');
  }
  return body.result;
}
const initReply = await post({
  jsonrpc: '2.0', id: 1, method: 'initialize',
  params: {
    protocolVersion: supportedVersion, capabilities: {},
    clientInfo: { name: 'bip-discovery-only', version: '1.0' },
  },
});
const init = rpcResult(initReply, 1);
if (init.protocolVersion !== supportedVersion ||
    init.serverInfo?.name !== 'EveryInfra' || !init.capabilities?.tools) {
  throw new Error('Unexpected version, server or tool capability');
}
headers['MCP-Protocol-Version'] = init.protocolVersion;
const session = initReply.response.headers.get('mcp-session-id');
if (session) headers['Mcp-Session-Id'] = session;
const notification = await post({
  jsonrpc: '2.0', method: 'notifications/initialized',
});
if (notification.response.status !== 202) {
  throw new Error('Initialization notification was not accepted');
}
const notificationBytes = Buffer.byteLength(notification.text);
if (notificationBytes !== 0) issues.push('notification_body_not_empty');
// Continue discovery for diagnosis only; never enter a business call.
const listed = rpcResult(await post({
  jsonrpc: '2.0', id: 2, method: 'tools/list', params: {},
}), 2);
if (!Array.isArray(listed.tools) || listed.tools.length === 0 ||
    listed.tools.some(tool => !tool.name || tool.inputSchema?.type !== 'object') ||
    listed.nextCursor) {
  throw new Error('Incomplete or unexpected tool list');
}
console.log(JSON.stringify({
  observedAt: new Date().toISOString(),
  protocolVersion: init.protocolVersion,
  sessionHeaderPresent: Boolean(session),
  notificationStatus: notification.response.status,
  notificationBodyBytes: notificationBytes,
  toolNames: listed.tools.map(tool => tool.name),
  issues,
  businessCallPerformed: false,
  hostAcceptanceVerified: false,
}, null, 2));
if (issues.length) process.exitCode = 2;
JS

El código de salida 0 indica únicamente que esta comprobación de descubrimiento limitada no encontró discrepancias, pero de ningún modo constituye una autorización de publicación ni una aprobación de aceptación en tres extremos. El código de salida 2 señala que se obtuvo el catálogo, aunque existen divergencias de protocolo; los demás errores interrumpen la ejecución. Trata por separado los fallos de conexión y los problemas de compatibilidad posteriores al descubrimiento exitoso.

Qué descubrió con éxito esta ejecución y qué problemas reveló

En la revisión sin autenticación realizada el 4 de septiembre de 2026 a las 20:43 (hora de Pekín), la inicialización devolvió HTTP 200 con la versión de protocolo 2025-06-18, sin proporcionar una cabecera de respuesta para el ID de sesión. El catálogo de herramientas devolvió seis nombres:

• everyinfra_list_capabilities
• everyinfra_call_api
• everyinfra_chat
• everyinfra_list_captcha_types
• everyinfra_solve_captcha
• everyinfra_search

Sin embargo, cuando la notificación de finalización de la inicialización devolvió HTTP 202, el cuerpo de la respuesta consistió en JSON null en lugar de un cuerpo vacío. Esto incumple los requisitos de respuesta de notificación de la versión mencionada. El catálogo sigue siendo legible, lo cual resulta insuficiente para demostrar que todos los clientes tolerarán esta divergencia; el script debe reportarla explícitamente en lugar de omitirla en silencio.

En esta ronda no se invocaron herramientas comerciales ni se confirmó si los clientes fallaron a consecuencia de ello. Los responsables del mantenimiento del servicio deben atender las diferencias de respuesta antes de volver a realizar pruebas en los clientes reales. La afirmación admisible en este momento es «la ruta de descubrimiento público ha observado seis herramientas y presenta discrepancias en la respuesta de notificación», la cual no puede redactarse como «compatibilidad total con MCP».

2026-09-08 Al volver a ejecutar el mismo proceso de descubrimiento gratuito, el catálogo devolvió ocho herramientas; las dos incorporaciones corresponden a utilidades de limpieza de datos. La notificación de finalización de la inicialización arrojó HTTP 202 con un cuerpo de 0 bytes, por lo que la discrepancia de respuesta del día 4 de septiembre no reapareció en esta revisión. Esta actualización solo clausura las observaciones antiguas de la capa de descubrimiento público, sin implicar que Claude, ChatGPT y Cursor hayan completado la autenticación o la ejecución de operaciones comerciales reales.

Cursor: comprueba el soporte de cabeceras de configuración de forma independiente de los permisos reales

La documentación oficial de Cursor proporciona configuraciones para url y headers en servidores remotos, además de admitir la interpolación desde variables de entorno. A continuación se muestra la forma de configuración que se usará tras la autorización del usuario; en esta ronda no se ha escrito en la configuración del usuario ni se ha verificado la llamada real de este cliente. Cursor Documentación de MCP

{
  "mcpServers": {
    "everyinfra": {
      "url": "https://api.everyinfra.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:EVERYINFRA_API_KEY}"
      }
    }
  }
}

El código actual del servidor del proyecto incluye el análisis de la cabecera Bearer, pero la existencia de esta ruta en el código fuente no demuestra que una clave determinada esté disponible hoy. Al preparar la integración real, confirma que el proceso del cliente puede leer las variables de entorno especificadas y verifica los permisos de negocio de la clave; no escribas valores reales en configuraciones bajo control de versiones, capturas de pantalla o informes de errores.

A continuación, actualiza el catálogo, selecciona herramientas individuales y conserva la confirmación del usuario en la versión actual de Cursor. No actives todas las herramientas para su ejecución automática solo porque el catálogo sea visible; una clave con permisos de negocio tampoco debe considerarse una autorización a largo plazo para todas las operaciones.

Claude: los conectores remotos no usan la red local

Las instrucciones oficiales del conector remoto de Claude indican que las solicitudes se emiten desde la nube de Anthropic, incluidos los conectores remotos de Claude Desktop. Esto constituye un mecanismo distinto al de los servidores MCP locales en la configuración de escritorio. Por lo tanto, que la máquina local pueda acceder a una dirección solo prueba la ruta local, no que el conector en la nube también pueda hacerlo. Claude Instrucciones del conector remoto

Durante la integración, revisa la entrada del conector según la cuenta actual y los permisos de la organización, y luego verifica los flujos de autenticación admitidos tanto por el servicio como por el cliente. La configuración de OAuth descrita en la documentación oficial no puede reescribirse para permitir cualquier clave de API Bearer. Si los modelos de autenticación no coinciden, es necesario que el servicio o el esquema de adaptación controlado completen primero el diseño y la aceptación, sin insertar secretos en la URL como sustituto genérico.

Aquí no se proporcionan capturas de pantalla de clics ni pasos de adición inmediata sin verificar en esta cuenta. La adición del conector, la autorización y la confirmación final modifican el estado de la cuenta y deben ejecutarse tras la aprobación del usuario; las sondas de protocolo no sustituyen estas evidencias.

ChatGPT y la API de OpenAI: dos puntos de entrada de integración distintos

La documentación oficial del modo de desarrollo de ChatGPT enumera OAuth, la ausencia de autenticación y la autenticación híbrida; esta última implica el descubrimiento sin autenticación y la selección del método de autenticación mediante declaraciones de seguridad de las herramientas. Que el descubrimiento no requiera una clave no significa que todas las herramientas de negocio se puedan invocar sin autenticación. ChatGPT Modo de desarrollo

En el catálogo de herramientas de esta ronda no se observaron campos de securitySchemes o _meta a nivel de herramienta. Esto constituye una observación de la respuesta actual y no una auditoría completa de la implementación de autenticación de todo el servicio; sin embargo, basta para ilustrar que no se puede declarar que se cumplen los requisitos de acceso de autenticación híbrida de ChatGPT basándose únicamente en un descubrimiento exitoso.

La configuración de MCP remoto para la API de respuestas de OpenAI representa otra ruta distinta e incluye parámetros como server_url, la selección de herramientas, la autenticación y la aprobación de llamadas. No se trata de la descripción de configuración de la interfaz de ChatGPT; construir solicitudes mediante la API tampoco demuestra de forma inversa que la interfaz web se haya conectado. Guía de conectores y MCP de OpenAI

En esta ronda solo se ha verificado la documentación, sin ejecutar solicitudes de negocio en la API de OpenAI ni habilitar el modo de desarrollo para el usuario. Si se utiliza esta ruta en el futuro, se debe revisar de forma independiente el ámbito de los datos que se enviarán al servicio remoto y mantener los pasos de aprobación para las llamadas sensibles.

El diseño de la autenticación también requiere la lectura independiente del tutorial oficial de mejores prácticas de seguridad de MCP. Dicha página se encuentra en la ruta de documentación de 2025-11-25 e indica que los tokens deben dirigirse al servicio correcto, desaprobando la transmisión de tokens sin verificar; no convierte claves de terceros en credenciales genéricas de MCP ni sustituye la comprobación de descubrimiento realizada según la versión de 2025-06-18.

Tras HTTP 200, es necesario comprobar dos niveles de resultados

Los errores de protocolo de MCP pueden aparecer en el nivel superior error de JSON-RPC; los errores de ejecución de herramientas también se pueden expresar mediante result.isError. No se puede declarar que la operación de negocio ha tenido éxito comprobando únicamente HTTP 200 o la presencia de un bloque de texto. Especificación de herramientas y errores

La actividad de negocio real también debe comprobar la estructura de datos devuelta por la herramienta: si la salida corresponde al objeto esperado, si está vacía o parcialmente completa, y si existen tareas asíncronas pendientes de consulta. Los bloques de contenido múltiple deben procesarse según el contrato de la herramienta y no se debe asumir por defecto que el primer bloque de texto contiene todos los metadatos. La facturación, el uso y el saldo requieren la revisión de la respuesta de negocio real; descubrir el catálogo no proporciona un comprobante de liquidación para una llamada de negocio.

En el caso de operaciones con efectos secundarios como envíos, compras, envíos de formularios u otras acciones, el hecho de que el cliente muestre la herramienta no significa que el usuario haya autorizado su ejecución. Confirma el destino y los parámetros antes de realizar la llamada, y determina si el primer resultado es conocido antes de reintentar. La sonda sin clave de este texto evita deliberadamente este nivel.

Un registro de aceptación para entregar al siguiente integrador

Cada cliente debe registrar por separado el producto y la versión, la ubicación de ejecución, los métodos de transporte y autenticación, la evidencia de instalación y autorización, el nombre real de la herramienta, las entradas enmascaradas, el estado del resultado y los errores. Registra la hora de la observación y el ámbito de llamadas permitido, sin almacenar el texto original de las claves. Las muestras de éxito, los fallos explícitos y los resultados desconocidos deben documentarse por separado.

El método de registro puede seguir los principios de correlación de eventos y exclusión de datos de la guía de registro de OWASP: correlacionar la misma operación y evitar al mismo tiempo escribir tokens, sesiones o contenido completo del cliente en los archivos adjuntos de depuración. Los registros constituyen únicamente una parte de la evidencia de aceptación y no sustituyen la comprobación del comportamiento real del cliente.

En esta ronda ya se han completado el descubrimiento público y la verificación de diferencias en la documentación. Aún no se han completado la corrección de cuerpos vacíos en las notificaciones, la instalación y autenticación en tres clientes, las llamadas de negocio autorizadas ni la aceptación de visualización de errores. Solo cuando cada uno de estos elementos obtenga sus respectivas evidencias se podrá cambiar la redacción del tutorial de "configuración pendiente de verificación" a "probado en la versión especificada".

Puedes ejecutar primero el script de descubrimiento de este texto para confirmar si la interfaz actual y el registro siguen coincidiendo, y luego avanzar según el cliente seleccionado por el equipo. No modifiques tres cuentas al mismo tiempo ni copies una configuración sin verificar solo para completar una lista de compatibilidad. EveryInfra Entrada de documentación