Lecciones de la Construcción de un Servidor MCP Remoto Empresarial

Soy Hemant. Soy un gerente senior de aprendizaje automático en PayPal. También soy GD en el dominio web y de pagos. Soy miembro de la comunidad DuckDuckDuck. He tenido la suerte de ser parte de TC39, contribuir un poco aquí a Node.js. Y puedes encontrarme en h3man.com o en Gnument, y ese es el código QR.

Así que si eras un usuario de chat GPT o de cualquiera de esos usuarios en ese entonces, si lo eras y decías, oye, ¿qué hora es o cómo está la fecha? Te habría respondido diciendo que no tengo acceso a datos en tiempo real, o diría, oye, probablemente habría inventado una hora o fecha, ¿verdad? Pero si abro un terminal y simplemente digo el comando date, vería la fecha y la hora. Funciona bien.

Lo mismo. A veces podría pedir dos respuestas diferentes y decir cuál es mejor. Y ambas son igualmente malas en este caso donde dice, oye, probablemente deberías preguntar a Siri o Google o usar tu hora local. Realmente no tengo acceso al tiempo. Y estas son como capturas de pantalla reales. Entonces, ¿por qué sucede eso? Sucedió porque todos estos modelos están entrenados en un conjunto de datos particular y tienen un conocimiento de corte. Como puedes verlo en el gráfico, cada uno de estos modelos tiene un conocimiento de corte para un mes particular más allá del cual realmente no saben. Y dentro de esa fecha también, a veces alucinan.

Entonces, ¿cómo habilitamos a estos modelos para que puedan acceder a toda esta información? Ahí es donde las herramientas entraron en escena o la llamada a funciones o la llamada a herramientas donde puedes habilitar al modelo para hacer una llamada a una herramienta y averiguar cuál es la hora o cuál es el clima en este caso. Correcto. Estoy diciendo cuál es el clima en Fremont. Puedes ver aquí que el LLM está haciendo una llamada a weather.com y obteniendo el clima. El pronóstico parece ser de 67 de máxima y 53 de mínima. Y eso parece ser lo máximo aquí, lo cual es interesante. Y lo mismo con Gemini o cualquier otra cosa. Si dices cuál es la hora, probablemente diría la hora y la fecha correctas porque ahora puede hacer una llamada a una herramienta y averiguar cuál es la hora de la fecha.

Así es como funciona el baile de la llamada a funciones, ¿verdad? El usuario entraría y pasaría un prompt a la aplicación y la aplicación luego diría, oye, aquí están el conjunto de funciones que tengo. Y lo envía como contexto al modelo. Y basado en el prompt, el modelo determina, oye, necesito llamar a esta función particular con este identificador. Estos son los parámetros requeridos. Hace la llamada a la función. La llamada a la función internamente probablemente llamaría a una API, regresaría con una respuesta. El modelo tomaría la respuesta, la ajustaría más y la enviaría de vuelta a la aplicación y la aplicación se la muestra al usuario.

Así es como funciona el baile de llamada a funciones. Sí, está bien. Vimos que la llamada al clima está sucediendo. También puedes hacer la llamada de hora o de fecha, cualquier llamada que quieras hacer. Puedes escribir una función. Todo funciona bien.

Aquí hay un ejemplo clásico de cómo se vería la definición de una herramienta o función para una llamada a herramienta. Dirías que es un tipo de función y luego dirías en este caso que es una función de obtener clima, que espera algunos parámetros, tal vez ubicación y unidad en este caso. Y decimos que la ubicación es requerida porque si el usuario está pidiendo el clima de una ubicación particular, necesito saber la ubicación y ese es un campo requerido.

Y aquí hay otro ejemplo. Podrías encontrar tales experimentos que hago en mi enlace de GitHub allí en Notebooks. Este es un ejemplo bastante antiguo aquí donde estoy usando pequeños agentes y usando la búsqueda de Dr. Go como herramienta y usando una API de hugging face para el modelo y diciendo cuál es la fecha de hoy. Porque estoy usando un agente de código aquí.

Podrías ver que el modelo escribió una especie de fragmento de código y luego ejecutó ese fragmento de código para obtener la respuesta. Y dijo, OK, la fecha de hoy es XYZ. Y otro ejemplo, una cosa similar de un agente. Si recuerdas, había un modelo llamado PAM hace mucho tiempo antes de que llegaran Gemini y otros. Así que al usar modelos PAM aquí de Google, estoy usando Dr. Go nuevamente y luego creando un agente y haciendo agent.run y diciendo, oye, ¿quién es Haman.HM? Podría hacer una búsqueda en Dr. Go por ti y regresar con el resultado. Funciona bien.

Pero lo que pasó es que había muchos LLMs y muchas APIs. Di un par de ejemplos de, digamos, clima o tiempo. Pero imagina que hay como una plétora de aplicaciones con las que necesitas hablar y tienes que escribir funciones y cada una de ellas se comporta de una manera diferente. Y necesitas escribir funciones para cada una de ellas. Y hay problemas de n por m donde n son LLMs y n número de APIs que necesitas manejar como desarrollador. Ahí es donde se vuelve complejo. Y la gente decía, oye, esto es demasiado para manejar.

Y estaban discutiendo, sí, necesitamos definir un estándar. Y este es un chiste clásico de XKCD que me encanta, que dice que hay estas dos figuras que están discutiendo y diciendo, sabes, ya hay como 14 estándares. ¿Qué hacemos? Y dijeron, oye, necesitamos definir otro, el número 15. Y ahí es cuando sucedió MCP. Todos sabemos que fue el 25 de noviembre de 2024 cuando Antropic lanzó MCP y dieron esta hermosa analogía de un USB 3. Tal vez le haga clic a la mayoría de ellos, pero fue un poco complicado para mí decir, ¿cómo se relaciona USB 3 con esto?

Así que vamos a desglosar rápidamente cómo funciona MCP. MCP es este protocolo abierto, como dice, model context protocol. Y cómo el modelo se comporta basado en el contexto que tiene.

Y este es un protocolo abierto basado en JSON RPC, lo que facilita que el cliente y el servidor se comuniquen en un conjunto de protocolos predefinidos, lo que facilita la llamada de herramientas. Así que vimos el meollo del problema donde la llamada de herramientas era compleja y la gente decía, oye, esto es demasiado para manejar. Pero MCP dijo, oye, déjame definirlo en una aplicación específica para que todos puedan adherirse a ella.

Y en este ejemplo, ves muchos servidores MCP. Son hechos por Slack o Gmail o tu Google Calendar y demás, que pueden ser como un servidor MCP, que puede hablar con el cliente y hay un intercambio de herramientas, datos y recursos. Y las cosas se volvieron fáciles y la vida se hizo más sencilla porque ahora, como desarrollador, no necesito romperme la cabeza sobre cómo se implementa MCP.

Solo necesito usar eso como un endpoint y mi cliente MCP habla con el servidor MCP. Entonces, ¿qué ves en la parte superior derecha donde está la nube o OpenAI o Cursor? Todos ellos son hosts MCP que tienen clientes dentro de ellos, que pueden hablar con MCPs. Así que MCP puede ser local y puede ser remoto. Local es algo que se ejecuta en tu dispositivo. Probablemente lo descargas de PIP o un NPX y lo ejecutas en tu dispositivo. Y remoto es, por supuesto, tiene una URL, tiene un endpoint. Está en algún lugar en la nube y simplemente te conectas a él. Y también puede acceder a tus datos locales. Puede hacer llamadas API.

Ahora el modelo está enriquecido con muchos datos y contexto y es muy fácil comunicarse porque es un estándar. No hay mezcla y combinación de herramientas y parámetros que necesiten ser pasados y no hay un juego de adivinanzas que esté ocurriendo. Así que MCP no solo viene con herramientas, ¿verdad? Viene con una plétora de atributos aquí, tal vez recursos, prompts, herramientas, muestreo y transporte y rutas. Y también hay elicitación hoy. Así que rápidamente sobre estos recursos son un tipo de entidades que exponen datos a tus LLMs, ¿verdad? Los recursos se utilizan incluso para exponer, digamos que quieres exponer una DB o archivo, o podría ser un HTML que necesita ser renderizado en el cliente.

Todo eso viene a través de recursos. Y los prompts son básicamente plantillas. Si tienes un comando slash, puedes hacerlo con prompts y herramientas. Viste qué herramientas para donde podrías hacer la llamada de herramientas y el LLM puede averiguar qué herramientas tienes. Hace una llamada de herramienta y obtiene una lista de todas las herramientas con la descripción del contexto. Entiende lo que hace esta herramienta a partir de la descripción y demás. Y el transporte y las rutas también están incluidas como parte de la especificación. La elicitación es interesante donde puedes tener un ida y vuelta entre el usuario, ¿verdad? Si hay un flujo, digamos un flujo de incorporación para un comerciante, donde el LLM necesita hacer un cierto conjunto de preguntas y entender el contexto, eso también se puede hacer a través de MCP.

Hay diferentes tipos de transportes. Los eventos de sub-aside se iniciaron inicialmente para MCPs remotos, pero están algo obsoletos y se aconseja usar HTTP transmitible. STO estándar, para cualquier cosa que estés haciendo localmente y haciendo una prueba rápida, probablemente usarías un STO estándar. Y HTTP transmitible también puede tener un respaldo a tener SSE, donde el usuario hace un POST. Básicamente, el cliente hace un POST al servidor. Y del servidor al cliente, sería una llamada GET. Así que tendrías una transmisión HTTP, lo que facilita la vida, tanto para el cliente como para el servidor. Así que siempre se aconseja tener un HTTP transmitible como tu predeterminado y no preocuparse realmente por SSE. Pero si eres un adoptador temprano y ya tenías SSE funcionando, deberías tener un respaldo. Así que las personas que todavía están tratando de conectarse a SSE deberían poder hacerlo con el mismo endpoint con transmisión, que puede retroceder a SSE si es necesario. La especificación también menciona esto sobre por qué están optando por HTTP más SSE como transporte y por qué SSE está siendo algo obsoleto. Así que fui y leí toda la especificación hasta esa fecha y creé un POST en el repositorio de MCP donde podrías ir y ver cómo funcionan todas estas cosas, cómo herramientas, recursos, prompts. Tenía un repositorio diferente para la elicitación también, que habla sobre cómo funcionan todas estas cosas dentro de MCP, lo cual es un buen repositorio para participar.

Hablando de la arquitectura MCP de PayPal, tuve la suerte de ser parte del equipo Tiger en PayPal, donde fuimos una de las primeras empresas en lanzar MCPs remotos. Y lo hicimos a una velocidad relámpago de cinco días, lo cual es súper divertido y loco para una empresa. Y compartiré algo de mi experiencia siendo parte del equipo. Así que mirando rápidamente la arquitectura de cómo es hoy el MCP remoto de PayPal, tenemos algunas capas aquí. Tenemos la capa de usuario, por supuesto, donde los usuarios están tratando de comunicarse con el servidor MCP de PayPal. Tenemos la capa de aplicación. Tenemos el modelo y la capa de API. Y luego tenemos la capa de datos. Parece que hay muchas cajas, pero piénsalo como un flujo fácil, ¿verdad? Como usuario, abro, digamos, cloud o cloud CLI o chat GPT o donde sea y conecto mi servidor MCP. Y simplemente iría y escribiría un prompt. Podría decir, ¿cuáles son mis últimas transacciones? O podría decir, oye, ve y créame una factura por $50 y envíala a Sam en gmail.com, ¿verdad? Así que sería un prompt en lenguaje natural que se descompone. Y luego el LLM descubre que necesito hacer una llamada a PayPal. Y hay un conjunto de herramientas que tengo. Oh, esto parece ser una factura, llamaré a la herramienta de facturación y pasaré los parámetros y se realiza la creación de la factura, ¿verdad? Así que en el flujo, el flujo del usuario está en la parte superior donde podría ser cualquiera de tus clientes MCP hechos por Cloud o GPT, o podría ser un inspector MCP donde estás tratando de probar el MCP remoto localmente. Y luego haces una solicitud. Va a la capa de aplicación donde tenemos un agente MCP que utiliza el kit de herramientas de PayPal. Y sabe que hay una lista de herramientas que tengo, lo que también activa OAuth si es necesario.

Mira en el encabezado. Si hay un token de portador, lo usará. Y luego todo esto está alojado hoy en CloudFlare, lo cual es maravilloso. Así que tuvimos al equipo de CloudFlare también trabajando con nosotros cuando hicimos el lanzamiento inicial. Y luego tenemos la tienda KB para lo que queramos almacenar, ya sea el token de acceso y demás. Así es como funciona el flujo.

Y veamos rápidamente el caso de uso que estaba mencionando en términos de crear una factura. Así que a la izquierda, tenemos al usuario, luego tenemos el cliente MCP, luego tenemos el agente, luego tenemos el servidor. Tenemos el toolkit de PayPal y la API de PayPal. Así que el baile es bastante regular. El usuario entra, pone los prompts, va al cliente, cierra, el cliente habla con el agente, el agente habla con el servidor, luego habla con el toolkit de PayPal, que aún puedes ejecutar localmente, que tiene todo el conjunto de herramientas, que habla con la API de PayPal.

Y es entonces cuando todo el flujo funciona sin problemas y el LLM puede entender qué herramienta llamar, cuál fue el prompt del usuario, qué parámetros debo pasar. E interesantemente, ¿qué pasa si hay un error? ¿Cómo me recupero? Así que todo eso es hermoso de ver cuando el LLM entra en escena donde puede entender bien el contexto. Veamos un ejemplo rápido aquí de usar Antropix SDK para conectarse al servidor MCP de PayPal. Ahora podemos conectarnos al servidor MCP remoto de PayPal usando Antropix SDK.

Aquí está la factura que se ha creado para la solicitud que pasamos. Así que ese es el resumen muy rápido de cómo podríamos conectar. Solo necesitas pasar el endpoint, pasar tu token, y deberías poder hablar con las herramientas. Y ahí es donde comienza la historia de terror de MCP. Si estás en este espacio, probablemente habrás leído una plétora de casos donde un token de acceso personal se filtró o las personas tuvieron acceso a sus repositorios privados y demás.

Así que la especificación de MCP hoy también agregó una sección para seguridad, que eventualmente no estaba en la especificación. Debido a todo esto que sucedió en la industria, la especificación evolucionó para agregar más detalles sobre qué es la seguridad y cómo debería manejarse. Así que desglosando eso, podrías decir que uno de ellos es el "confused deputy". Entonces, lo que sucede aquí es que si estás usando un ID de cliente estático, por supuesto, si es estático, está fijado a un cliente. Puede filtrarse. Puede compartirse y las cosas pueden salir mal. Así que no hagas eso. Ese es un camino para la explotación. Así que obtén el consentimiento del usuario por cliente. Así que cada vez que un cliente MCP intenta conectarse a un servidor MCP remoto, obtén el consentimiento, tal vez a través de OAuth o un token de acceso que se ha pasado. Ten el consentimiento del usuario.

Luego, el siguiente es el paso del token. Asegúrate de que el token que se emite para tu servidor es el que se está utilizando. Esto previene cualquier pérdida de datos o tal vez eludir que el token se pase y alguien más lo use, lo cual no está destinado para este usuario desde el cliente que debería estar usándolo. Pero fue a una superficie diferente. Así que MCP abre una gran superficie para ataques. Correcto. Así que debes ser muy cuidadoso con la solicitud que está llegando. La tercera parte es el secuestro de sesión, donde puedes hacer inyección de prompts o suplantación. Hay otra maravillosa masterclass a continuación sobre cómo puedes usar LLMs para atacar y también cómo podemos protegernos de estos ataques. Pero la regla principal, el fundamento es muy simple. Correcto. Es como validar todos tus tokens. Cualquier token que estés recibiendo, por favor, valídalo y verifica la solicitud. Asegúrate de que sea una solicitud autorizada, autenticada y mantén los límites de confianza.

Por límites de confianza, digo, oye, si este ámbito de autenticación está destinado a acceder a herramientas XYZ, solo podrán acceder a herramientas XYZ para eso, hasta que la autenticación expire. No es que puedan usar todas las herramientas que están en el conjunto de herramientas. Así que puedes también mantener esos límites de confianza. De este modo, puedes mejorar y no ser atacado en la superficie.

Ahí es cuando comienza la lección uno sobre lecciones de seguridad de la arquitectura de seguridad de múltiples capas. La idea de la arquitectura de seguridad de múltiples capas es validar, como dije, validar todas tus entradas en el límite y luego implementar un principio de privilegio mínimo, diciendo que, oye, este token está destinado a usar XYZ y solo usará herramientas XYZ y no más. Y también tengo tu almacenamiento seguro de tokens, ¿verdad? Así que puedes tenerlo en un almacén seguro, ver si es válido. ¿Debería re-autenticar, debería crear un nuevo token de acceso?

Y hay todo un baile de autenticación de auth 2.0 sobre el registro dinámico de clientes y demás. Así que siempre es bueno tener algún tipo de encabezado donde te asegures de que esta es una solicitud que mi servidor reconoce y está autorizado para usar. Así es como te aseguras de que tener autenticación es crucial. Y en el lanzamiento inicial que hicimos, teníamos la autenticación como parte del flujo, ¿verdad?, lo cual era un mandato para nosotros. Y nuevamente, hay dos flujos diferentes aquí.

Por flujos de cliente, quiero decir, el usuario podría entrar y cuando intenta usar la herramienta, puede iniciar sesión en PayPal o iniciar sesión en cualquier superficie, hacer el baile de autenticación regular en el cliente, dar un consentimiento y luego comenzar a usar las herramientas. O podría ser que tienen un secreto del lado del cliente. Son un desarrollador en el lado del comerciante. Tienen un secreto del lado del cliente del cual podrían ir adelante y crear un token y usar ese token en el flujo. Así es donde se aplica la estrategia de autenticación dual. Es decir, si es solo del lado del cliente o si es de primera parte o de tercera parte. Correcto.

Así que en el fragmento de código que ves allí, nos aseguramos de que si el usuario ha iniciado sesión y pasó por los flujos de identidad regulares de PayPal donde están haciendo la autenticación, entonces respetamos eso. Nos aseguramos de que se dé el consentimiento y obtenemos el token de vuelta y lo usamos. O vemos si es una tercera parte donde ocurrió el inicio de sesión o si es una primera parte donde el comerciante está pasando el token de acceso. Así que ambas estrategias duales se aplican, lo que ayuda a tener un alcance estrecho y no expandir todo el conjunto de herramientas MCP a todos.

La bandera de características es importante. Supongamos que tienes un conjunto de herramientas MCP que deseas habilitar para un conjunto de desarrolladores o están inscritos para una característica experimental o son elegibles como socios para usar un conjunto de herramientas, entonces puedes tener una bandera de características, donde también podrías tener TTLs cortos en ellas y asegurarte de que sea descubrible. Y en esta bandera de características podrías decir, oye, OK, sé que este cliente es elegible para esto y tener una bandera de características establecida para este cliente. Ahora puedo servirles herramientas adicionales si es necesario o no. Así que ese es el beneficio de tener una bandera de características. Y nuevamente, las herramientas de organización y el alcance en la esquina derecha donde ves la categoría de herramientas, tenemos nuestras propias 42 herramientas para primera parte. Tenemos dos herramientas para tercera parte y para comercio tenemos dos.

Y esto está evolucionando y construyendo más herramientas de este tipo basadas en los casos de uso. En este nivel de arquitectura, podríamos delimitar y decir, oye, sabes, esto es de primera parte. Así que los mostraré con herramientas X, Y, Z. Esto es de tercera parte. Puedo hacer solo dos herramientas si es necesario. Correcto. Esto te ayuda a organizar las herramientas por nivel de acceso y usar importaciones dinámicas en el conjunto de herramientas en lugar de cargar todo el conjunto de herramientas de una vez. Podemos hacer una importación dinámica y cargar lo que se requiere. Correcto. Y eso también te ayuda a mantener el alcance.

Y estrategia de despliegue en producción. Cuando comenzamos, teníamos un trabajador de CloudFlare al que estábamos desplegando rápidamente y probando si nuestros flujos funcionaban. ¿Puedo conectarme a este MCP remoto y tal? Es bueno tener esta estrategia donde podrías decir, oye, sabes, solo construye y despliega a Sandbox. Y deberías desplegar y devolver una URL de Sandbox para ti, lo cual es fácil para ti o para los desarrolladores. Es más una lección de DX donde también tienes una estrategia de despliegue que dice, ¿debería ir a stage? ¿Debería ir a Sandbox? ¿Debería ir a producción? Y todo esto debería ser una configuración muy fácil, que es una forma estándar de hacerlo. Pero es bueno tenerlo como parte de tu ciclo de vida de desarrollo de MCP.

Tipo, seguridad y experiencia del desarrollador. Por supuesto, tienes que asegurarte de que todos tus tipos definidos para tus APIs estén bien definidos. Y, sabes, hay una buena cantidad de código de prueba escrito y no hay fugas en términos de tipo. Si estás escribiendo una definición de herramienta, entonces, sabes, OK, que el tipo no coincide. Tengo que asegurarme de que todo esté bien. No es que durante el tiempo de ejecución, sino más bien en el momento de la definición de la herramienta cuando estás codificando, deberías poder darte cuenta. Y por supuesto, con toda la asistencia de LLM, es fácil si puedes dar una definición de tipo y pedirle que escriba una herramienta para ti. También lo haría instantáneamente por ti. ¿Verdad?

Hay algunos en la sala. 402 es como una solicitud de pago, un método de pago requerido dentro de HTTP. Es un estándar. Pero X402 es básicamente una extensión de eso de Coinbase, que dice, oye, sabes, si quiero enviar dinero a la primera persona aquí en la audiencia y resulta que tienen una billetera cripto, diría, oye, ¿sabes qué? Envía 10 PYUSD. PYUSD básicamente es un PayPal USD, que es una moneda fiat estándar, que puedes usar en blockchain. Podría decir envía $10 o 10 PYUSD a Daniel. Entonces debería poder hacer eso sin un intermediario. Ese es todo el punto, ¿verdad? Porque hay blockchain y hay una capa que puede facilitarme y decir si la dirección de Daniel es correcta, si la persona que está enviando, ¿tienen 10 PYUSD? Entonces podría enviarlo directamente. Así que hay menos sobrecarga en el comerciante y en los clientes. Y es bastante instantáneo. También puede suceder en la Web. Así que si miras en la esquina derecha, tenemos una herramienta de servidor donde podrías ir y tener un X402 implementado en eso. Así que cada vez que se hace una llamada, puedes usar X402 y decir, oye, sabes, para esta llamada de herramienta, probablemente necesitarías pagar como 5 PYUSD. O también podría ser como enviar dinero a Daniel, que puedo usar esta capa y enviarlo. Esto es algo que aún no hemos implementado, pero es interesante, ¿verdad? Mientras comparto algunas lecciones de hablar con algunos de los otros expertos en la industria, X402 es un protocolo muy interesante para implementar. Eso habilitaría mucho comportamiento amigable agentic, ¿verdad? Si hay algún tipo de pago agentic que necesita suceder o estamos viendo mucha experiencia de compra que está surgiendo y todo ese GPT o nube y áreas como Gemini shop, Google shop y similares. Ayuda a esa experiencia agentic donde enviar dinero o pagar y básicamente el intercambio de moneda se vuelve más fácil con este protocolo. Y es un estándar HTTP. Así que es maravilloso ver dónde se está aprovechando blockchain de una manera muy positiva. Esto también puede ser parte de una herramienta MCP. Pero la lección aquí es, digamos, si eres una empresa y tienes alrededor de 40 APIs para comenzar, es muy fácil para ti escribir un servidor MCP hoy. Podrías simplemente enviar un prompt a un LLM y decir, oye, sabes, estos son mis esquemas de API abiertos, ve y escribe un servidor MCP para ello. LLM puede hacerlo fácilmente. Pero, ¿deberíamos hacerlo? Es una pregunta mayor. Así que uno de los estudios LLM más capaces hoy en día no puede manejar más de 40 herramientas. Correcto. Entrará en un lío y llorará. Es como, ¿qué está pasando? Demasiado contexto. Así que es muy importante que des un paso atrás y mires qué estás tratando de resolver con tu MCP. ¿Qué es lo que el usuario está tratando de hacer? ¿Cuál es su viaje y cómo puedo probablemente integrar cuatro, cinco, seis APIs en una sola herramienta en lugar de abrir todas tus APIs como herramientas independientes en sí mismas? Mira una imagen más amplia y ve cuál es el viaje del usuario aquí y cuál es el conjunto de APIs que están usando y cómo puedo combinar eso y exponerlo como una herramienta. Así que eso hace que sea menos una sobrecarga para el modelo y también un menor número de herramientas y más rápido en términos de orquestación. No hay mucho ida y vuelta.

No hay mucho ida y vuelta. Así que no envuelvas todas tus APIs, lo cual es fácil de hacer. Pero no lo hagas. Aquí hay otro ejemplo de Rick Roll. Solo quiero decir roll me. Buscando herramientas disponibles, hizo la llamada a Rick Roller y ahí estaba el widget. Auto play true. Confirmar. Y esto debería cargar el video de recall. Feliz viernes. Sí, es realmente fácil tener estos recursos MCP para renderizar interfaces de usuario. Si estás siguiendo el SDK de la app liberada por OpenAI, he creado un módulo pip llamado Create App, Create Open AI app, que crea una app GPT, que crea una app que puede ejecutarse en superficies GP. Todo lo que hace internamente es hacer una llamada a un MCP y devuelve un recurso de UI. Si miras en la esquina derecha, que dice UI, widget, Rick Roller, HTML, ese HTML tiene este enlace de video y el cliente simplemente lo renderiza. Así que piénsalo más como widgets de los años 2000. Pero ahora se está integrando más en las superficies usando MCP. Y esto es realmente interesante porque va a desbloquear muchos casos de uso. Ya sea el clásico enviar dinero para iniciar sesión en odds para todo lo que puede suceder en la app misma. Ahora mismo, el usuario no está cambiando entre múltiples apps, sino teniendo todo en la misma superficie. Así que es importante aprovechar los recursos MCP para UI.

Así que sucede que todo lo que hemos escuchado hasta ahora, estamos construyendo MCP de la manera incorrecta. Si has estado siguiendo, Antropic presentó la ejecución de código y Cloudflare también habló sobre el modo de código y demás. Correcto. Entonces, lo que hemos perdido hasta ahora en todo el viaje de MCP es, como mencioné, la sobrecarga de contexto. Así que si tienes 40 herramientas, se registran y dan toda la definición de herramientas y todo al modelo, lo que llena el contexto rápidamente. No solo eso, en términos de conversación de múltiples turnos de ida y vuelta, este contexto sigue creciendo y sigue pasándose al modelo. Correcto. Ahí es donde ocurre la sobrecarga de la ventana de contexto, donde tienes muchas herramientas y traen su contexto, lo que explota el contexto para el modelo. Y se vuelve loco o es la explosión de datos intermedios que ocurre que, como mencioné, si estás haciendo demasiado ida y vuelta y estás enviando el mismo contexto de nuevo, y sigue construyéndose y el modelo se vuelve loco. Correcto.

Entonces, ¿cómo se puede resolver esto? La otra parte también está en la privacidad y la composición. Pero llegaré a esa parte. {{^}}Entonces, ¿cómo se puede resolver esto? Correcto. Si vuelves a los primeros ejemplos iniciales donde te mostré sobre preguntar la fecha, vimos un agente de código que construyó una especie de fragmento de código y ejecutó ese código. Y hizo un trabajo hermoso al obtener la fecha. Correcto. Así que resulta que los LLMs son súper inteligentes en escribir el código. Entonces, ¿por qué no aprovechamos eso y decimos, oye, LLM, en lugar de hacer una llamada a una herramienta, aquí hay un conjunto de APIs. Ahora, ve y escribe un código que tenga este flujo de trabajo, un flujo de trabajo hermoso sobre cómo probablemente debería suceder el checkout. Estas son las APIs que necesitas orquestar. Ahora, ve y escribe un código y luego ejecuta ese código y usa ese resultado como una llamada a una herramienta. En lugar de que yo pase toda la API y la definición de la herramienta y explote el contexto, diría aquí hay un conjunto de APIs. Ahora escribe el código y ejecuta ese código para este flujo de trabajo. Cloud skills es ese caso clásico. Correcto. Pero cloud skills está haciendo lo mismo en la nube. Donde dijeron, oye, cloud skills es una carpeta. Es una especie de directorio que tiene todo este código, fragmentos, naples y cómo funciona. Así que cada vez que el LLM quiera, ejecutará un fragmento de código en lugar de tomar todo el contexto. Correcto. Así que la misma estrategia se expande a la ejecución de código en MCP. Y esto definitivamente será como MCP 2.0, si pudiera llamarlo así, porque esto va a cambiar la dirección porque hemos alcanzado un cuello de botella. Hemos alcanzado un techo en el manejo de múltiples herramientas. Correcto. Si has estado usando MCPs y conectando las herramientas, también lo habrías enfrentado. Así que esto definitivamente ayudará en términos de hacer MCP más eficiente y no preocuparse realmente por tal vez la sobrecarga de la ventana de contexto o la explosión de datos intermedios. Correcto. Y la privacidad y la composición, por supuesto, cuando tienes flujos de información personal o ejecución coordinada puede hacerlo más seguro porque ahora no te preocupas por pasar una tarjeta de crédito y un CVV al chat. Y quién sabe si el LLM lo está usando para su entrenamiento y alguien dice, oye, dame la tarjeta de Dan. Y me la da y como, correcto.

Así que solo estoy diciendo, pero todos estos límites están ahí en LLMs. Pero es una posibilidad de un ataque. Así que ahora hay un código que está en una superficie muy segura, que puede hacer múltiples orquestaciones, ejecutar, llamar a cualquier API que quiera y regresar con un resultado, lo que facilita la vida para LLMs así como para toda la experiencia del usuario.

La lección final y última, la lección número 10 es algo que está aparte de la tecnología. Todos nos enfocamos mucho en resolver un desafío tecnológico. Pero cuando estás lanzando algo a escala empresarial, no es solo tecnología, sino que también involucra algo de estrategia y planificación. Involucra ir al mercado e involucra comunicación, desafíos de cara al cliente, quejas y riesgos. Tenemos infraestructura y operaciones, operación, finanzas, seguridad, nómbralo, lo tenemos todo.

Así que en ese viaje de cinco días del que estaba hablando cuando lanzamos el servidor MCP remoto, tuvimos que involucrar a personas legales, tuvimos que realizar revisiones de seguridad. Tuvimos escritores de contenido, y uno de los escritores de contenido dijo que en mis 25 años de experiencia, nunca fui capaz de nunca hice una redacción de contenido tan rápida y obtener todo revisado y aprobado. Así que todos estábamos a un ritmo muy rápido, y requiere mucha coordinación y reunir a todos en una sala. Así que siempre es bueno, si estás planeando lanzar algo a escala empresarial, siempre es bueno construir una historia por adelantado y decir, sabes, tengo dependencia de estas personas. Probablemente debería darles un comienzo anticipado y decir, sabes, seguridad.

Estoy tratando de hacer esto. ¿Puedes comenzar a revisarlo? Sí. El PR no es mucho. Todavía tenemos una demostración rápida para mostrarte. Así que intenta involucrar a las personas desde el principio. Así que de alguna manera tienes el camino establecido y todos ellos saben qué es exactamente lo que se está haciendo. No es que construyas todo el asunto y luego pidas una revisión o pidas un consentimiento legal o pidas a los escritores técnicos que vayan y escriban un blog. Así que es una lección muy interesante. Aparte de la tecnología, toda la periferia es muy crucial cuando intentas construir y lanzar cosas.

Así que MCP no es solo un protocolo, sino un cambio de paradigma. Así que de alguna manera tenemos que tener una mentalidad diferente al intentar adoptar nuevas tecnologías y también estar felices de experimentar. Ver cuando las cosas fallan y las cosas salen mal y cómo abordamos esto. Siempre es bueno estar en la vanguardia, pero también ser cauteloso sobre lo que estás tratando de resolver. Asegúrate de que tus barandillas de seguridad y todo eso estén en acceso. Asegúrate de que los fundamentos y las bases sean correctos. Así que lo que sea que estemos haciendo hoy, la vanguardia de hoy es el legado de mañana.

Quizás dentro de 20 años, alguien se reirá de esta charla y dirá, oh, estaban haciendo MCPs en aquel entonces. Correcto. Así que lo que sea que estemos haciendo hoy es efímero, pero es divertido ser parte de este viaje. Siempre feliz de salir y explorar y experimentar. Y es agradable estar.

Y es un gran momento para estar vivo, es lo que siento. Así que la IA de hoy, la vanguardia de hoy es el legado de mañana. Y gracias por escuchar la charla de Hemant. Nos vemos en el Q&A.

Así que creo que solo tenemos tiempo, desafortunadamente, para una, tal vez dos preguntas si somos rápidos. Pero la primera va a ser, ¿cuáles son los mayores casos de uso que has visto para los MCPs financieros específicamente en lo que respecta a la banca de consumo? ¿Y qué productos están construyendo las personas usando estas herramientas o qué te gustaría ver que la gente construya? Sí, esa es una gran pregunta. ¿Quién la hizo? No estoy seguro si están en la sala o de forma remota, pero sí, esa es una gran pregunta. Correcto. Así que como estaba mencionando, siento que el mundo se está dirigiendo más hacia un camino agéntico. Correcto. Mira al extremo izquierdo del espectro con PayPal como un caso de uso donde tienes un botón amarillo en un sitio web de un comerciante y el usuario va y hace clic en ese botón amarillo. Inician sesión en PayPal. Hacen el baile habitual y luego compran cosas. Realizan el pago. Probablemente seleccionan su banco o tarjeta y realizan un pago. Eso es en el extremo izquierdo. Correcto.

Piensa en ello en el extremo derecho. Probablemente estoy pensando en comprar algo y algún agente es capaz de escuchar lo que estoy pensando. Y va y realiza un pago con mis credenciales o PayPal. Eso es en el extremo derecho donde las cosas son completamente autónomas. Pero siento que estamos en algún lugar en el medio aquí donde no estamos completamente a la derecha y la izquierda se está desvaneciendo. Y estamos llegando a una superficie donde pueden ser clots o GPTs o Gemini que están abriendo superficies donde la gente puede hacer comercio electrónico y también banca. Correcto.

Así que vería aplicaciones que harían la vida más fácil en términos de compras, pagos y tal vez datos financieros. Así que diría, oye, ¿cuánto gasté en compras el mes pasado o cuánto gasté en viajes o dame una idea de cómo puedo ahorrar dinero? Así que podría usar mis datos de banca abierta o enlazar mi cuenta bancaria a un agente. Puede ir y averiguar todas mis transacciones, darme análisis e ideas. Eso sería solo desde la perspectiva bancaria. Pero siento que el comercio en sí mismo se volverá más agéntico en naturaleza y tal vez hacia el extremo derecho donde todo es autónomo y probablemente no humano en el bucle, sino como humano en el bucle. Diría, oye, sabes, quiero comprar esto. Parece que te estás quedando sin.