MCP server y firma electrónica: qué cambia cuando un agente de IA envía el contrato

Una API es un conjunto de endpoints sobre los que un desarrollador escribe código. Un MCP server es un programa pequeño encima de esa API que describe esos endpoints como herramientas que un modelo de IA encuentra y llama por sí mismo. Esa es la diferencia entre MCP y API en una línea: la API es para tu código, el MCP server para un agente. En la firma electrónica decide quién elige el siguiente paso. Con la API REST de Chaindoc, tu código decide cuándo sale un contrato. Con el MCP server decide el agente, dentro de los límites de su clave. La firma nunca pasa al agente.

¿Qué es un MCP server? Es la parte servidor del Model Context Protocol (MCP), un estándar abierto que Anthropic publicó el 25 de noviembre de 2024 para conectar aplicaciones de IA con herramientas y datos externos. En diciembre de 2025 el protocolo pasó a la Agentic AI Foundation, dentro de la Linux Foundation, así que ya no pertenece a un solo proveedor de modelos. La especificación vigente lleva fecha 2026-07-28.

MCP tiene tres roles. El host es la aplicación de IA con la que hablas, el cliente es el conector que lleva dentro, y el servidor expone lo que un sistema externo sabe hacer, de tres formas:

• Tools (herramientas): funciones que el modelo puede llamar, como «crear una solicitud de firma».
• Resources (recursos): datos que el modelo o el usuario pueden leer, como el estado de un contrato.
• Prompts, tareas con nombre que un usuario puede lanzar.

Los mensajes son JSON-RPC 2.0. Un servidor funciona como proceso local que el cliente arranca (transporte stdio) o detrás de un endpoint HTTP (Streamable HTTP).

¿Es entonces un servidor MCP un servidor de verdad? A veces. Un servidor stdio es un proceso en tu equipo que arranca y se cierra con tu cliente de IA. Un servidor HTTP es un servicio que alguien tiene que alojar.

¿Por qué «MCP o API» es una falsa elección? Porque casi todo MCP server útil envuelve una API que ya existe. El de Chaindoc conecta sus herramientas con los mismos endpoints REST que llamaría tu backend. No eliges entre los dos. Eliges quién conduce: tu código o un modelo.

Los endpoints de debajo son idénticos. La diferencia entre MCP y API es todo lo que rodea a la llamada, y cinco partes de ella se notan en cuanto quien llama es un agente.

1. 1.
   Descubrimiento. Tu código conoce la API porque un desarrollador leyó la documentación. Un cliente MCP le pide al servidor su lista de herramientas (tools/list) en tiempo de ejecución y pasa nombres, descripciones y esquemas de entrada al modelo. Si conoces el function calling, es la misma idea en un formato común: un servidor sirve en cualquier cliente MCP.
2. 2.
   Quién elige la llamada. En una integración por API, la secuencia está escrita en el código y se ejecuta igual cada vez. Con MCP, el modelo elige la herramienta y rellena los argumentos a partir de tu frase, de modo que una misma petición puede seguir dos caminos distintos en dos días.
3. 3.
   Los errores vuelven al modelo. La especificación separa los errores de protocolo de los errores de ejecución de una herramienta, y los segundos están pensados para llegar al modelo, que puede corregir un argumento y reintentar. Un backend los registraría y se detendría.
4. 4.
   Las credenciales viven en un archivo de configuración. Un servidor stdio lee su clave de una variable de entorno que le pasa tu cliente de IA. Quien pueda editar ese archivo decide qué puede hacer el agente.
5. 5.
   La aprobación es cosa del cliente. La página de herramientas de la especificación MCP recomienda (SHOULD) que una persona pueda intervenir en las llamadas a herramientas y rechazarlas, y que los clientes pidan confirmación en las operaciones sensibles. Una llamada desde tu backend no tiene ese paso, salvo que lo construyas.

Sinceramente, el punto dos es el que importa en los contratos. Un script que envía un NDA envía exactamente el NDA para el que fue escrito. Un agente envía lo que entendió que querías. Para un documento que alguien va a firmar, esa distancia necesita una barrera.

El MCP server de Chaindoc es de código abierto. El código está en GitHub con licencia MIT, y el paquete se llama @chaindoc_io/mcp-server en npm, en su versión 0.2.0 cuando lo revisamos el 14 de octubre de 2026. La mayoría de las herramientas equivalen a un único endpoint REST y devuelven el resultado en una forma que el modelo sabe leer.

Las herramientas, por grupos

Las tablas principales del README listan 35 herramientas en diez grupos:

• Documentos: crear, actualizar, fijar permisos de acceso, verificar una versión, leer su estado de verificación.
• Firmas: crear una solicitud, leer su estado, listar tus solicitudes y firmar.
• Contratos, el grupo más largo: crear, listar, leer, enviar, cancelar, rescindir, leer la actividad, adjuntar una configuración de pago.
• Facturas y transacciones para cobrar a partir de un contrato firmado: crear, enviar, cobrar, marcar como pagada, listar pagos.
• Plantillas: convertirlas en un documento o un contrato, o enviarlas directamente a firma.
• Carga de archivos, sesiones de firma incrustadas, dos comprobaciones de cuenta y un verificador de webhooks.

La versión 0.2.0 añadió búsqueda, versiones, recordatorios, cancelaciones, descarga del archivo firmado con su certificado y el ciclo de vida de las plantillas.

Recursos y prompts

Recursos de solo lectura, como chaindoc://contracts/{id}/status, conviven con prompts con nombre, como prepare_signature_request, que guían al modelo en una tarea más larga.

Hay dos cosas que no hace. No registra webhooks: se configuran por clave de API en el panel, y la herramienta de webhooks solo comprueba un evento que ya recibiste. Y Chaindoc no aloja ningún endpoint: lo ejecutas por stdio o alojas tú mismo el modo HTTP.

La verificación es la parte propia de Chaindoc. El servidor calcula el hash de un archivo al subirlo; cuando se publica una versión, ese hash va a la blockchain, y la prueba de cada firmante se registra cuando termina la firma. Las herramientas de verificación comparan una versión con ese registro, de modo que un agente puede responder «¿es este el archivo que se firmó?» sin que nadie abra la aplicación.

No existe una clave de API de MCP aparte. El servidor funciona con una clave de API normal de Chaindoc, y las claves se crean en el plan Business. Las cuentas Team pueden pedir acceso a la API; Free y Personal no pueden crear claves, y los webhooks son solo de Business.

Dos límites marcan el comportamiento de un agente. El servidor se frena solo a 10 solicitudes por minuto por defecto, el límite que fija la guía de la API de Chaindoc, así que un agente que recorre cincuenta documentos es lento a propósito. Y el tráfico del agente corre por tu cuenta como cualquier llamada de API: las solicitudes que envía salen de la misma cuota mensual de firmas. Revisa los precios actuales antes de dejar que un agente envíe en masa.

En resumen: un agente puede pulsar el botón, pero la ley nunca lo trata como el firmante. Firmante es aquel por quien actúa el agente, y ahí terminan casi todas las dudas sobre contratos con IA.

En EE. UU.: ESIGN y UETA

ESIGN define la firma electrónica como un sonido, símbolo o proceso ejecutado o adoptado por una persona con la intención de firmar (15 U.S.C. § 7006(5)): la intención es de una persona. Para el software, 15 U.S.C. § 7001(h) dice que un contrato no pierde efecto porque un agente electrónico ayudara a formarlo, mientras la acción del agente sea jurídicamente atribuible a la persona obligada. La UETA, adoptada por todos los estados salvo Nueva York, atribuye la firma a quien realizó el acto (§ 9, por ejemplo por el procedimiento de seguridad empleado: con un MCP server, la clave de API), permite que un contrato se forme entre agentes sin revisión humana (§ 14) y deja que quien trató con tu agente y no pudo corregir un error anule el registro erróneo si actúa con rapidez (§ 10). Un flujo sin paso de revisión es un riesgo que construyes tú.

En España y la UE: eIDAS, Ley 6/2020 y Código Civil

El Reglamento (UE) n.º 910/2014 (eIDAS) es más estricto sobre el papel. Su artículo 3.9 define al firmante como «una persona física que crea una firma electrónica», así que un modelo no puede serlo. Una empresa que quiere marcar documentos sin una persona detrás de cada uno tiene otro instrumento, el sello electrónico, que crea una persona jurídica según el artículo 3.24. Nuestra guía sobre sellos electrónicos para empresas explica cuándo encaja.

El Derecho español llega al mismo punto. El artículo 1259 del Código Civil dice que nadie puede contratar a nombre de otro sin estar autorizado, y que el contrato celebrado sin esa autorización es nulo salvo ratificación. Un agente de IA no tiene personalidad jurídica, así que no es un representante, pero lo que hace dentro de lo que tú le permitiste lo asumes tú. El artículo 1262 ya contempla los contratos celebrados mediante dispositivos automáticos: hay consentimiento desde que se manifiesta la aceptación. Y la Ley 6/2020, en su artículo 3, da a los documentos electrónicos el valor y la eficacia de su naturaleza. Una firma simple vale, pero hay que poder probar quién la puso.

En México: Código de Comercio

El Código de Comercio dice algo parecido. Su artículo 89 define al Firmante como la persona que posee los datos de creación de la firma y actúa en nombre propio o de la persona a la que representa. El artículo 90 presume que un mensaje de datos proviene del Emisor si lo envió, entre otros casos, un sistema de información programado por el Emisor o en su nombre para que opere automáticamente. Un agente que trabaja con tu clave a través de un MCP server se parece mucho a ese sistema, así que por prudencia parte de que lo que envíe se te atribuye.

Una nota sobre la UE: el artículo 14 del Reglamento (UE) 2024/1689, el reglamento de IA, exige que las personas puedan supervisar con eficacia los sistemas de alto riesgo y decidir no usarlos o ignorar su resultado. Que un uso sea de alto riesgo depende de su finalidad (anexo III), y un agente que envía NDA no suele entrar. La idea vale igualmente: una persona tiene que poder intervenir.

La línea práctica es sencilla. Deja que el agente prepare, envíe, haga seguimiento y verifique. La firma queda con la persona cuya voluntad registra. Si dejas que un agente concreto firme un tipo concreto de documento, decídelo por escrito y con conocimiento, nunca por defecto. Tómalo como un marco, no como asesoramiento jurídico sobre tu contrato.

Cuatro puntos de un flujo de firma merecen a una persona. El centro aburrido no es uno de ellos.

• Antes de enviar nada. La confirmación de tu cliente debería cubrir cada herramienta que envía, firma, cancela, rescinde o cobra. Las llamadas de solo lectura pueden correr sin preguntar.
• Los firmantes y su orden. Una solicitud creada por el agente invita a todos los firmantes a la vez. Si el orden importa (primero aprueba el responsable, después firma el cliente), es una ruta de aprobación que configuras en la aplicación de Chaindoc en el plan Business, no algo que el agente improvise.
• La identidad, cuando lo que está en juego la exige. El KYC de los firmantes es opcional, con la verificación de identidad de Chaindoc y una cuota mensual según el plan. Decídelo por tipo de contrato, no se lo dejes al modelo.
• Lo que el agente lee. Un texto puede traer instrucciones que tú no escribiste: una línea en un PDF subido, una nota en un registro del CRM. La especificación MCP trata por la misma razón como no fiables las anotaciones de herramientas de un servidor en el que no confías.

¿Qué puede correr sin supervisión? Consultas de estado, recordatorios a personas que ya tienen el documento, la verificación de un archivo contra su registro en la blockchain. Cada documento conserva su propia pista de auditoría, así que incluso las llamadas sin supervisión dejan un registro que puedes releer.

DocuSign anunció el 4 de septiembre de 2026 que su MCP server estaría disponible para todos el 30 de septiembre, con llamadas desde Claude, ChatGPT, Gemini, Copilot, Slack y cualquier cliente MCP. DocuSign lo aloja, y la conexión pasa por un inicio de sesión OAuth y una pantalla de consentimiento en lugar de una clave pegada en un archivo de configuración. Es una ventaja real para una empresa que no quiere claves de API en laptops, y Chaindoc hoy no ofrece un endpoint alojado.

En el eje MCP vs API, los dos se parecen: cada servidor envuelve la API de su proveedor. En el control, sin embargo, el intercambio va al revés. El servidor de Chaindoc es código con licencia MIT que puedes leer, bifurcar y alojar dentro de tu propia red, y sus herramientas llegan al registro de verificación en la blockchain además de a la firma. Si comparas una conexión MCP de DocuSign con la de Chaindoc para un agente, hazte tres preguntas prácticas: quién guarda la credencial, dónde se ejecuta el servidor y qué acciones puede hacer el agente sin la aprobación de una persona.

Usa la API cuando el flujo es fijo. Una oportunidad pasa a «ganada», un contrato sale de una plantilla, un webhook actualiza el CRM cuando se firma. Eso es código, tiene que comportarse igual cada vez, y un agente solo añade variación. Si quieres automatización de documentos con IA dentro de un flujo fijo, llama a un modelo desde tu propio código y deja que la API haga el envío. Nuestra comparativa de APIs de firma electrónica explica qué mirar de ese lado.

Usa el MCP server cuando la petición cambia cada vez y hay una persona en la conversación de todos modos: «envía el contrato de prestación de servicios a las dos personas de la llamada de ayer», «¿qué NDA del mes pasado siguen sin firmar?», «¿este PDF es la versión que firmamos?». Es incómodo de programar y fácil de decir. Un ejemplo: una startup en Madrid o en Ciudad de México deja que un agente prepare y envíe contratos de prestación de servicios, y quien firma es la persona con nombre y apellidos, desde el enlace.

La mayoría de los equipos acaba con los dos, en claves separadas, y esa es la respuesta honesta a MCP server o API. La API ejecuta lo que ya decidiste. El agente se ocupa de lo que aún no decidiste. En ambos casos la firma se queda con una persona.