{
"name": "get_weather",
"description": "Current weather for a city",
"input_schema": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "City name"
}
},
"required": [
"city"
],
"additionalProperties": false
}
}Qué hace
Las herramientas de function-calling y MCP se definen mediante un JSON Schema, y los proveedores ejecutan ese esquema en modo estricto: additionalProperties: false en cada objeto, cada propiedad listada en required, sin defaults, todo tipado. Esta herramienta hace dos cosas al respecto:
- Construir — rellena un nombre de herramienta, una descripción y filas de parámetros; genera un esquema limpio para el modo estricto por construcción, en vivo, con botón de copia.
- Lint — pega cualquier definición de herramienta; la comprueba contra el contrato del modo estricto y lista cada infracción con su ruta exacta. Un clic aplica Auto-strict — las correcciones mecánicas — mientras que los nombres y las descripciones siguen siendo cosa tuya de escribir.
Las reglas (el contrato exacto que aplica el linter)
| Regla | Qué comprueba |
|---|---|
non-empty-name |
el nombre tiene 1–64 caracteres de [a-z0-9_-] (la convención get_weather) |
description-present |
la herramienta y cada propiedad llevan una descripción real |
no-additional-properties |
cada objeto — raíz y anidados — pone additionalProperties: false |
all-required |
required lista todas las propiedades, en todos los niveles |
no-defaults |
sin claves default — los proveedores las rechazan o las ignoran |
typed-properties |
el tipo de cada propiedad es uno de string · number · integer · boolean · object · array |
enum-values |
los enums no están vacíos y comparten un solo tipo primitivo |
array-items |
los arrays declaran items con un tipo |
json-parseable |
la entrada parsea y input_schema es un objeto tipado |
Auto-strict corrige no-additional-properties, all-required (incluidas las entradas basura en required) y no-defaults — de forma recursiva e idempotente. Nunca inventa nombres ni descripciones: eso es semántico, no mecánico.
Cómo usarlo
- Modo Construir: escribe el nombre y la descripción de la herramienta, añade una fila por parámetro (nombre, tipo, descripción) y copia el esquema generado. No hay interruptor de «opcional» a propósito — el modo estricto exige toda propiedad en
required, así que la opcionalidad vive en la semántica de tu modelo, no en el esquema. - Modo Lint: pega una definición (prueba los chips — una válida, una rota). Los problemas aparecen con ids de regla y rutas; pulsa Auto-strict para corregir los mecánicos; el esquema corregido sustituye a la entrada para revisión, con botón de copia.
- Apunta a tu agente a la tabla de reglas de arriba — es la superficie de respuesta para «¿por qué rechazan mi esquema de herramienta?»
Ejemplos
Una herramienta limpia — get_weather con city y un enum unit: cero problemas, se copia tal cual en la definición de herramientas de cualquier proveedor.
Una rota típica — una descripción vacía, un default, un additionalProperties que falta y un required que olvidó unit: el linter nombra las seis infracciones; Auto-strict corrige tres al instante; el resto necesita dos frases tuyas.
Bueno saber
- 100 % en el cliente. Nada se envía a ninguna parte — los esquemas pueden ser propietarios.
- El modo estricto es la opción segura por defecto: garantiza que los argumentos del modelo validen contra tu esquema, que es lo que hace que una llamada a herramienta merezca ejecutarse.
- Gemelo Go: las mismas reglas están disponibles como
cosmodev tool-schema-builderen la CLI (vectores de test compartidos), para que los agentes hagan lint localmente. - ¿Por qué no hay parámetros opcionales? Los proveedores en modo estricto exigen toda propiedad en
required; la convención del ecosistema es describir la opcionalidad en la descripción y dejar que el modelo omita valores semánticamente.