# Del chatbot al componente Curso exprés sobre structured output y tool use: cómo convertir un modelo de lenguaje, de un chatbot que suelta prosa, en un componente fiable sobre el que tu código pueda construir. 20 conceptos — Structured Output, Constrained Generation, Boundary Validation, Function Calling, el Tool-Use Loop, Tool Poisoning, Least Privilege, MCP y más — cada uno con su nombre en inglés, un diagrama, una ficha y un ejemplo. Al final, una chuleta de una página con todos los conceptos. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/structured-output-express --- ## 1. El texto libre no es una API El primer paso para construir sobre un modelo es reconocer el desajuste: él habla en prosa, pero tu programa necesita datos y acciones. Salvar esa brecha es de lo que trata todo este curso. ### El mapa: 20 conceptos en siete grupos > Un mapa de metro: primero ves todas las líneas de golpe, luego viajas estación por estación. El curso recorre siete grupos. Primero, **el problema** (por qué la prosa no sirve para el código). Después, las dos mitades de la solución: **structured output** con **validación** (datos en los que puedes confiar) y **tool use** con buen **diseño de herramientas** (acciones bajo control). Luego **MCP**, la capa estándar para conectar herramientas, y por último cómo **usarlo todo bien**. _Diagram: Siete grupos de conceptos: los capítulos del curso los siguen._ ### Cómo leer cada concepto > Un pasaporte: los mismos campos para todos, así es fácil compararlos. Cada concepto de abajo tiene las mismas partes: su **nombre en inglés** (memorízalo: así lo llama la documentación), una imagen de la vida cotidiana, un **diagrama** y una **ficha** con campos: _problema_, _idea_, _ejemplo_, _coste_ o _trampa_, _cuándo usarlo_ y cómo se _relaciona_ con otros conceptos. Las amenazas llevan campos algo distintos: _qué es_, _cómo funciona_, _defensa_. ### Free Text — prosa para humanos > Un párrafo escrito a mano que describe un pedido frente a un formulario rellenado con casillas etiquetadas: una persona lee el párrafo con facilidad, pero solo el formulario puede archivarlo una máquina. Por defecto, un modelo de lenguaje devuelve **texto libre**: un párrafo, una explicación, prosa. Es perfecto para un lector humano e inútil para tu código, que necesita valores predecibles sobre los que actuar: un número aquí, una categoría allá, un sí o un no. Un programa no puede sacar de forma fiable "el cliente quiere un reembolso de 40 $" de una frase que el modelo redactó como le dio la gana. Prosa y datos son cosas distintas, y el código funciona con datos. _Diagram: Izquierda: prosa — clara para una persona, sin nada a lo que el código pueda agarrarse. Derecha: campos tipados — el código puede actuar._ #### Free Text (prosa) - **Problema:** Por defecto el modelo responde en prosa, pero el código necesita datos. - **Idea:** Distinguir dos tipos de salida: **para una persona** (prosa) y **para un programa** (datos). - **Ejemplo:** "Así que el cliente parece querer unos 40 $ de vuelta, el pedido llegó tarde…": una persona lo entiende, el código no. - **Cuándo encaja:** Chat, explicaciones, texto que solo lee una persona. - **Relaciones:** Intentar parsearlo con código es **Prose Parsing**; la solución real es **Structured Output**. ### Prose Parsing — un antipatrón > Intentar sacar el total de una carta que puede decir "40 $", "cuarenta dólares" o "un reembolso de 40 pavos": tus reglas funcionan hasta el día en que cambia la redacción, y entonces todo se cae. El arreglo ingenuo (que el modelo escriba texto y luego parsearlo con tu propio código: expresiones regulares, búsqueda de cadenas) es frágil. El modelo es **no determinista**: dirá lo mismo de diez maneras distintas, añadirá un preámbulo amable o envolverá la respuesta en markdown. Tu parser maneja los casos que viste y se rompe con el que no viste. Construir sobre el parseo de la prosa del modelo es construir sobre arena: funciona en la demo y falla en producción. _Diagram: Mismo significado, distinta redacción: el parser solo atrapa lo que estaba preparado para atrapar._ #### Prose Parsing (parsear a mano la salida del modelo) - **Problema:** Necesitas datos de la respuesta del modelo y devolvió texto libre. - **Idea:** Sacar los valores con tus propias reglas: expresiones regulares, búsqueda de cadenas. - **Ejemplo:** Una regex atrapa `$40` pero se le escapa "cuarenta dólares" y tropieza con `**$40**`. - **Coste:** Se rompe de forma silenciosa y repentina: el modelo cambia su redacción y tu código se cae. - **Cuándo usarlo:** Casi nunca; como mucho en scripts de un solo uso, no en producción. - **Relaciones:** Se cura con **Structured Output** y **Constrained Generation**. ### Model as a Component — una pieza fiable > Un motor solo le sirve a un coche cuando tiene soportes y conectores estándar: interfaces predecibles a las que el resto de la máquina se puede acoplar con confianza. Para construir software sobre un modelo hay que convertirlo de oráculo charlatán en **componente**: una pieza con interfaces predecibles, una salida en la que tu código pueda confiar y acciones que pueda ejecutar con seguridad. Esas son justo las dos mitades de este curso: **structured output** (datos, no prosa) y **tool use** (actuar, no solo hablar). Con eso, el modelo deja de ser una demo y pasa a ser una pieza fiable sobre la que puedes hacer ingeniería como con cualquier otra. _Diagram: Un chatbot se convierte en componente con dos interfaces: datos (structured output) y acciones (tool use)._ #### Model as a Component (el modelo como pieza fiable) - **Problema:** Un "oráculo" responde como quiere: no se puede construir un sistema así. - **Idea:** Dar al modelo dos interfaces predecibles: **datos** de salida y **acciones** a través de herramientas. - **Ejemplo:** El modelo lee un correo y devuelve `{intent: "refund"}`, no un párrafo sobre un reembolso. - **Coste:** Tienes que diseñar schemas, herramientas y comprobaciones: es trabajo de verdad. - **Cuándo usarlo:** Siempre que el código haga algo con la respuesta del modelo. - **Relaciones:** Las dos mitades son **Structured Output** y **Function Calling**. > **La pregunta de encuadre:** "¿Mi código tiene que actuar sobre esta salida? Y si es así, ¿me apoyo en parsear prosa libre o recibo datos estructurados en los que el programa pueda confiar de verdad?" > Un modelo habla en prosa; tu código necesita datos y acciones. Parsear texto libre es frágil: el objetivo es hacer del modelo un componente fiable, con una salida en la que confías y acciones que puede ejecutar. ## 2. Structured output La primera mitad de convertir el modelo en componente es lograr que devuelva datos con la forma que define tu código, siempre: no prosa que hay que adivinar, sino una estructura predecible. ### Structured Output — un schema, no una frase > Entregar a alguien un formulario con casillas etiquetadas en vez de una hoja en blanco: rellena exactamente los campos que necesitas, en el orden que necesitas, sin nada de más. **Structured output** significa pedirle al modelo que devuelva datos en un formato definido, normalmente **JSON** que cumpla un **schema** que tú especificas: estos campos, estos tipos, esta forma. En vez de "cuéntame sobre este pedido", dices "devuelve `{customer, amount, reason}`" y recibes datos que tu código puede usar directamente. Tú defines la forma; el modelo la rellena. Es el único movimiento que convierte la salida del modelo de prosa en algo en lo que un programa puede apoyarse. _Diagram: Prompt + schema → modelo → JSON con la forma correcta → tu código._ #### Structured Output (JSON según un schema) - **Problema:** El código no puede construir de forma fiable sobre la prosa del modelo. - **Idea:** Definir un **schema** (campos y tipos) y pedirle al modelo **JSON** exactamente con esa forma. - **Ejemplo:** Un correo de un cliente → `{"customer": "Ana", "amount": 40, "reason": "late"}`. - **Coste:** Hay que diseñar la forma de antemano; el schema es un contrato que irás evolucionando. - **Cuándo usarlo:** Siempre que la respuesta del modelo la lea código, no una persona. - **Relaciones:** Se refuerza con **Constrained Generation**; se comprueba con **Boundary Validation**; aplicado a acciones se convierte en **Function Calling**. ### Constrained Generation — solo salida válida > Una aguja de ferrocarril que físicamente solo puede enviar el tren por una de las vías definidas: no hay manera de que acabe en un sitio fuera del mapa. Los modelos modernos admiten **constrained generation**: se les puede _obligar_ a producir una salida que realmente cumpla tu schema (JSON válido, los campos correctos, los tipos adecuados) en vez de limitarse a pedírselo con educación. Esto cierra el hueco en el que el modelo devuelve "casi siempre" la forma correcta pero de vez en cuando se desvía. Con la salida limitada al schema, tu código puede contar con que la estructura estará ahí, y eso es lo que hace al modelo utilizable como bloque de construcción real. _Diagram: Pedirlo en el prompt da “casi siempre”. Restringir al schema da “siempre una forma válida”._ #### Constrained Generation (constrained decoding) - **Problema:** Incluso cuando se le pide JSON, el modelo a veces se desvía: texto extra, un campo que falta. - **Idea:** Mientras genera, el modelo solo puede elegir lo que encaja con el schema. - **Ejemplo:** `amount` está declarado como número: la cadena "cuarenta" físicamente no puede aparecer ahí. - **Trampa:** Garantiza la **forma**, no la **corrección** de los valores. - **Cuándo usarlo:** Siempre que tu proveedor lo admita y el código lea la salida. - **Relaciones:** Hace fiable a **Structured Output**; no sustituye a **Boundary Validation**. ### Model-to-Code Hand-off — el puente hacia tu código > Un intérprete que convierte los deseos hablados de un comensal en una comanda precisa y estandarizada que la cocina puede ejecutar: el mismo significado, ahora en una forma que el sistema puede usar. Structured output es el puente entre la capacidad lingüística del modelo y la necesidad de datos de tu software. Deja que el modelo haga lo que se le da genial, entender entradas humanas desordenadas, y entregue el resultado a tu código como valores limpios y tipados. La **clasificación**, la **extracción**, el **enrutado** y el rellenado de formularios se vuelven fiables cuando la salida es estructurada. El modelo lee el caos; el schema entrega el orden. Ese traspaso es donde viven la mayoría de las funcionalidades reales con LLM. _Diagram: Un correo desordenado → modelo → JSON con la intención → el código lo enruta a la cola correcta._ #### Model-to-Code Hand-off (clasificación, extracción, enrutado) - **Problema:** Los correos, chats y documentos entrantes son un caos que tu código no sabe leer. - **Idea:** El modelo entiende el caos y devuelve campos según un schema. - **Ejemplo:** "Paquete tarde, ¡quiero mi dinero de vuelta!!" → `{intent: "refund"}` → la cola de reembolsos. - **Coste:** Una clasificación errónea ahora viaja a tu sistema: hay que comprobarla. - **Cuándo usarlo:** Clasificación, extracción, enrutado, rellenado de formularios. - **Relaciones:** Construido sobre **Structured Output**; el resultado pasa por **Boundary Validation**. > **La pregunta de la estructura:** "¿He definido la forma exacta que quiero recibir (campos y tipos) y he limitado al modelo a ella, para que mi código reciba datos fiables en vez de prosa que parsear?" > Structured output significa que el modelo devuelve datos que cumplen un schema que tú defines, limitado a una forma válida: el puente que convierte su capacidad lingüística en valores tipados en los que tu código puede confiar. ## 3. Validar en el límite Structured output te da una forma predecible, pero la forma no es corrección. Antes de que tu código se fíe de lo que devolvió el modelo, tiene que comprobarlo: la misma disciplina que con cualquier entrada no confiable. ### Shape ≠ Content — bien formado no es correcto > Un formulario rellenado con pulcritud, todas las casillas completas, pero con una fecha imposible y un total que no cuadra. Ordenado no es lo mismo que correcto. Un schema garantiza la _forma_ (los campos y tipos correctos), pero no que los valores tengan sentido. El modelo puede devolver un JSON perfectamente formado con una cantidad negativa, una categoría que no existe o un importe que se **inventó**. Structured output resuelve "¿puede mi código leerlo?"; no resuelve "¿es correcto?". Trata una respuesta bien formada como un punto de partida para comprobar, no como garantía de que sea correcta. _Diagram: La comprobación del schema pasa, pero los valores son un disparate: −3 artículos, categoría “banana”, importe 9999._ #### Shape vs Content (bien formado vs correcto) - **Problema:** Un JSON válido se confunde fácilmente con una respuesta correcta. - **Idea:** Mantener separadas dos preguntas: **"¿se puede leer?"** (schema) y **"¿es correcto?"** (el significado de los valores). - **Ejemplo:** `{"quantity": -3, "category": "banana"}` pasa el schema, pero es basura. - **Trampa:** Los errores de contenido son más silenciosos que los de forma: ni un parser ni constrained generation los atrapan. - **Relaciones:** Se resuelve con **Boundary Validation**. ### Boundary Validation — comprobar antes de que nada actúe > Un control de aduana entre países: nada pasa al siguiente sistema hasta que se ha inspeccionado según las reglas y declarado seguro. Así que **validas** la salida estructurada del modelo antes de que tu código la use: aplicas el schema de forma estricta, compruebas que los valores estén en rangos y conjuntos permitidos y confirmas que lo referenciado exista de verdad. Esta comprobación corre en tu código, en el **límite** entre el modelo y el resto de tu sistema, porque el modelo es un componente no determinista en el que no puedes confiar del todo. La misma lección que en seguridad: la salida del modelo es **entrada no confiable** para la siguiente etapa hasta que la hayas verificado. _Diagram: Un validador en tu código: schema, rangos, existencia. Pasa: entra al sistema; falla: se rechaza o se reintenta._ #### Boundary Validation (validación en el límite) - **Problema:** El modelo puede devolver una respuesta bien formada pero equivocada. - **Idea:** Una comprobación entre el modelo y el sistema: **schema estricto**, rangos, conjuntos permitidos, referencias que existan. - **Ejemplo:** `amount` entre 0 y el total del pedido; `category` de la lista; `order_id` existe en la base de datos; si no, se rechaza o se vuelve a preguntar. - **Coste:** Código extra y, a veces, una segunda llamada al modelo. - **Cuándo usarlo:** Siempre, cuando algo actúa sobre la salida del modelo. - **Relaciones:** Atrapa lo que **Constrained Generation** deja pasar; es la base de **Boundary Discipline**. ### Insecure Output Handling — salida en bruto hacia algo peligroso > No viertes un caudal sin filtrar directamente en el agua potable: lo que hubiera río arriba acaba en todos los grifos, sin posibilidad de detectarlo. La regla se endurece cuando la salida fluye hacia algo con consecuencias. Nunca metas la salida en bruto del modelo directamente en una escritura en base de datos, un comando de shell, una consulta u otro sistema sin validarla y **escaparla** antes: así es como una alucinación o una instrucción inyectada se convierte en un error o una brecha reales. Este fallo tiene nombre: **insecure output handling**. Structured output más validación estricta es lo que te permite actuar con seguridad sobre lo que produjo el modelo. La estructura lo hace legible; la validación lo hace fiable. _Diagram: Arriba: salida en bruto directa a SQL o a un shell: un agujero. Abajo: primero validar y escapar._ #### Insecure Output Handling (fiarse de la salida en bruto del modelo) - **Qué es:** La salida en bruto del modelo va directa a una base de datos, un shell, una consulta o una API. - **Cómo funciona:** Una alucinación o una instrucción inyectada se convierte en un comando o registro real. - **Ejemplo:** El modelo "sugirió" un nombre de archivo y el código lo pegó en un comando de shell. - **Defensa:** Validar y escapar; usar consultas parametrizadas; no dejar nunca que la salida se ejecute como código. - **Relaciones:** Se cierra con **Boundary Validation**; primo de **Tool Poisoning**. > **La pregunta de la validación:** "Entre la salida del modelo y el código que actúa sobre ella, ¿qué comprueba que los valores sean realmente válidos? ¿O me fío de un JSON bien formado como si bien formado significara correcto?" > Un schema válido garantiza la forma, no la corrección. Valida la salida del modelo en el límite (rangos, conjuntos, existencia) antes de que ningún código actúe sobre ella, porque la salida del modelo no es confiable hasta que se comprueba. ## 4. Tool use Structured output deja que el modelo devuelva datos. La otra mitad de convertirlo en componente es dejar que haga cosas: ir más allá del texto para buscar, calcular, traer datos y actuar en el mundo real. Eso es tool use. ### Tool Use / Function Calling — funciones que el modelo puede pedir > Un asistente listo que no puede abrir el archivador por sí mismo, pero sabe decirte exactamente qué cajón y qué carpeta sacar, y usa lo que le traes. Con **tool use** (también llamado **function calling**) describes las funciones que el modelo tiene permiso de pedir: `search_orders`, `send_email`, `get_weather`. Cuando el modelo decide que necesita una, devuelve una **llamada a herramienta** estructurada: el nombre de la función y sus argumentos. Es structured output aplicado a acciones: en vez de datos, el modelo emite una petición de _hacer_ algo. Así es como un LLM llega más allá de su propio texto, hasta tus sistemas y el mundo. _Diagram: Tú describes las herramientas; el modelo elige una y devuelve una llamada: nombre + argumentos._ #### Function Calling (tool use) - **Problema:** El modelo solo sabe lo que hay en su contexto y no puede hacer nada por sí mismo. - **Idea:** Describir funciones; el modelo devuelve una **llamada a herramienta**: un nombre y argumentos según un schema. - **Ejemplo:** "¿Dónde está mi pedido 1042?" → `search_orders({id: 1042})`. - **Coste:** Cada herramienta es una capacidad nueva que se puede usar mal. - **Cuándo usarlo:** Cuando la tarea necesita datos recientes o necesita que se haga algo. - **Relaciones:** Es **Structured Output** para acciones; se ejecuta bajo **Model Decides, Code Executes**. ### Model Decides, Code Executes — el reparto del trabajo > Un capataz que señala y dice exactamente qué hay que hacer, pero es la cuadrilla, no el capataz, quien maneja las máquinas y mantiene el control de la obra. El reparto del trabajo es la clave: el modelo decide _qué_ hacer y con qué argumentos; **tu código decide si hacerlo de verdad y cómo.** Cuando el modelo devuelve una llamada a herramienta, tu código ejecuta la función (o no), obtiene el resultado y lo devuelve al contexto para que el modelo continúe. El modelo nunca toca tus sistemas directamente: pide, y tu código ejecuta. Ese límite es donde mantienes el control y la seguridad. _Diagram: El modelo solo pide. Decidir si se ejecuta, y ejecutarlo, ocurre en tu código, al otro lado del límite._ #### Model Decides, Code Executes (pedir vs ejecutar) - **Problema:** Si el modelo aprieta los botones él mismo, un solo error ya está dentro de tu sistema. - **Idea:** El modelo devuelve una **petición**; el código la comprueba y decide si ejecutarla. - **Ejemplo:** El modelo pide `refund_order(amount: 900)`: el código ve el límite de 100 $ y la rechaza. - **Coste:** El código tiene que poder comprobar cada llamada: permisos, límites, argumentos. - **Cuándo usarlo:** Siempre, cuando el modelo tiene herramientas. - **Relaciones:** Es **Boundary Validation** para acciones; la base del **Tool-Use Loop**. ### Tool-Use Loop — el resultado vuelve > Un investigador pide un documento, lee lo que le traen y lo usa para decidir la siguiente pregunta: un ir y venir, no un solo disparo. Tool use es un **bucle**: el modelo pide una herramienta, tu código la ejecuta y devuelve el resultado al contexto, y el modelo sigue razonando con esa información nueva, quizá llamando a otra herramienta. Este bucle es justo lo que convierte a un modelo en un **agente** (el curso de agentes profundiza). Las herramientas son las manos; el bucle es la persistencia. Por ahora, la idea clave es que tool use permite al modelo reunir lo que necesita y actuar paso a paso, en vez de responder a ciegas de memoria. _Diagram: Modelo → llamada → el código la ejecuta → resultado al contexto → modelo otra vez. Se repite hasta acabar el trabajo._ #### Tool-Use Loop (agent loop) - **Problema:** Una sola llamada a menudo no basta: averiguar, pensar y luego dar el siguiente paso. - **Idea:** Repetir: modelo → llamada a herramienta → el código la ejecuta → resultado al contexto → modelo. - **Ejemplo:** Encontrar el pedido → comprobar el estado de entrega → emitir el reembolso → responder al cliente. - **Coste:** Más pasos significan más llamadas, más dinero y más formas de desviarse. - **Cuándo usarlo:** Tareas de varios pasos donde el siguiente depende del resultado del anterior. - **Relaciones:** El peldaño más alto de la **Capability Ladder**; se apoya en **Model Decides, Code Executes**. > **La pregunta de las herramientas:** "¿Esta tarea necesita que el modelo haga o traiga algo de verdad? Y si es así, ¿lo he expuesto como una herramienta que puede pedir, con mi código al mando de si se ejecuta?" > Tool use deja que el modelo pida funciones: structured output para acciones. El modelo decide qué hacer; tu código decide si hacerlo y cómo, y devuelve el resultado. ## 5. Diseñar buenas herramientas El modelo elige y usa las herramientas según cómo las describes, así que el diseño de herramientas forma parte de lograr un comportamiento fiable. Unos pocos principios separan las herramientas que funcionan de las que confunden al modelo. ### Tool Description — nombres y descripciones guían la elección > Una caja de herramientas donde cada una está claramente etiquetada con su función: el operario coge la correcta al instante, en vez de adivinar entre una fila de mangos sin marcar. El modelo elige qué herramienta llamar casi por completo a partir de su **nombre** y su **descripción**. Así que no son documentación para humanos: son las instrucciones desde las que razona el modelo. Una descripción vaga o engañosa lleva a la herramienta equivocada, a los argumentos equivocados o a ignorar una herramienta cuando hacía falta. Escribe los nombres y descripciones de las herramientas con el mismo cuidado que un prompt, porque para el modelo eso es exactamente lo que son. _Diagram: “do_stuff / handles data”: el modelo adivina. Un nombre y una descripción claros: el modelo acierta la llamada._ #### Tool Description (nombre y descripción de la herramienta) - **Problema:** El modelo elige la herramienta equivocada o los argumentos equivocados. - **Idea:** El nombre y la descripción son un **prompt** para la elección: qué hace, cuándo llamarla, qué devuelve. - **Ejemplo:** No `do_stuff: "handles data"` sino `search_orders: "Find orders by customer email. Read-only."` - **Coste:** Tiempo dedicado a la redacción y a comprobar cómo la lee el modelo. - **Cuándo usarlo:** En cada herramienta, sin excepciones. - **Relaciones:** Trabaja junto con un **Small Toolset**; las descripciones forman parte de la superficie de ataque (**Tool Poisoning**). ### Small Toolset — pocas herramientas afiladas ganan a un menú gigante > Una cocina con pocas herramientas bien elegidas y claramente distintas trabaja más rápido que una con cincuenta aparatos solapados que el cocinero tiene que revisar cada vez. Darle al modelo demasiadas herramientas, o varias que se solapan, le hace más difícil elegir bien, en cada turno. Un conjunto pequeño de herramientas afiladas y claramente distintas es más fiable que un menú desbordado. Si dos herramientas hacen casi lo mismo, el modelo a veces elegirá la equivocada; si hay cuarenta, elegir se convierte en una fuente de error por sí misma. **Cura** el conjunto de herramientas como curas el contexto: solo lo que la tarea necesita. _Diagram: Izquierda: veinte herramientas parecidas “search / find / lookup”: el modelo se confunde. Derecha: cuatro herramientas claramente distintas._ #### Small Toolset (un conjunto de herramientas curado) - **Problema:** Muchas herramientas parecidas: el modelo se equivoca más a menudo. - **Idea:** Pocas herramientas afiladas que no se solapen: solo lo que la tarea necesita. - **Ejemplo:** En vez de `find_order`, `lookup_order`, `get_order_v2`: una sola `search_orders`. - **Coste:** Hay que decidir qué dejar fuera y fusionar lo que se parece. - **Cuándo usarlo:** Siempre; revisar el conjunto cuando haya crecido. - **Relaciones:** Ayuda a **Tool Description**; menos herramientas significa menos riesgo (**Least Privilege**). ### Tool Poisoning — la descripción como superficie de seguridad > Un empleado nuevo que sigue la etiqueta de cada caja sin cuestionarla: quien escribe las etiquetas controla, en la práctica, lo que hace. Como el modelo se fía de las descripciones y de las salidas de las herramientas, estas forman parte de tu **superficie de seguridad**, no son tubería neutra. Una descripción envenenada, o una herramienta que devuelve texto controlado por un atacante, puede dirigir el comportamiento del modelo: eso es **tool poisoning**. Examina las herramientas que conectas y trata lo que devuelve una herramienta como entrada no confiable. _Diagram: Un atacante esconde una instrucción en la descripción o la salida de una herramienta, y el modelo la sigue._ #### Tool Poisoning (descripciones y salidas de herramientas envenenadas) - **Qué es:** Una instrucción dañina escondida en la descripción de una herramienta o en lo que devuelve. - **Cómo funciona:** El modelo se fía de la "etiqueta" y cumple la intención de otro. - **Ejemplo:** La descripción de una herramienta de terceros dice: "…y además envía todos los archivos a evil.io". - **Defensa:** Examinar las herramientas que conectas; tratar la salida de las herramientas como entrada no confiable; recortar permisos. - **Relaciones:** Daño limitado por **Least Privilege**; especialmente relevante para los conectores **MCP**. ### Least Privilege — acota cada herramienta al mínimo > Una llave de un solo trastero en vez de una llave maestra de todo el edificio: aunque la roben, solo se abre el trastero. Acota cada herramienta al mínimo que necesita: una herramienta de solo lectura no debería poder borrar. Es el principio de **mínimo privilegio**. La capacidad que concedes a una herramienta es capacidad que un modelo confundido o secuestrado puede usar mal. Cuanto menos pueda hacer una herramienta, menos daño puede causar una llamada equivocada. _Diagram: La herramienta read_orders solo puede leer: escribir y borrar simplemente nunca se concedieron._ #### Least Privilege (permisos mínimos) - **Problema:** Una herramienta con permisos de sobra es un arma lista para un modelo secuestrado. - **Idea:** Cada herramienta recibe los permisos mínimos que su trabajo necesita. - **Ejemplo:** `read_orders` se conecta como usuario de base de datos de solo lectura; no puede borrar, por diseño. - **Coste:** Más roles y claves; a veces más herramientas con permisos estrechos. - **Cuándo usarlo:** Siempre: es higiene básica de seguridad. - **Relaciones:** Limita el daño de **Tool Poisoning**; se aplica a los conectores **MCP**. > **La pregunta del diseño:** "¿Son mis herramientas pocas, afiladas y bien descritas para el modelo, y están acotadas al mínimo privilegio, de modo que una llamada equivocada o secuestrada no pueda hacer mucho daño?" > El modelo elige herramientas por sus nombres y descripciones, así que escríbelos como prompts. Mantén pocas herramientas y afiladas, acota cada una al mínimo privilegio y trata las descripciones y salidas como superficie de seguridad. ## 6. MCP y conectores A medida que las herramientas se multiplican, conectar cada modelo con cada sistema a mano no escala. Ha surgido un estándar para cómo los modelos llegan a herramientas y datos, y con él, una capa nueva que entender y asegurar. ### MCP — Model Context Protocol > Antes de los enchufes y tomas estándar, cada aparato necesitaba su propio cableado a medida; un estándar universal significó que cualquier dispositivo podía conectarse a cualquier toma sin trabajo especial. El **Model Context Protocol (MCP)** es un estándar emergente de cómo los modelos se conectan a herramientas y fuentes de datos. En vez de cablear cada modelo con cada sistema con código a medida (N × M integraciones), MCP define una forma común de exponer herramientas, de modo que cualquier modelo compatible pueda usar cualquier herramienta compatible (N + M). Es la toma universal de la era de los agentes: una **capa de conectores** que deja enchufar herramientas y modelos sin integraciones ad hoc cada vez. _Diagram: Sin estándar: N × M cables. Con MCP cada lado se conecta una vez: N + M._ #### MCP (Model Context Protocol) - **Problema:** Cada modelo hay que cablearlo con cada sistema con código a medida. - **Idea:** Un estándar: un **servidor MCP** expone herramientas y datos, un **cliente MCP** (un agente, una app) los usa. - **Ejemplo:** Un servidor MCP de GitHub, usado por igual por un agente, un asistente de IDE y una app de chat. - **Coste:** Una capa nueva que hay que asegurar (ver **Connector Security**). - **Cuándo usarlo:** Cuando hay muchas herramientas y modelos, o quieres engancharte a un ecosistema existente. - **Relaciones:** La forma estándar de exponer **Function Calling**; hace las herramientas **componibles**. ### Composability — la fontanería de los agentes, estandarizada > Una red eléctrica: estandarizada para que un aparato nuevo se enchufe y funcione, y una nueva fuente de energía alimente la misma red; el estándar es lo que hace que toda la red componga. MCP importa porque hace que herramientas y datos sean **componibles**: una herramienta construida una vez puede usarse con muchos modelos y agentes, y un agente nuevo puede usar de inmediato todo el ecosistema de herramientas existentes. Esto explica en buena parte por qué los agentes se volvieron potentes tan rápido: la fontanería se estandarizó y las capacidades encajan entre sí. Cuando hoy das a un agente acceso a tus sistemas, cada vez más a menudo es MCP la capa que lo hace. _Diagram: Clientes arriba, servidores abajo, MCP en medio: una herramienta construida una vez la pueden usar todos._ ### Connector Security — el conector es una puerta > Fontanería nueva tendida deprisa por toda la casa, y una encuesta descubre que una buena parte de las válvulas nunca llevó cerradura. Esta capa nueva es también un lugar nuevo por donde sufrir una brecha. Los conectores MCP exponen acciones y datos reales, y las prisas por adoptarlos han dejado muchos desplegados con seguridad débil o ausente: una gran parte de los servidores MCP remotos se han lanzado **sin autenticación** alguna. Así que trata un conector como la puerta que es: **autentícalo**, **acota** lo que expone, mantenlo **fuera de internet público** salvo que deba estar ahí y haz **inventario** de lo que has conectado. Una fontanería potente exige las cerraduras básicas. _Diagram: Cuatro cerrojos en un servidor MCP: autenticación, alcance estrecho, red privada, inventario._ #### Connector Security (asegurar conectores MCP) - **Problema:** Los conectores MCP exponen acciones y datos reales, y muchos se despliegan sin autenticación. - **Idea:** Cuatro cerrojos: **autenticar**, **acotar**, mantenerlo **privado**, llevar un **inventario**. - **Ejemplo:** Un servidor MCP de base de datos: solo con token, solo lectura, solo red interna, listado en el registro. - **Coste:** Configurar accesos y la disciplina de mantener la lista al día. - **Cuándo usarlo:** Con cada conector que despliegues o enchufes. - **Relaciones:** Aplica **Least Privilege** a **MCP**; protege contra **Tool Poisoning**. > **La pregunta del conector:** "Si expongo herramientas y datos a través de MCP, ¿cada conector está autenticado, acotado y contabilizado? ¿O he abierto una puerta poderosa y la he dejado sin llave?" > MCP estandariza cómo los modelos llegan a herramientas y datos y hace el ecosistema componible. Esa misma capa de conectores es una superficie de ataque real: autentícala, acótala y haz inventario. ## 7. Usarlo bien Structured output y tool use son las herramientas que hacen del modelo un componente, pero usarlas bien sigue significando subir por la escalera: usar la pieza menos potente que resuelva tu problema. ### Capability Ladder — primero structured output, herramientas cuando deba actuar > No le das las llaves del coche a alguien cuando solo necesitaba una respuesta: das justo la capacidad que la tarea requiere, ni más. Hay una **capability ladder**, una escalera de capacidades. Un prompt simple responde; **structured output** hace esa respuesta utilizable por el código; las **herramientas** dejan al modelo traer datos y actuar; un **bucle de agente** completo le permite perseguir un objetivo de varios pasos. Cada peldaño añade potencia y nuevas formas de fallar. Sube solo hasta donde necesite la tarea: si solo necesitas datos limpios, structured output basta; no des herramientas al modelo, y desde luego tampoco un bucle, cuando una respuesta restringida lo resuelve. La mayoría de las funcionalidades nunca necesitan el peldaño más alto. _Diagram: Prompt → structured output → herramientas → bucle de agente. Más arriba es más potente y más arriesgado._ #### Capability Ladder (el peldaño menos potente que funcione) - **Problema:** Tienta recurrir a un agente incluso cuando bastaría con JSON. - **Idea:** Usar el peldaño menos potente que resuelva la tarea. - **Ejemplo:** Clasificar correos: structured output; encontrar un pedido: una herramienta; un reembolso de varios pasos: un bucle. - **Coste:** Cada peldaño que subes significa más llamadas, más gasto y más formas de fallar. - **Cuándo usarlo:** Al elegir el enfoque de cada funcionalidad nueva. - **Relaciones:** Los peldaños: **Structured Output** → **Function Calling** → **Tool-Use Loop**. ### Boundary Discipline — validar todo lo que vuelve a cruzar > Un mostrador de devoluciones que inspecciona cada artículo que regresa antes de que vuelva al estante: nada reentra en el sistema sin revisar, por muy fiable que pareciera el cliente. El hábito que unifica las dos mitades es la **desconfianza en el límite**: **valida la salida estructurada del modelo** antes de que tu código la use y **mantén el control en tu código** de si ejecutar o no una herramienta que el modelo pidió. El modelo es un componente brillante y no determinista, y tratas todo lo que pasa de él a tu sistema como una entrada que verificar. Esa disciplina de límites es lo que te permite construir con fiabilidad sobre algo que es falible por naturaleza. #### Boundary Discipline (desconfianza en el límite) - **Problema:** El modelo comete errores, y se filtran a tu sistema. - **Idea:** Todo lo que sale del modelo es **entrada no confiable**: los datos se validan, las acciones las aprueba el código. - **Ejemplo:** El JSON pasó el validador; la llamada a herramienta pasó las comprobaciones de permisos y límites; solo entonces ocurre algo. - **Coste:** Comprobaciones en cada cruce: un poco de código y de tiempo. - **Cuándo usarlo:** Siempre: es el hilo común de todo el curso. - **Relaciones:** Une **Boundary Validation** (datos) y **Model Decides, Code Executes** (acciones). ### Cómo encaja todo > El mapa de metro entero de golpe: se ve dónde se cruzan las líneas y dónde se hace transbordo. **Structured output** sustituye al texto libre; **constrained generation** lo mantiene en forma y la **boundary validation** comprueba su significado. El mismo structured output aplicado a acciones es **function calling**; **MCP** da una forma estándar de exponer herramientas; tu código ejecuta las llamadas y de ahí crece el **tool-use loop**. Un solo hábito sostiene las dos mitades: la **boundary discipline**. _Diagram: Los vínculos principales entre los conceptos del curso: datos arriba, acciones abajo, el límite en el medio._ #### Antes de construir sobre un modelo - **¿Mi código necesita datos?** ¿Recibo structured output según un schema, en vez de parsear prosa? - **¿Está validada la salida?** ¿Se comprueban los valores, no solo la forma, antes de que nada actúe sobre ella? - **¿Necesita actuar?** ¿Y lo he expuesto como herramienta, con mi código al mando de ejecutarla? - **¿Son las herramientas pocas, afiladas y bien descritas**, y acotadas al mínimo privilegio? - **Si uso MCP**, ¿está cada conector autenticado, acotado e inventariado? - **¿Estoy en el peldaño más bajo** que funciona: salida, herramientas o un bucle completo solo si hace falta? #### Señales de que construyes bien con ello - Recibes **structured output según un schema** en vez de parsear la prosa del modelo. - **Validas** la salida en el límite antes de que ningún código actúe sobre ella. - El modelo **pide** herramientas y **tu código mantiene el control** de ejecutarlas. - Tus herramientas son **pocas, afiladas, bien descritas** y de **mínimo privilegio**. - Subes solo hasta el **peldaño que la tarea necesita** y tratas los conectores MCP como una puerta **cerrada con llave**. ## Chuleta: los 20 conceptos ### El problema - **Free Text** (prosa): Prosa para una persona; el código no puede construir sobre ella. - **Prose Parsing** (antipatrón): Parsear el texto del modelo con regex. Se rompe con la siguiente redacción nueva. - **Model as a Component** (una pieza fiable): Un modelo con dos interfaces predecibles: datos y acciones. ### Structured output - **Structured Output** (JSON según un schema): Tú defines la forma (campos y tipos); el modelo la rellena. - **Constrained Generation** (constrained decoding): El modelo físicamente solo puede emitir lo que encaja con el schema. - **Model-to-Code Hand-off** (clasificación, extracción): El modelo entiende el caos; el código recibe campos limpios. ### Validación - **Shape vs Content** (bien formado vs correcto): JSON válido ≠ valores correctos. - **Boundary Validation** (comprobar en el límite): Schema, rangos, conjuntos, existencia: antes de que el código actúe. - **Insecure Output Handling** (salida en bruto hacia el peligro): Amenaza: la salida del modelo directa a SQL, un shell o una base de datos. ### Tool use - **Function Calling** (tool use): El modelo devuelve una llamada: nombre de función + argumentos. - **Model Decides, Code Executes** (pedir vs ejecutar): El modelo solo pide; el código decide si ejecutarlo. - **Tool-Use Loop** (agent loop): Llamada → resultado al contexto → siguiente paso. Así un modelo se convierte en agente. ### Diseño de herramientas - **Tool Description** (nombre y descripción): Es el prompt desde el que el modelo elige herramientas: escríbelo con cuidado. - **Small Toolset** (pocas herramientas afiladas): Pocas herramientas claramente distintas ganan a un menú gigante. - **Tool Poisoning** (etiquetas envenenadas): Amenaza: una instrucción dañina en la descripción o la salida de una herramienta. - **Least Privilege** (permisos mínimos): Cada herramienta recibe los permisos mínimos que necesita. ### MCP - **MCP** (Model Context Protocol): El estándar para enchufar herramientas a modelos: N + M en vez de N × M, las herramientas se vuelven componibles. - **Connector Security** (asegurar conectores): Autenticación, alcance estrecho, red privada, inventario. ### Usarlo bien - **Capability Ladder** (el peldaño más bajo que funcione): Prompt → salida → herramientas → bucle. Toma el peldaño más bajo que funcione. - **Boundary Discipline** (desconfianza en el límite): Todo lo que viene del modelo es no confiable: valida los datos, deja que el código apruebe las acciones. > Para construir sobre un modelo, hazlo un componente: structured output en el que tu código pueda confiar, validado en el límite, y herramientas que él pide pero que tu código controla: el peldaño menos potente que resuelva el trabajo. Fin del curso exprés · 7 capítulos · 20 conceptos Ahora toca practicar: toma una funcionalidad donde estés parseando la prosa del modelo y pásala a structured output según un schema; luego valida el resultado antes de usarlo. Si la tarea necesita que el modelo traiga o haga algo, expón una herramienta pequeña y bien descrita y deja a tu código al mando de ejecutarla. El cambio hace clic en el momento en que el modelo deja de ser un chatbot con el que forcejeas y pasa a ser una pieza en la que puedes confiar. Pero quédate con una idea por encima de todas: un modelo se vuelve útil para el software cuando devuelve datos en los que puedes confiar y emprende acciones que controlas. Structured output y tool use son cómo un chatbot se convierte en componente.