Eu Escaneei 10 Ferramentas de Desenvolvimento para Prontidão de Agentes de IA. Apenas Uma Aprovou.

Todos estão construindo agentes de IA. Ninguém está construindo para eles.

Eu estive trabalhando em integrações de agentes e continuei encontrando o mesmo problema: quando dizemos "agentes de IA podem usar APIs", quantas ferramentas de desenvolvedor estão realmente configuradas para que um agente descubra e interaja de forma autônoma?

Então, eu realizei uma auditoria de prontidão para agentes em 10 ferramentas de desenvolvedor bem conhecidas. O scanner verifica 32 sinais em 6 categorias:

• Descobribilidade — os agentes podem te encontrar?
• Compreensão — os agentes podem entender sua API?
• Usabilidade — os agentes podem interagir com você?
• Estabilidade — os agentes podem depender de você?
• Experiência do Agente — o que acontece quando um agente aparece?
• Transacionabilidade — os agentes podem fazer negócios com você?

Cada categoria recebe um nível: Pronto, Parcial ou Não Pronto. Para "passar", uma ferramenta precisa ter pelo menos metade de suas categorias como Pronto.

Uma ferramenta passou. Nove não passaram.

Os Resultados

Resend — 4/6 Pronto ✅

O vencedor claro, e não foi nem perto. Resend tem um endpoint MCP em /.well-known/mcp.json, uma especificação OpenAPI pública com 39 endpoints totalmente documentados, dados estruturados Schema.org na página inicial e retorna erros JSON adequados com estrutura consistente.

Isso é o que a prontidão para agentes realmente parece: um agente pode descobrir a API através da descoberta baseada em protocolo (MCP), entender toda a superfície da API através de especificações legíveis por máquina (OpenAPI) e verificar o que o produto faz através de dados estruturados. Nenhuma intervenção humana é necessária em nenhuma etapa.

Stripe — 1/6 Pronto (Estabilidade)

O resultado mais surpreendente da lista. A Stripe literalmente inventou o Protocolo de Comércio Agente. Eles têm um arquivo llms.txt adequado. Eles são, sem dúvida, a API mais amigável para desenvolvedores na internet.

Mas: sem especificação OpenAPI em caminhos descobríveis padrão, sem endpoint MCP, sem /.well-known/agent.json. A Experiência do Agente marcou Vermelho. Um agente acessando o endpoint /api da Stripe recebe uma página HTML, não uma especificação legível por máquina.

A empresa que está construindo o futuro dos pagamentos por agentes não está pronta para agentes.

Vercel — 1/6 Pronto (Estabilidade)

Fundamentos bons — changelog, página de status, cabeçalhos de segurança adequados. Mas a especificação OpenAPI está atrás de uma parede de login, e não há endpoint MCP. Um agente encontraria a documentação, mas não conseguiria ler a superfície da API sem autenticação primeiro.

Postmark — 1/6 Pronto (Descobribilidade)

Possui dados estruturados e llms.txt, que já é mais do que a maioria. Mas o scanner foi limitado por taxa (429) em metade de suas verificações — a página de preços, a página de inscrição e vários caminhos da API retornaram "Muitas Solicitações."

Isso é, na verdade, uma descoberta interessante por si só: limitação de taxa agressiva sem cabeçalhos de limitação de taxa significa que os agentes ficam bloqueados sem uma maneira de se auto-regularem. Se seu limitador de taxa não incluir cabeçalhos Retry-After ou X-RateLimit-*, você não está apenas bloqueando abusos — você está bloqueando a descoberta legítima de agentes.

Clerk — 0/6 Pronto

Possui um impressionante llms.txt de 2.395 linhas — mais conteúdo do que a documentação inteira da maioria das ferramentas. Mas não há especificação OpenAPI em caminhos descobríveis, sem MCP, e os Termos de Serviço parecem proibir o acesso automatizado.

Todo esse investimento em conteúdo é invisível para a descoberta de agentes baseada em protocolo.

Neon — 0/6 Pronto

O llms-full.txt tem 32.588 linhas — de longe o maior do conjunto. Mas a Compreensão marcou Vermelho porque não há especificação OpenAPI em caminhos descobríveis, e nenhum dado estruturado na página inicial.

Este é o exemplo mais claro de um padrão que continuei vendo: investimento pesado em conteúdo legível por LLM enquanto falta a infraestrutura legível por máquina que os agentes realmente usam para descoberta.

Supabase — 0/6 Pronto

Este realmente me surpreendeu. Supabase tem um servidor MCP — eu o uso diariamente. Mas /.well-known/mcp.json retorna 404. Sem dados estruturados, sem especificação OpenAPI em caminhos padrão, llms.txt existe, mas foi sinalizado como básico. A Descobribilidade marcou Vermelho.

As ferramentas estão lá, mas a porta da frente não está conectada para descoberta autônoma. Um agente usando descoberta baseada em protocolo MCP nunca encontraria o servidor MCP da Supabase.

Plaid — 0/6 Pronto

A documentação é boa, o sandbox está disponível, mas sem MCP, sem OpenAPI em caminhos padrão. O preço está atrás de uma tabela sem dados estruturados. Um agente que compara APIs fintech programaticamente não conseguiria incluir a Plaid em sua avaliação.

Twilio — 0/6 Pronto

Tanto a Descobribilidade quanto a Experiência do Agente marcaram Vermelho. O llms.txt existe, mas era grande demais para ser analisado (corpo truncado). Sem MCP, sem OpenAPI em caminhos descobríveis. Para uma empresa que está há mais de 15 anos focada em API, a camada de agente está essencialmente ausente.

SendGrid — 0/6 Pronto

Herda a infraestrutura da Twilio (agora é um produto da Twilio), então as mesmas limitações. O caminho openapi.json retorna uma página HTML em vez de JSON — o que é uma falha particularmente frustrante para um agente que espera dados estruturados.

O que os Dados Realmente Mostram

A lacuna não é a qualidade da API. Todas as ferramentas desta lista têm APIs que os desenvolvedores adoram. A lacuna está na camada de descoberta e legibilidade por máquina — a diferença entre "um desenvolvedor pode ler nossa documentação" e "um agente pode encontrar, avaliar e começar a usar nossa API programaticamente."

Três descobertas específicas se destacaram:

Quase ninguém tem /.well-known/mcp.json

Apenas Resend. Este é o caminho padrão para descoberta baseada em protocolo MCP — como um agente usando MCP encontra seu endpoint de servidor. Sem isso, seu servidor MCP pode existir, mas os agentes seguindo o protocolo não conseguem descobri-lo.

A adoção de llms.txt é forte — mas insuficiente

8 em cada 10 ferramentas tinham um arquivo llms.txt. Isso é uma adoção encorajadora. Mas llms.txt resolve um problema diferente da descoberta de agentes. Ajuda os LLMs a entender o que seu produto faz. Não ajuda um agente usando descoberta baseada em protocolo MCP ou A2A a encontrar sua API.

Um agente navegando em endpoints /.well-known/mcp.json não lerá seu llms.txt. Protocolos diferentes, mecanismos de descoberta diferentes.

O tamanho de llms.txt não correlaciona com a prontidão

Esta foi a descoberta mais contra-intuitiva. O arquivo de 32.588 linhas da Neon não ajudou porque a infraestrutura estruturada ao seu redor estava faltando. O arquivo muito menor da Resend funcionou porque tinha OpenAPI, MCP e dados estruturados apoiando-o.

A lição: llms.txt é valioso quando está em cima de uma infraestrutura legível por máquina sólida. Não é valioso como um substituto para essa infraestrutura.

O que Isso Significa para os Construtores

Se você está construindo agentes que precisam descobrir e avaliar APIs de forma autônoma, você encontrará barreiras em todos os lugares. A camada de infraestrutura que MCP, A2A e x402 assumem — descoberta legível por máquina, preços estruturados, documentação de autenticação programática — mal existe ainda.

Construa seus agentes para lidar com degradação graciosa, porque a maioria das APIs ainda é construída para desenvolvedores humanos navegando em páginas de documentação, não para agentes autônomos tomando decisões programáticas.

E se você está construindo uma API: a barra para prontidão de agentes é mais baixa do que você pensa. A Resend passou com infraestrutura simples — uma especificação OpenAPI pública, um endpoint MCP no caminho padrão e dados estruturados na página inicial. Nenhuma tecnologia exótica. Apenas o básico, feito corretamente.

O scanner é gratuito em