Voltar as noticias
A saída do seu agente é inválida e você descobrirá da maneira cara
Agentic SEOAltaEN

A saída do seu agente é inválida e você descobrirá da maneira cara

Dev.to - MCP·23 de julho de 2026

Eu construo pipelines de agentes como um projeto paralelo. O modo de falha que continuava me custando dinheiro real nunca foi o dramático — sempre foi algo silencioso e a montante: o agente gera JSON, uma resposta de API ou uma consulta SQL; algo sutilmente inválido escapa (um campo obrigatório ausente, uma string onde deveria haver um número, um erro de SELEKT três joins abaixo); e eu pago por isso mais tarde. Um passo de pipeline quebrado, um registro corrompido, ou meu favorito pessoal — um loop de retry de LLM que consome tokens re-gerando tudo porque um campo estava errado.
Por que "basta pedir ao modelo para verificar" não funciona
A correção óbvia é a autoavaliação: alimentar a saída de volta e pedir ao modelo para verificar. Dois problemas.
Primeiro, é pouco confiável da maneira errada. O modelo que cometeu o erro está extraindo da mesma distribuição quando revisa — ele perde seus próprios erros a uma taxa que é difícil de orçar. Validação é o único lugar onde "geralmente certo" não é uma propriedade que você deseja.
Segundo, é caro. Uma chamada completa ao modelo para verificar um objeto JSON contra um esquema é como contratar um advogado para verificar se um número é par. A conformidade com o esquema é um problema resolvido e determinístico — deveria custar milissegundos e frações de centavo, e dar a mesma resposta toda vez.
O que eu construí
machinegrade validate é um pequeno serviço que verifica artefatos gerados por agentes contra um contrato antes de você agir sobre eles:

json_schema — artefato vs. um JSON Schema, todos os erros coletados
openapi_response — corpo da resposta vs. o esquema de resposta para um determinado caminho + método + status em uma especificação OpenAPI
sql — verificação de sintaxe por dialeto

A decisão de design que mais me importa: um veredicto não é um erro. Um artefato inválido retorna HTTP 200 com um veredicto estruturado — porque para um agente, "inválido" é um resultado normal e esperado que ele precisa agir, não uma exceção:

{
  "valid": false,
  "errors": [
    {
      "path": "/age",
      "code": "type",
      "message": "deve ser um número",
      "fix_hint": "Altere o valor em /age para um número (recebido string)."
    }
  ],
  "latency_ms": 2
}

Todo erro tem um caminho, um código estável e um fix_hint escrito para ser consumido pelo agente na nova tentativa — assim, a nova tentativa é direcionada ("corrigir /age") em vez de "regenerar tudo e esperar".
Erros HTTP reais (chave ruim, limite excedido, tipo não suportado) também são JSON tipados — {código, mensagem, dica, docs_url} — nunca strings livres. Se você já escreveu se "limite de taxa" em error_message, você sabe por quê.
Tente em 30 segundos

# Obtenha uma chave (plano gratuito: 500 chamadas/mês)
curl -s -X POST https://api.machinegrade.dev/keys \
  -H 'content-type: application/json' \
  -d '{"email": "you@example.com"}'

# Validar
curl -s -X POST https://api.machinegrade.dev/v1/validate \
  -H 'content-type: application/json' -H 'X-Api-Key: sk_...' \
  -d '{"type": "json_schema",
       "artifact": {"name": "Ada", "age": "thirty"},
       "contract": {"schema": {"type": "object", "required": ["name", "age"],
         "properties": {"name": {"type": "string"}, "age": {"type": "number"}}}}'

Para MCP, há duas maneiras de entrar: um endpoint remoto que você pode apontar um cliente diretamente — https://api.machinegrade.dev/mcp (HTTP transmitível; tools/list funciona anonimamente, tools/call precisa da chave) — ou um adaptador stdio no npm (@machinegrade/validate). Com Claude Code:

claude mcp add --transport http validate https://api.machinegrade.dev/mcp \
  --header "X-Api-Key: sk_..."

Está no registro oficial do MCP como io.github.machinegrade/validate, e no Smithery.
A parte onde sou honesto sobre o que isso é
Este é um teste de demanda em estágio inicial, e eu prefiro dizer isso do que fingir o contrário. O contrato da API é estável (mudanças quebradas apenas via /v2/, nunca silenciosamente), o plano gratuito permanece, e o código é licenciado sob MIT — se o serviço hospedado algum dia for descontinuado, as chaves funcionam por 90 dias e você pode auto-hospedar o mesmo comportamento.
A objeção óbvia é: "Eu só vou conectar o ajv eu mesmo." Legítimo! Essa é precisamente a suposição que estou testando — se uma chamada HTTP/MCP que cobre múltiplos tipos de contrato, com erros legíveis por agentes e zero infraestrutura para manter, vale a pena pagar em comparação a N bibliotecas que você integra e mantém atualizadas você mesmo. (Fato divertido de construir isso: o ajv em si não roda em Cloudflare Workers — ele compila esquemas via new Function(), que o runtime proíbe. As coisas que você aprende apenas ao implantar.)
Se você constrói pipelines de agentes: você usaria isso? O que está faltando? Abra um problema, ou apenas me diga aqui por que você não usaria — isso é o dado mais útil de todos.

Repo: https://github.com/machinegrade/validate
Documentação da API: https://api.machinegrade.dev/openapi.yaml

Contexto Triplo Up

Empresas brasileiras que utilizam agentes de IA podem enfrentar custos altos devido a erros silenciosos em suas saídas. A implementação de validações automáticas pode reduzir esses custos e melhorar a eficiência operacional, garantindo que os dados gerados estejam sempre em conformidade com os esquemas esperados.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.