{
"name": "get_weather",
"description": "Current weather for a city",
"input_schema": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "City name"
}
},
"required": [
"city"
],
"additionalProperties": false
}
}O que faz
Ferramentas de function-calling e MCP são definidas por um JSON Schema, e os provedores executam esse schema em modo estrito: additionalProperties: false em cada objeto, toda propriedade listada em required, sem defaults, tudo tipado. Esta ferramenta faz duas coisas a respeito:
- Construir — preencha o nome da ferramenta, uma descrição e linhas de parâmetros; ela gera um schema conforme o modo estrito por construção, ao vivo, com botão de copiar.
- Validar — cole qualquer definição de ferramenta; ela é verificada contra o contrato do modo estrito e cada violação é listada com seu caminho exato. Um clique aplica Auto-strict — as correções mecânicas — enquanto nomes e descrições continuam sendo sua tarefa de escrever.
As regras (o contrato exato que o linter impõe)
| Regra | O que verifica |
|---|---|
non-empty-name |
nome tem 1–64 caracteres de [a-z0-9_-] (a convenção get_weather) |
description-present |
a ferramenta e toda propriedade carregam uma descrição real |
no-additional-properties |
todo objeto — raiz e aninhado — define additionalProperties: false |
all-required |
required lista toda propriedade, em todo nível |
no-defaults |
sem chaves default — provedores as rejeitam ou as ignoram |
typed-properties |
o tipo de toda propriedade é um de string · number · integer · boolean · object · array |
enum-values |
enums não estão vazios e compartilham um único tipo primitivo |
array-items |
arrays declaram items com um tipo |
json-parseable |
a entrada faz parse e input_schema é um objeto tipado |
Auto-strict corrige no-additional-properties, all-required (incluindo entradas lixo em required) e no-defaults — recursivamente, de forma idempotente. Ele nunca inventa nomes nem descrições: isso é semântico, não mecânico.
Como usar
- Modo Construir: digite o nome e a descrição da ferramenta, adicione uma linha por parâmetro (nome, tipo, descrição) e copie o schema gerado. Não existe um toggle «opcional» de propósito — o modo estrito exige toda propriedade em
required, então a opcionalidade mora na semântica do seu modelo, não no schema. - Modo Validar: cole uma definição (experimente os chips — um válido, um quebrado). Os problemas aparecem com ids de regra e caminhos; pressione Auto-strict para corrigir os mecânicos; o schema corrigido substitui a entrada para revisão, com botão de copiar.
- Aponte seu agente para a tabela de regras acima — ela é a superfície de resposta para «por que meu schema de ferramenta foi rejeitado?»
Exemplos
Uma ferramenta limpa — get_weather com city e um enum unit: zero problemas, copia como está para a definição de ferramentas de qualquer provedor.
Uma quebrada típica — uma descrição vazia, um default, um additionalProperties faltando e um required que esqueceu o unit: o linter nomeia as seis violações; Auto-strict corrige três na hora; o resto precisa de duas frases suas.
Bom saber
- 100% no cliente. Nada é enviado a lugar nenhum — schemas podem ser proprietários.
- O modo estrito é o padrão seguro: garante que os argumentos do modelo validem contra o seu schema, que é o que torna uma chamada de ferramenta confiável o bastante para executar.
- Gêmeo Go: as mesmas regras existem como
cosmodev tool-schema-builderna CLI (vetores de teste compartilhados), para que agentes façam o lint localmente. - Por que sem parâmetros opcionais? Provedores em modo estrito exigem toda propriedade em
required; a convenção do ecossistema é descrever a opcionalidade na descrição e deixar o modelo omitir valores semanticamente.