Skip to main content
El servidor MCP (Model Context Protocol) público de Nexor permite que un cliente de IA consulte y opere tu cuenta. Trabaja sobre los mismos recursos que la API REST, pero los dos catálogos no son idénticos. URL del servidor de producción: https://mcp.getnexor.ai/mcp

Explora todas las tools listadas

Revisa las 384 tools no administrativas que se muestran a sesiones de cliente, con scopes, argumentos obligatorios, tipo de operación, resguardos y la excepción de disponibilidad vigente.

Autenticación REST

Usa esta guía separada para las claves de la API REST. Las claves REST y MCP no son intercambiables.

Mira el recorrido de conexión

Las configuraciones siguientes son la referencia vigente para cada cliente compatible.

Crea una clave MCP

  1. Haz clic en MCP en la barra lateral izquierda. La ventana crea una clave llamada Acceso MCP con acceso completo de configuración, para que tu asistente pueda terminar la puesta en marcha.
  2. Copia el código para tu cliente. Incluye la clave; la clave completa no se vuelve a mostrar. Guárdala en un gestor de contraseñas o de secretos.
  3. Para reducir el acceso de la clave, recorta sus scopes en la misma ventana o abre Gestionar claves. Revoca las claves que ya no uses: abrir la ventana de nuevo en otra sesión puede crear otra clave.
Las claves MCP comienzan con nxr_mcp_. Son distintas de las claves REST y tienen sus propios scopes. Aplica mínimo privilegio: si el cliente solo necesita consultar la cuenta, deja solo scopes de lectura.
Envía la clave solo mediante el header X-API-Key. El servidor MCP público no autentica Authorization: Bearer. Nunca pegues una clave real en el control de versiones, capturas o chats compartidos.

Conecta un cliente

Usa una de estas cuatro configuraciones específicas. Reemplaza nxr_mcp_YOUR_KEY en tu equipo.

Claude Code

Ejecuta en una terminal:

Codex

Agrega esto a ~/.codex/config.toml:

Cursor

Agrega esto a ~/.cursor/mcp.json:

Claude Desktop

Claude Desktop usa un bridge stdio local para este servidor remoto con autenticación por header. Abre Developer → Edit Config y agrega esto a claude_desktop_config.json:
Mantén el argumento del header sin espacios en la configuración de Claude Desktop. mcp-remote reemplaza ${NEXOR_MCP_KEY} desde env al iniciarse.

Cómo funciona la conexión

Nexor implementa Streamable HTTP con sesión:
  1. El cliente envía una solicitud MCP initialize mediante HTTP POST con X-API-Key.
  2. Nexor autentica la clave, vincula la identidad del cliente y sus scopes a la sesión nueva, y devuelve un mcp-session-id.
  3. Las solicitudes POST siguientes reutilizan esa sesión. GET abre el stream de eventos del servidor y DELETE cierra la sesión.
La mayoría de los clientes MCP administra el header de sesión y la reconexión de forma automática. Una tool disponible para clientes nunca acepta un ID de cliente como autorización; Nexor obtiene el tenant desde la sesión autenticada. Existen siete tools de administración interna fuera del catálogo generado para clientes, y solo las sesiones internas de administración pueden usar sus controles de contexto de tenant.

Scopes

Una clave MCP solo puede llamar una tool cuando tiene el scope requerido. Las tools sin un scope nominal también exigen una clave MCP válida.
La respuesta tools/list del servidor contiene 391 tools en la revisión fijada por esta documentación. Siete están reservadas para administración interna y rechazan claves de cliente. El catálogo generado de tools no administrativas incluye las otras 384.
El catálogo fijado todavía incluye create_client_tool, update_client_tool, assign_tool_to_workflow, configure_customer_api_tool, create_workflow_tool y update_workflow_tool porque esas tools existen en tools/list. Por ahora, crear, editar o asignar un destino HTTP personalizado no es una operación pública soportada mientras Nexor refuerza la validación de destinos. No uses estas tools para configurar un destino hasta que se retire este aviso.

Confirmaciones y acciones sensibles

Inscribir leads en una tarea activa, por ejemplo con upsert_leads y workflow_id, o con las tools de asignación individual y masiva, inicia el contacto de inmediato según su cadencia; las llamadas esperan el horario de contacto de la tarea, y los mensajes salen de inmediato salvo que la tarea los restrinja a su horario. Se excluyen los leads marcados como no contactar y las tareas solo entrantes. Al activar una tarea en pausa se empieza a contactar a todos los leads que esperan en ella. Explica esto y obtén aprobación antes de inscribir leads o activar una tarea.
Un scope de escritura autoriza una clase de acciones. No reemplaza la aprobación del operador. Antes de una acción destructiva, con cobro, con salida hacia un lead u operacional, explica el efecto y solicita aprobación explícita. El catálogo generado muestra estos resguardos directamente desde el contrato de la tool: Algunas tools destructivas exigen aprobación en sus instrucciones, pero no tienen un campo común de confirmación: run_background_job, delete_agent_group, delete_cloud_function, clear_cloud_function_runs, delete_function_environment_variable, delete_scheduled_function y clear_scheduled_function_runs. Pregunta antes de usarlas y no infieras aprobación por la ausencia de un campo en el schema.

Borradores, pruebas y publicación de funciones

Los cambios de código de Cloud Functions y Funciones programadas pasan por un borrador, así producción sigue ejecutando el código publicado mientras un cliente trabaja:
  1. update_cloud_function y update_scheduled_function guardan code como borrador y devuelven su draft_hash. Los demás campos se guardan de inmediato.
  2. test_cloud_function y test_scheduled_function ejecutan el borrador sin efectos reales. Las lecturas se envían, los demás métodos HTTP reciben un 200 simulado y aparecen en outbound.would_send, y los cambios en leads solo se previsualizan. run_cloud_function se mantiene como alias de la prueba.
  3. Muestra al operador lo que se enviaría y los efectos previsualizados. Después de su aprobación explícita, llama a publish_cloud_function o publish_scheduled_function con confirm: true y el draft_hash probado como expected_draft_hash. Un CONFLICT con draft_changed_since_preview significa que el borrador cambió: vuelve a leerlo, pruébalo y pregunta de nuevo.
list_cloud_function_versions, get_cloud_function_version, list_scheduled_function_versions y get_scheduled_function_version leen el historial de versiones. restore_cloud_function_version y restore_scheduled_function_version copian una versión en el borrador, nunca en producción. discard_cloud_function_draft, discard_scheduled_function_draft y una restauración con replace_draft: true pierden los cambios sin publicar, así que pregunta antes. run_scheduled_function ejecuta la versión publicada de verdad y sigue requiriendo confirm: true.

Errores de tools

Una falla de tool marca isError: true en MCP y devuelve texto JSON con la forma { "error": { "code": "...", "message": "..." } }.

Errores de transporte

Las fallas del handshake y de sesión son errores JSON-RPC, separados de los errores de tools.

Solución de problemas

El cliente conecta, pero una tool devuelve FORBIDDEN

Compara el scope de la tool en el catálogo con los scopes otorgados a la clave. Agrega solo el que falta. Una clave de cliente no puede llamar una tool reservada para administración interna.

Claude Desktop no inicia el servidor

Usa la configuración stdio con mcp-remote, no el formato remoto { "url", "headers" } de Cursor. Confirma que Node.js y npx estén disponibles, y mantén X-API-Key:${NEXOR_MCP_KEY} sin espacios.

El cliente informa una sesión inválida

Reinicia o reconecta el cliente MCP para que envíe una solicitud initialize nueva. No reutilices un mcp-session-id guardado entre procesos distintos del cliente. Las llamadas a tools y sus tasas de error de los últimos 30 días están disponibles por tool, para todas las claves MCP, en Gestionar claves.
Última modificación el 6 de octubre de 2026