Resultado del proyecto final

Una integración de MCP lista para producción no es simplemente un agente capaz de llamar a una herramienta. Es una aplicación que conecta un agente de IA con herramientas o datos aprobados, gestiona cada solicitud mediante un cliente MCP y ofrece a los usuarios un registro fiable de lo ocurrido. En este proyecto final, diseñarás y evaluarás todo ese recorrido mediante solicitudes realistas, incluidas aquellas que sean ambiguas, inseguras o imposibles de completar.

Mantén diferenciados los roles. El host es la aplicación que gestiona la experiencia del agente y sus clientes MCP. Un cliente MCP mantiene una conexión con un servidor MCP. El servidor expone capacidades como herramientas o recursos. El modelo puede ayudar a seleccionar una acción, pero el host sigue siendo responsable de las decisiones de política, la interacción con el usuario y la comunicación de los resultados. No consideres una instrucción del modelo ni la descripción de una herramienta como un límite de autorización.

Define la solicitud y los límites

Comienza con un flujo de trabajo concreto, como la clasificación inicial de un ticket de soporte. Documenta qué puede solicitar el usuario, a qué datos puede acceder la aplicación y qué acciones pueden modificar el estado externo. Un conjunto inicial de capacidades útil incluye una consulta de tickets de solo lectura y una acción que modifique el estado, como añadir una nota interna. Especifica las entradas permitidas, el resultado esperado y el requisito de autorización de cada acción antes de conectar el agente.

Separa la recopilación de información de las decisiones con consecuencias. La aplicación puede recuperar un ticket y redactar una nota sugerida sin modificar nada. No debe añadir la nota ni cambiar el estado del ticket hasta que el usuario confirme la acción y el objetivo exactos. Si la solicitud no identifica un ticket o si la información recuperada deja una incertidumbre importante, formula una pregunta aclaratoria en lugar de hacer suposiciones. Utiliza datos de sandbox para el desarrollo y la evaluación; no uses registros reales de clientes para que una demostración parezca realista.

Construye la ruta de MCP

Conéctate al servidor mediante un cliente MCP compatible con el SDK y el transporte que hayas elegido. Para un servidor local, la entrada y salida estándar pueden ser adecuadas; para un servidor remoto, utiliza un transporte HTTP compatible y configura su seguridad de forma deliberada. Trata el transporte, el SDK y la versión del servidor como dependencias explícitas del proyecto. Registra la identidad y las capacidades esperadas del servidor al iniciarse, y produce un error claro si falta una herramienta requerida o si su esquema de entrada anunciado es incompatible con tu aplicación.

Usa el descubrimiento y la invocación de MCP como operaciones del protocolo, no como nombres inventados para el modelo. El cliente puede descubrir las herramientas disponibles mediante tools/list e invocar una herramienta seleccionada mediante tools/call. Los servidores también pueden exponer recursos, que los clientes pueden descubrir y leer mediante las operaciones de recursos correspondientes. Solicita únicamente las capacidades que necesita este flujo de trabajo. Antes de invocar una herramienta, el host debe comprobar su propia política, validar los argumentos según las expectativas de la aplicación y obtener confirmación cuando sea necesario. Después de la invocación, valida el resultado antes de devolvérselo al agente o presentarlo como un hecho.

Aplica la seguridad y la fiabilidad

Los esquemas y las descripciones de las herramientas ayudan al agente a comprender una capacidad, pero no demuestran que una llamada sea segura. Las anotaciones, como las indicaciones de solo lectura o destructivas, son metadatos útiles, pero no sustituyen a la política de la aplicación. Aplica el control de acceso mediante los permisos del servidor y las propias comprobaciones de autorización del host. Proporciona al servidor credenciales únicamente para las operaciones y los registros que necesita, almacena los secretos fuera de los prompts y del control de versiones, y utiliza los mecanismos de autorización remota adecuados para el transporte seleccionado.

Trata tanto los argumentos generados por el modelo como el contenido devuelto por el servidor como entradas no confiables. Valida los identificadores, los valores de estado permitidos, la longitud del texto y los permisos relevantes de cada usuario. La salida de una herramienta puede contener datos incorrectos o instrucciones destinadas a manipular al agente; no puede anular la política del host. Establece timeouts y proporciona una ruta clara para los errores. Reintenta únicamente las operaciones que sepas que es seguro repetir, ya que reintentar una solicitud que cambia el estado después de un timeout incierto puede crear efectos duplicados. Cuando sea compatible, gestiona la cancelación y cierra correctamente las conexiones del cliente y del servidor.

Evalúa de extremo a extremo

Prueba el flujo de trabajo completo del usuario, no solo si se abre la conexión MCP. Incluye una consulta sencilla, una solicitud que necesita aclaración, una solicitud para realizar un cambio, un usuario que rechaza la confirmación y un servidor que agota el tiempo de espera o devuelve un error. Añade un caso en el que la salida de la herramienta contenga una instrucción que entre en conflicto con la política de la aplicación. Para cada caso, especifica la respuesta visible para el usuario y si se permite realizar una llamada a la herramienta.

Mide el comportamiento observable. Registra si se seleccionó la herramienta prevista, si los argumentos superaron la validación, si se produjo una aprobación obligatoria y si la respuesta final coincide con el resultado real de la herramienta. Una prueba solo se aprueba si la aplicación rechaza las llamadas inseguras y describe los errores con precisión. Revisa los logs y las trazas con suficiente detalle para diagnosticar una solicitud fallida, redactando las credenciales y limitando los datos confidenciales del usuario. Informa sobre la cobertura de las pruebas y las limitaciones conocidas en lugar de afirmar que una suite de pruebas pequeña demuestra la seguridad general.

Publicación y revisión

Antes de la publicación, fija las dependencias, documenta la configuración del servidor MCP y del transporte, y asegúrate de que la aplicación falle de forma segura cuando no estén disponibles la configuración o las capacidades necesarias. Revisa los controles de acceso, la gestión de credenciales, la exposición de red, los timeouts y la retención de logs. Mantén separadas las configuraciones de los servidores de desarrollo, pruebas y producción. Los cambios en el esquema de una herramienta o en la implementación del servidor deben activar pruebas de compatibilidad y seguridad antes del despliegue.

El entregable final es una aplicación reproducible, no una captura de pantalla exitosa. Incluye los pasos de configuración, los límites de confianza, las acciones que requieren aprobación y los resultados de las pruebas. Un revisor debe poder ejecutar la aplicación con datos de sandbox, reproducir tanto una consulta exitosa como una acción rechazada o fallida, y verificar que el mensaje final nunca afirme que se realizó un cambio a menos que el servidor lo haya confirmado. Estos estándares hacen que la integración sea comprensible, comprobable y más segura de operar.