Chaindoc MCP Server (Beta): Turn Claude and ChatGPT Into Your AI Document Employee

Un servidor MCP es un programa pequeño que permite a asistentes IA como Claude Desktop o ChatGPT llamar a servicios externos como si fueran herramientas integradas. El Model Context Protocol (MCP) fue presentado por Anthropic en noviembre de 2024 como un estándar abierto para conectar agentes IA con sistemas reales. En lugar de decirle a la IA "explica cómo funciona Chaindoc", le dices "envía este NDA a John para firma" y la IA lo ejecuta directamente a través del servidor MCP, sin copiar y pegar, sin inicios de sesión, sin cambiar de aplicación.

Chaindoc MCP es el primer servidor MCP nativo de firma electrónica, actualmente en beta privada. Convierte a Claude Desktop, ChatGPT (a través del OpenAI Apps SDK), Cursor y Zed en una interfaz operativa para todo el ciclo de vida del contrato: redacción, firma, verificación y seguimiento. Sinceramente, la primera vez que ves cómo Claude redacta y envía un contrato por ti, parece casi trampa.

El cambio es real. Según el informe Salesforce State of Sales 2024, los comerciales dedican solo el 28% de su semana a vender activamente; el resto se va en tareas administrativas como redactar contratos, perseguir documentos y actualizar el CRM. Los empleados IA construidos sobre MCP pueden reducir buena parte de ese 72% a instrucciones por chat. Investigaciones de Aberdeen Group muestran que las organizaciones que usan flujos de firma electrónica cierran contratos 80% más rápido y procesan 22,6 propuestas por comercial al mes, frente a 10,4 con flujos manuales. Combina esas ganancias con un agente IA que se hace cargo del trabajo de extremo a extremo y el techo de productividad sube de manera notable.

Esta guía explica qué hace el Chaindoc MCP server, en qué se diferencia de una integración API tradicional, qué está disponible en la beta y cómo solicitar acceso. Para más contexto sobre integraciones, ve nuestra página de API REST para firma electrónica y automatización documental y nuestra guía existente sobre integración CRM con Chaindoc y Pipedrive.

Un empleado IA, en este contexto, no es un chatbot que finge ser una persona. Es un agente IA con un conjunto específico de herramientas y autoridad para usarlas en tu nombre. El protocolo MCP le da a la IA tres cosas que antes no tenía: un directorio de herramientas disponibles (operaciones de Chaindoc como "crear documento" o "verificar firma"), una forma estructurada de invocarlas y un canal para leer los resultados de vuelta y planificar el siguiente paso.

Piensa en cómo un empleado humano gestiona una tarea contractual. Le mandas un correo: "envía el NDA a John, copia nuestras cláusulas estándar de PI, hazle seguimiento si no firma en una semana". Abre Chaindoc, busca la plantilla de NDA, la rellena, la envía, pone un recordatorio en el calendario para el seguimiento y revisa el estado cuando llega la fecha. Cada uno de esos pasos se corresponde con una herramienta del Chaindoc MCP: `chaindoc_create_document`, `chaindoc_create_signature_request`, `chaindoc_get_status`, `chaindoc_subscribe_webhook`. El agente IA razona sobre qué herramientas llamar, en qué orden, y se adapta a lo que devuelve cada paso.

Lo que cambia para ti, el humano:

• Dejas de abrir 14 pestañas del navegador para el trabajo contractual. La mayoría de las operaciones contractuales se mueven a una única interfaz de chat.
• El agente IA se ocupa del aburrido medio (rellenar plantillas, vigilar firmas, enviar recordatorios) y tú solo entras al principio (intención) y al final (revisión).
• Las pistas de auditoría se vuelven más sólidas, no más débiles, porque cada acción de la IA queda registrada por Chaindoc igual que una acción humana, con el mismo anclaje en blockchain descrito en nuestra guía de cumplimiento de pistas de auditoría.

Aviso justo: los agentes IA cometen errores. A veces eligen la plantilla equivocada, cuentan mal los firmantes o envían al correo equivocado ante instrucciones ambiguas. El servidor MCP devuelve mensajes de error completos, así que la IA suele detectar sus propios fallos a mitad de la tarea, pero un paso de revisión humana sigue siendo recomendable para contratos de alto valor.

La mayoría de los primeros servidores MCP conectan a los agentes IA con datos de solo lectura: buscar en la web, consultar una base de datos, leer un archivo. La firma electrónica es distinta porque es uno de esos flujos raros en los que el valor no está en recuperar, sino en actuar. La IA no se limita a hablarte de un contrato; lo envía. Eso cambia el cálculo de productividad en un orden de magnitud completo.

Tres razones por las que la firma electrónica encaja inusualmente bien con MCP:

1. 1.
   Acciones discretas y bien definidas. Las operaciones contractuales se descomponen en primitivas limpias (crear, enviar, firmar, verificar, estado, listar). Los agentes IA son buenos eligiendo la primitiva adecuada para una instrucción; son peores improvisando flujos difusos de varios pasos. Las operaciones de firma electrónica son justo el tipo de cosa que se le describe a un becario en una sola frase.
2. 2.
   Alto rigor de pista de auditoría. La mayoría de los flujos que tocan los agentes IA tienen procedencia débil. ¿Realmente envió ese correo el agente? ¿Estaban limpios los datos? Con Chaindoc, cada acción de la IA aterriza en una pista de auditoría a prueba de manipulaciones anclada en una blockchain pública, el mismo registro que produciría un usuario humano. Esto hace que la contratación impulsada por IA sea conforme por defecto para ESIGN, eIDAS y SOX; ve nuestra guía de pista de auditoría y prueba legal.
3. 3.
   Cola larga de variantes contractuales. Una empresa típica maneja decenas de tipos de contratos (NDAs, MSAs, SOWs, acuerdos con proveedores, contratos laborales, contratos de prestación). Cada uno tiene ligeras variaciones por jurisdicción, sector y contraparte. Los agentes IA gestionan bien esa variabilidad porque pueden razonar sobre plantillas y cláusulas; la automatización basada en reglas no.

Para escenarios contractuales concretos donde se está probando Chaindoc MCP en beta, ve nuestros artículos sobre el NDA para contratistas en empresas de software, la guía del formulario W-9 para contratistas y la clasificación contratista independiente vs empleado.

El Chaindoc MCP server en beta expone siete herramientas que cubren el ciclo completo de vida del contrato. Cada herramienta se corresponde con un endpoint REST API específico de Chaindoc, y la capa MCP gestiona la autenticación, el parseo de respuestas y el contexto de error para que el agente IA reciba algo sobre lo que realmente pueda razonar.

Herramientas disponibles en beta

• `chaindoc_create_document` , sube un archivo o variante de plantilla y devuelve un ID de documento y una URL del visor. La IA la usa para redactar a partir de una plantilla siguiendo las instrucciones del chat.
• `chaindoc_create_signature_request` , envía un documento para firma a uno o varios firmantes, con verificación KYC opcional, orden de firma y calendario de recordatorios.
• `chaindoc_get_status` , devuelve el estado completo de una solicitud de firma: quién ha firmado, quién está pendiente, URLs de firma para los firmantes activos y la pista de auditoría hasta la fecha.
• `chaindoc_verify_document` , pasa un documento firmado por Chaindoc por una verificación a prueba de manipulaciones y devuelve el certificado de firma, el ancla blockchain y el resultado de integridad.
• `chaindoc_list_documents` , lista paginada de documentos con filtros opcionales (estado, rango de fechas, correo del firmante). Permite a la IA encontrar el documento adecuado a partir de una referencia vaga.
• `chaindoc_get_template` — recupera una plantilla guardada junto con su esquema de variables, para que la IA sepa exactamente qué campos rellenar.
• `chaindoc_subscribe_webhook` — registra un webhook para eventos de estado y devuelve el ID del webhook y el secreto HMAC. Sirve para configurar notificaciones asíncronas que la IA pueda consultar después.

Lo que aún no está en beta

Las herramientas de facturación, la orquestación KYC y el OAuth multi-tenant están en la hoja de ruta (ve la sección de abajo). La beta actual se basa en clave API, lo que está bien para usuarios individuales y equipos pequeños pero todavía no soporta el flujo OAuth por usuario que necesitarán los despliegues multi-tenant en producción.

Si ya has integrado Chaindoc a través de la API REST y los SDKs, la pregunta es legítima: ¿por qué añadir una nueva capa? La respuesta es que MCP no sustituye a la API; es una superficie distinta para un consumidor distinto. Las integraciones API tradicionales se escriben para código (un servicio backend, un plugin de CRM). MCP se escribe para agentes IA (Claude, ChatGPT, Cursor).

Una vez configurado el servidor MCP (ve la sección de acceso a la beta más abajo), el flujo del lado del usuario es conversacional. Aquí va un ejemplo real de las pruebas en beta.

Paso 1: abrir Claude Desktop y describir lo que necesitas

Escribes: "Envía el NDA de contratista a John Smith en john@acme.example, fecha límite de firma el próximo viernes, copia la cláusula de cesión de PI desde nuestra plantilla de software".

Paso 2: Claude razona sobre qué herramientas llamar

Claude llama a `chaindoc_get_template` para obtener tu plantilla de NDA de contratista, identifica los huecos variables (nombre de la contraparte, correo, fecha límite, jurisdicción) y mezcla la cláusula de cesión de PI desde tu biblioteca estándar. Luego llama a `chaindoc_create_document` con la plantilla rellenada.

Paso 3: Claude prepara la solicitud de firma

Claude llama a `chaindoc_create_signature_request` con el correo de John, la fecha límite de firma y (opcional) la verificación KYC. Devuelve una confirmación: "Documento redactado desde la plantilla `Contractor NDA v3`, enviado a john@acme.example, URL de firma activa hasta el viernes 9 de mayo a las 23:59 UTC".

Paso 4: Claude registra un webhook de estado

Claude llama a `chaindoc_subscribe_webhook` para escuchar el evento `signature.completed`, así recibirás una notificación dentro de Claude cuando John firme sin tener que consultar tú mismo. Todo el flujo lleva unos 60 segundos desde tu mensaje inicial hasta que la solicitud de firma está activa en el buzón de John.

Paso 5: verificación al completar

Cuando John firma, el webhook se dispara y Claude reporta el resultado. Puedes pedirle a Claude que verifique la firma y llamará a `chaindoc_verify_document` para confirmar el ancla blockchain, el certificado de firma y la pista de auditoría. La misma verificación que harías manualmente en /verify-document, pero dentro del chat donde empezaste.

A ver, la experiencia varía según el modelo de IA. Claude Desktop es ahora mismo el más fluido porque Anthropic creó MCP. ChatGPT vía Apps SDK funciona bien pero con algo más de latencia. Cursor y Zed son geniales si vives en un editor de código de todos modos. El protocolo está estandarizado, así que con el tiempo la experiencia debería converger entre clientes.

Cada acción que un agente IA realiza a través del servidor MCP pasa por el mismo backend de Chaindoc que gestiona las acciones humanas. No hay un camino paralelo, ni un registro separado, ni un modo de "bypass IA". La pista de auditoría captura los mismos siete campos requeridos descritos en nuestra guía de cumplimiento de pista de auditoría, con un añadido: la sesión del agente IA queda etiquetada para que se vea qué acciones fueron iniciadas por IA y cuáles por un humano.

En concreto:

• Identidad: la clave API (en beta) o el token OAuth de usuario (en GA) identifica la cuenta humana en cuyo nombre actúa la IA. Cada acción es trazable hasta una persona real, no a una identidad genérica de "agente IA".
• Autenticación: las claves API pueden tener alcance (solo lectura, escritura, admin), de modo que los usuarios beta puedan otorgar el acceso mínimo imprescindible a clientes IA específicos.
• Procedencia de la acción: el log de auditoría registra que la acción vino por MCP, además de qué cliente (Claude Desktop, ChatGPT, Cursor, etc.) y qué herramienta se llamó. Si Claude envió un contrato en tu nombre, el rastro muestra "enviado vía MCP, cliente: claude-desktop, herramienta: chaindoc_create_signature_request, usuario: alex@chaindoc.example".
• Inviolabilidad: cada entrada de auditoría está encadenada por hash y anclada a una blockchain pública, exactamente igual que las acciones humanas directas. Los contratos impulsados por IA no son menos defendibles que los enviados manualmente; en algunos aspectos son más defendibles, porque la llamada estructurada a la herramienta queda preservada junto con la instrucción humana del chat.

Para los marcos de cumplimiento subyacentes, ve nuestro artículo sobre cumplimiento de la firma digital con eIDAS, GDPR y NIST y sobre la solidez legal de las firmas electrónicas blockchain. Para los controles de acceso a nivel de equipo que rigen quién puede conectar clientes IA a tu cuenta, ve /team-management.

A mayo de 2026, ningún proveedor importante de firma electrónica ha lanzado un servidor MCP público. Las comparaciones más cercanas son anuncios de funciones IA dentro de los productos existentes (Docusign IAM y Docusign AI, las funciones de revisión IA de Ironclad), pero ninguno expone esas capacidades a agentes IA externos a través de un estándar abierto. La tabla siguiente resume el panorama.

La beta es solo por invitación, con plazas limitadas priorizadas para clientes activos de Chaindoc y organizaciones con peso técnico. Los participantes en la beta obtienen acceso gratuito hasta la disponibilidad general, soporte dedicado por Slack del equipo de ingeniería y una línea directa para solicitar funciones.

Tres formas de pedir acceso

1. 1.
   Clientes existentes: entra en tu panel de Chaindoc y busca la sección "AI Agents" en Ajustes. El interruptor de la beta está allí.
2. 2.
   Nuevos evaluadores: regístrate en /api-integration y marca la casilla "MCP beta" en el formulario de onboarding para desarrolladores.
3. 3.
   Solicitud directa: escribe a beta@chaindoc.io con tu caso de uso (1-2 frases), tamaño del equipo y qué cliente IA quieres conectar (Claude Desktop, ChatGPT, Cursor, Zed). Respondemos en dos días laborables.

Instalación, una vez tengas acceso

La beta se entrega como un paquete npm. Tras recibir tu clave API, añade lo siguiente a tu configuración de Claude Desktop (`~/Library/Application Support/Claude/claude_desktop_config.json` en macOS, rutas equivalentes en Windows y Linux):

Reinicia Claude Desktop. El icono 🔌 debería mostrar "chaindoc" conectado con siete herramientas disponibles. La primera llamada a una herramienta suele tardar 2-3 segundos.

Para Cursor, Zed y Windsurf la configuración es similar; las instrucciones completas llegan con tu invitación a la beta. El soporte para ChatGPT vía OpenAI Apps SDK está en pruebas privadas y se desplegará después de que Claude Desktop alcance GA.

La beta actual cubre la redacción, firma, verificación y seguimiento de contratos. Hay tres capacidades en desarrollo activo para fases posteriores de la beta y la disponibilidad general:

Automatización de facturación

Una herramienta `chaindoc_create_invoice` que genera una factura ligada a un contrato firmado, con condiciones de pago, líneas e instrucciones de Stripe / transferencia. La herramienta lee el calendario de pagos del contrato, genera la factura en la fecha correcta y la envía (opcionalmente) a través de la pista de auditoría existente de Chaindoc. Ve nuestro artículo sobre pagos vinculados a contratos y automatización de facturación para el flujo humano sobre el que se construye, además del análisis profundo de automatización de facturación tras la firma electrónica.

Orquestación KYC

Una herramienta `chaindoc_request_kyc` que dispara la verificación de identidad de un firmante antes de que firme. El agente IA puede razonar sobre qué firmantes necesitan KYC completo (contratos de alto valor, sectores regulados) frente a verificación ligera (NDAs estándar) y configurar la solicitud de firma en consecuencia. Hoy KYC se configura a nivel de solicitud por humanos; la meta es dejar que la IA tome esa decisión.

Flujos multiagente

Mirando más adelante, MCP soporta comunicación entre agentes. Así que un servidor Chaindoc MCP puede llamar a un servidor MCP de CRM (HubSpot, Salesforce), a un servidor MCP de calendario (Google, Outlook) o a un servidor MCP de pagos (Stripe). Un contrato firmado puede disparar una actualización en CRM, un recordatorio en calendario y la emisión de una factura, todo coordinado por el agente IA en lugar de webhooks codificados a mano. Esta es la arquitectura que convierte a la IA de una herramienta de escritura en una verdadera capa operativa.

Las funciones IA pegadas a productos existentes están por todas partes ahora mismo. Redacción automática de cláusulas, redlining inteligente, resúmenes de revisión de contrato: cada proveedor heredado las está enviando. Son útiles, pero son funciones. Viven dentro de la interfaz del proveedor y necesitan que un usuario humano dirija el flujo.

La firma electrónica IA-nativa es estructuralmente distinta. La unidad de valor no es "qué puede hacer nuestro producto por ti" sino "qué puede hacer tu agente IA en tu nombre, esté donde esté" (Claude Desktop, ChatGPT, Cursor, tu propio cliente personalizado). Eso cambia los criterios de compra. La velocidad de ejecución del contrato deja de medirse en minutos por firma y empieza a medirse en instrucciones de chat por resultado. Las pistas de auditoría dejan de ser una función defensiva de cumplimiento y se convierten en condición previa para confiar en flujos impulsados por IA.

Chaindoc apuesta pronto por que esta categoría se convierta en la dominante en los próximos 24 meses. El servidor MCP es el primer paso concreto. Si eres cliente actual, el interruptor de la beta está en tu panel ahora mismo. Si estás evaluando herramientas de firma electrónica con IA en la hoja de ruta, solicita acceso a la beta a través de /api-integration y dinos qué cliente IA quieres conectar.