Por qué JSON Schema se ha convertido en el idioma nativo de los LLMs

En el ecosistema actual de herramientas para LLMs —MCP servers, function calling, structured outputs, agentes con subagentes— hay un elemento que aparece una y otra vez en configuraciones, especificaciones y contratos de API: JSON Schema. No es casualidad ni moda. Un artículo publicado el pasado 2 de mayo por el equipo de Sourcemeta lo articula con precisión: cuando se trata de describir datos a una IA, JSON Schema es el único lenguaje que los modelos realmente entienden.

El argumento central es técnico pero tiene consecuencias prácticas inmediatas. Los LLMs han sido entrenados con cantidades masivas de documentación, código y especificaciones que usan JSON Schema como gramática común. Otros formatos de esquema —YAML Schema, Zod, TypeScript interfaces, RDFS— existen y tienen sus comunidades, pero ninguno tiene la misma densidad de presencia en los datos de entrenamiento. El resultado es que los modelos generan, validan e interpretan JSON Schema de forma más fiable que cualquier alternativa.

Qué dice realmente el artículo

Sourcemeta mantiene varias herramientas del ecosistema JSON Schema y su perspectiva no es neutral, pero los datos que aportan son difíciles de rebatir. El post documenta cómo las principales APIs de modelos —incluyendo la de Anthropic— usan JSON Schema como mecanismo nativo para definir el formato de respuestas estructuradas y para describir las herramientas disponibles en el function calling. No es una capa de compatibilidad añadida a posteriori: es la interfaz de diseño.

En el caso concreto de Claude, esto se traduce en que cuando defines un MCP server o configuras un skill en Claude Code, las definiciones de parámetros de herramientas viajan como JSON Schema. Lo mismo ocurre con los schemas de validación en hooks de tipo `PreToolUse` o `PostToolUse`, donde puedes restringir qué formas de datos acepta o emite un subagente antes de que la acción se ejecute. El modelo no infiere la estructura: la lee de un schema explícito, y cuanto más canónico es ese schema, mejor funciona el conjunto.

Por qué importa más allá de la teoría

Hay tres perfiles para los que esta realidad tiene implicaciones directas:

Desarrolladores que construyen MCP servers. Si estás exponiendo herramientas a Claude vía MCP, la calidad de tus definiciones de schema determina directamente la fiabilidad con la que el modelo las invoca. Un schema ambiguo o incompleto produce llamadas erróneas; un schema bien construido, con descripciones en los campos y restricciones explícitas, reduce los errores de invocación de forma medible. No es magia: es que el modelo tiene más información con la que razonar.

Equipos que trabajan con structured outputs. Extraer datos estructurados de texto no estructurado —facturas, contratos, logs— es uno de los casos de uso más comunes con Claude Opus 4.7 o Claude Sonnet 4.6. Definir el schema de salida con precisión, usando `$defs` para tipos reutilizables y anotaciones descriptivas, mejora la tasa de éxito sin necesitar prompt engineering adicional. El schema es, en sí mismo, parte del prompt.

Quienes diseñan plugins o skills distribuibles. Con la madurez del marketplace de Claude Code, los paquetes que se distribuyen como plugins o skills necesitan contratos de datos estables. JSON Schema proporciona exactamente eso: versionado, validación, documentación embebida. Un skill que expone su interfaz como JSON Schema válido es interoperable por defecto.

El elefante en la sala: la complejidad del propio estándar

JSON Schema no es un estándar simple. Las diferencias entre Draft 4, Draft 7, 2019-09 y 2020-12 han causado incompatibilidades reales en producción, y no todos los validadores implementan el mismo subconjunto. El artículo de Sourcemeta no profundiza en este problema —comprensiblemente, dado su interés en promover el ecosistema—, pero es un factor que cualquier equipo debe considerar antes de asumir que «JSON Schema» es una respuesta monolítica.

En la práctica, con Claude y con el ecosistema MCP, conviene verificar qué versión del draft espera cada componente. Claude Code y los MCP servers actuales tienden a asumir un subconjunto compatible con Draft 7, pero la documentación oficial de Anthropic es la referencia que hay que consultar antes de asumir compatibilidad total con las features más recientes del estándar.

---

El artículo de Sourcemeta no descubre nada que los desarrolladores avanzados del ecosistema no supieran ya, pero lo expresa con una claridad que merece difusión. Si construyes con Claude y todavía tratas los schemas como burocracia opcional, este es un buen momento para reconsiderarlo: en herramientas basadas en LLMs, el schema no documenta la interfaz, es la interfaz.