Curso exprés · No. 27
Un modelo de lenguaje en bruto devuelve texto libre: precioso para que lo lea una persona, inútil para que tu código se apoye en él. Para construir software real sobre un modelo necesitas dos cosas: una salida en la que tu programa pueda confiar de verdad (structured output) y una forma segura de que el modelo vaya más allá del texto y actúe (tool use). Juntas convierten un chatbot en un componente fiable dentro de tu sistema.
20 conceptos · 22 diagramas · chuleta al final
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.
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.
- 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.
- 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
$40pero 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.
- 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.
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.
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.
- 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.
- 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
amountestá 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.
- 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.
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.
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.
- 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.
- 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
amountentre 0 y el total del pedido;categoryde la lista;order_idexiste 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.
- 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.
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.
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.
- 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.
- 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.
- 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.
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.
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.
- 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"sinosearch_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.
- 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 solasearch_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.
- 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.
- 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_ordersse 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.
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.
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.
- 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.
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.
- 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.
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.
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.
- 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.
- 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.
- ¿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?
- 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 Textprosa
Prosa para una persona; el código no puede construir sobre ella.
- Prose Parsingantipatrón
Parsear el texto del modelo con regex. Se rompe con la siguiente redacción nueva.
- Model as a Componentuna pieza fiable
Un modelo con dos interfaces predecibles: datos y acciones.
Structured output
- Structured OutputJSON según un schema
Tú defines la forma (campos y tipos); el modelo la rellena.
- Constrained Generationconstrained decoding
El modelo físicamente solo puede emitir lo que encaja con el schema.
- Model-to-Code Hand-offclasificación, extracción
El modelo entiende el caos; el código recibe campos limpios.
Validación
- Shape vs Contentbien formado vs correcto
JSON válido ≠ valores correctos.
- Boundary Validationcomprobar en el límite
Schema, rangos, conjuntos, existencia: antes de que el código actúe.
- Insecure Output Handlingsalida en bruto hacia el peligro
Amenaza: la salida del modelo directa a SQL, un shell o una base de datos.
Tool use
- Function Callingtool use
El modelo devuelve una llamada: nombre de función + argumentos.
- Model Decides, Code Executespedir vs ejecutar
El modelo solo pide; el código decide si ejecutarlo.
- Tool-Use Loopagent loop
Llamada → resultado al contexto → siguiente paso. Así un modelo se convierte en agente.
Diseño de herramientas
- Tool Descriptionnombre y descripción
Es el prompt desde el que el modelo elige herramientas: escríbelo con cuidado.
- Small Toolsetpocas herramientas afiladas
Pocas herramientas claramente distintas ganan a un menú gigante.
- Tool Poisoningetiquetas envenenadas
Amenaza: una instrucción dañina en la descripción o la salida de una herramienta.
- Least Privilegepermisos mínimos
Cada herramienta recibe los permisos mínimos que necesita.
MCP
- MCPModel Context Protocol
El estándar para enchufar herramientas a modelos: N + M en vez de N × M, las herramientas se vuelven componibles.
- Connector Securityasegurar conectores
Autenticación, alcance estrecho, red privada, inventario.
Usarlo bien
- Capability Ladderel peldaño más bajo que funcione
Prompt → salida → herramientas → bucle. Toma el peldaño más bajo que funcione.
- Boundary Disciplinedesconfianza 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.