MCP y facturación: arquitectura, permisos y casos de uso

Conectar un agente a facturación no consiste en pegar una API a un chat. El modelo necesita descubrir qué puede hacer, con qué argumentos y bajo qué identidad; la plataforma debe seguir aplicando permisos, validaciones y límites como en cualquier otra integración. Model Context Protocol (MCP) normaliza esa frontera sin trasladar la autoridad al modelo.

Los pasos de conexión están en la página de MCP de Factuarea; aquí analizamos qué ocurre después y cómo controlar el acceso a datos financieros.

1. Qué aporta MCP a una integración de facturación

Una API define operaciones para software que ya sabe qué endpoint llamar. MCP añade una capa de descubrimiento pensada para aplicaciones de IA: el servidor publica capacidades con nombres, descripciones y esquemas de entrada, y el cliente las presenta al modelo como herramientas disponibles. El modelo puede elegir una herramienta y construir sus argumentos a partir de la conversación.

El valor no está en reemplazar la API, sino en proporcionar contratos legibles por el host y adaptar la superficie a la identidad. Una pregunta sobre facturas vencidas puede terminar así en una consulta estructurada, no en texto que intenta imitar una base de datos.

MCP tampoco convierte al servidor en agente. El host conserva la conversación, el modelo y las aprobaciones. La documentación para desarrolladores sigue siendo la fuente de contratos, errores y límites.

2. Host, cliente, servidor y herramientas: quién hace qué

La arquitectura oficial de MCP distingue cuatro piezas que conviene no mezclar:

• Host MCP. Es la aplicación con la que interactúa la persona. Gestiona la conversación, el modelo, las conexiones y las confirmaciones.
• Cliente MCP. Es el componente de protocolo que el host crea para mantener una conexión con un servidor concreto. Un host puede tener varios clientes.
• Servidor MCP. Publica capacidades de un dominio, recibe invocaciones y las traduce a operaciones de la plataforma que protege.
• Herramientas. Son acciones o consultas ejecutables, con una descripción y un esquema de argumentos.

En facturación, el servidor no debe confiar en que el host ya comprobó todo. Autentica la solicitud, resuelve la organización, valida el permiso y vuelve a validar los argumentos antes de llegar al dominio. Después devuelve un resultado estructurado para que el host lo incorpore a la conversación.

3. El descubrimiento también forma parte del control de acceso

Al iniciar la sesión, cliente y servidor negocian capacidades. Si hay herramientas, el cliente puede solicitar su catálogo y conocer para cada una el nombre, la finalidad y el esquema de entrada. La ejecución es un paso distinto: el cliente invoca una herramienta concreta con argumentos que deben ajustarse a ese esquema.

En un sistema sensible, no basta con rechazar una operación prohibida al final. La lista descubierta debería estar recortada según los permisos efectivos. Una credencial de solo lectura no necesita ver acciones de envío o borrado; ocultarlas reduce opciones equivocadas y mejora la selección del modelo. Aun así, la invocación debe volver a comprobar el permiso, porque el catálogo pudo quedar obsoleto o un cliente podría construir la llamada manualmente.

4. Diseña credenciales con el mínimo privilegio

Empieza por la tarea, no por una credencial administrativa. Si el agente solo analiza vencimientos, concédele lectura sobre la información necesaria. Si debe crear documentos, añade ese alcance sin incorporar automáticamente envío, anulación o acciones masivas. Separa entornos y evita reutilizar una credencial personal en procesos compartidos.

Los permisos deben evaluarse en varias capas: identidad válida, pertenencia a la organización, módulo contratado, alcance de la credencial y disponibilidad de la función. La autorización del transporte no sustituye a la autorización del dominio. Del mismo modo, que una persona pueda ver una factura no implica que pueda enviarla o eliminarla.

Las prácticas de seguridad de MCP advierten contra reutilizar tokens destinados a otro servicio. Para servidores remotos: audiencia correcta, almacenamiento seguro, caducidad gestionada y alcances mínimos.

5. Separa leer, escribir, enviar y destruir

No todas las herramientas requieren la misma experiencia de aprobación. Una consulta puede ejecutarse de forma silenciosa si la política lo permite. Crear o modificar datos exige mostrar qué cambiará. Enviar una factura comunica algo a un tercero; anular o borrar puede tener consecuencias difíciles de revertir. El host debe tratar esas categorías de manera diferente.

Una confirmación útil nombra acción, documento, destinatario y efecto. Para una operación masiva, añade recuento, filtros y una muestra. El servidor debe mantener sus barreras aunque el host no muestre esa confirmación.

6. Casos de uso que sí encajan

MCP funciona mejor cuando la intención puede traducirse en una operación acotada y verificable. Algunos ejemplos razonables en facturación son:

• buscar facturas y resumir cuáles requieren atención;
• localizar un cliente por su identidad fiscal antes de proponer un alta;
• preparar los datos de una factura a partir de información ya validada;
• mostrar el documento y el destinatario antes de solicitar su envío;
• consultar información de cumplimiento o revisar una cadena de VeriFactu;
• reunir contexto para explicar un error sin exponer credenciales ni datos innecesarios.

El patrón común es consulta, propuesta, validación y acción. Un agente puede preparar la operación mientras una persona conserva la decisión financiera.

Para integraciones deterministas, la plataforma de Developers ofrece API, SDK y webhooks. MCP encaja cuando el host debe elegir una capacidad a partir de lenguaje natural.

7. Auditoría y observabilidad antes de producción

Cada invocación debería poder reconstruirse sin almacenar el razonamiento completo del modelo. Registra identidad técnica, organización, herramienta, alcances, resultado, código de error, latencia y un identificador de correlación. Para los argumentos, prioriza huellas y muestras redactadas frente a copias indiscriminadas de NIF, correos o cuentas bancarias.

Separa errores de autenticación, permisos, validación de negocio y fallos transitorios. Si todo aparece como "la IA se equivocó", el sistema no es operable. Prueba con datos controlados, revisa qué descubre cada rol y verifica que una llamada directa tampoco salta la restricción.

8. Antipatrones que conviene evitar

• Entregar una clave con acceso total para ahorrar configuración. Amplía el impacto de cualquier error y hace imposible atribuir la necesidad de cada permiso.
• Usar el prompt como política de seguridad. "No borres facturas" no sustituye a retirar la herramienta o denegar su alcance.
• Ejecutar envíos o acciones destructivas sin vista previa. La velocidad no compensa un efecto externo sobre el cliente equivocado.
• Tratar la conversación como registro contable. El sistema de facturación sigue siendo la fuente de verdad; el chat es una interfaz.
• Exponer todo el catálogo a todos los roles. Más herramientas aumentan la confusión y la superficie de riesgo.
• Volcar argumentos completos en logs. La observabilidad debe ayudar a investigar sin crear una copia paralela de datos sensibles.

Una integración MCP sólida no es la que permite al agente hacer más, sino la que hace visible únicamente lo necesario, confirma lo irreversible y deja un rastro comprensible. Ese diseño mantiene la utilidad del lenguaje natural sin renunciar a las garantías que exige la facturación.