Voltar as noticias
Como agentes de IA se tornam seus clientes — lições do envio de 17 servidores MCP pagos
MCP ProtocolAltaEN

Como agentes de IA se tornam seus clientes — lições do envio de 17 servidores MCP pagos

Dev.to - MCP·11 de junho de 2026

Publicação cruzada para dev.to, Hashnode, Medium.

Sugestão de imagem de capa: tela dividida — lado esquerdo um ticket de suporte ao cliente humano, lado direito uma chamada de API de agente de IA. Sobreposição de título.

A premissa

Durante a maior parte da história do SaaS, o comprador era um humano. Eles visitavam uma página de marketing, se inscreviam, inseriam um cartão de crédito. O produto foi construído para a ergonomia humana — painéis bonitos, e-mails de integração úteis, gerentes de conta para os cheques maiores.

Essa suposição está se quebrando. Cada vez mais, a entidade que chama sua API não é um desenvolvedor integrando seu produto em seu aplicativo. É um agente autônomo (Claude, GPT, um LLM interno) sendo solicitado a usar sua ferramenta no meio da conversa, muitas vezes por um usuário final que o LLM nunca viu e cuja empresa nunca ouviu falar da sua.

Enviei 17 servidores MCP (Modelo de Protocolo de Contexto) nas últimas semanas. Os MCPs são servidores de ferramentas que os agentes de IA chamam para buscar dados ou realizar ações. Por definição, o consumidor não é um humano — é um modelo de linguagem. Depois de semanas projetando essas superfícies de ferramentas e observando o uso escasso, aqui está o que é diferente.

O que muda quando seu cliente é um agente

1. O agente lê sua documentação antes de cada chamada

Os humanos folheiam a documentação uma vez, tiram uma captura de tela do exemplo do SDK, nunca voltam. Os agentes relêem suas descrições de ferramentas em cada conversa — porque é literalmente isso que a especificação do MCP faz. Cada conexão inclui uma chamada tools/list que retorna o nome da ferramenta, descrição e esquema de parâmetros.

Isso significa que sua descrição da ferramenta é o manual do usuário toda vez. Não há "o usuário leu o README." Há apenas a descrição que você entregou ao agente no início da sessão.

Implicação prática: gaste um esforço desproporcional nas descrições das ferramentas. A descrição certa diz ao LLM:

  • O que a ferramenta faz (1 frase)
  • Quando usá-la em vez de outras ferramentas (essa é a parte crítica — LLMs roteiam mal quando as descrições se sobrepõem)
  • O que os parâmetros significam em inglês simples
  • Como será a forma de retorno

Reescrevi a descrição de edgar_read_filing da SEC EDGAR quatro vezes. Versão 1: "Lê um arquivo da SEC." Inútil. Versão 4: "Retorna o texto completo de um arquivo específico da SEC identificado pelo seu número de acesso. Use após edgar_search_filings retornar candidatos. Para extração específica de itens 8-K, use edgar_get_8k em vez disso. Passe section='risk_factors' para extrair apenas divulgações de fatores de risco de 10-Ks."

A quarta versão reduziu chamadas mal roteadas (LLM chamando read_filing quando deveria ter chamado get_8k) em cerca de metade em meus próprios rastros de teste.

2. Erros devem ser acionáveis para o modelo, não apenas para o humano

Quando um humano recebe um erro 429, ele lê a documentação e recua. Quando um agente recebe um 429, ele está prestes a tentar novamente com a mesma carga útil, a menos que seu erro diga para não fazê-lo.

As respostas de erro que um agente vê devem responder: "O que devo fazer agora para ter sucesso?" Exemplos que funcionam:

  • "Limite de taxa alcançado. O nível gratuito permite 100 chamadas/mês por IP. Para continuar, obtenha uma chave de API em https://sec-edgar-mcp.atlasword.workers.dev/upgrade e passe-a como Authorization: Bearer <key>."
  • "Arquivo não encontrado. O número de acesso deve estar no formato 0001193125-23-123456. Use edgar_search_filings para encontrar números de acesso válidos primeiro."

Erros ruins:

  • "Não autorizado"
  • "Solicitação inválida"
  • "Cota excedida"

As boas versões são mais longas. Isso é aceitável. O agente as lê com total atenção; o humano nunca as verá a menos que esteja depurando.

3. O preço deve ser transparente para o modelo, não apenas para o site

Se seu preço é "$9/mês" em uma página de marketing, o agente não sabe disso. O agente sabe o que você retornou na última resposta tools/list. Portanto, você deve codificar os fatos relevantes sobre preços nos metadados da ferramenta ou nas respostas de erro.

Incluo uma ferramenta chamada <product>_get_pricing na maioria dos meus MCPs. Ela retorna a estrutura atual de níveis como JSON. O agente a chama uma vez e agora sabe o que recomendar ao usuário final quando atinge o limite do nível gratuito. Sem isso, o agente irá alucinar um preço ou apenas dirá "você deve atualizar" sem detalhes acionáveis.

4. O funil de conversão se colapsa em um único passo

Para o SaaS humano, o funil é: visitar o site → se inscrever → inserir o cartão → usar o produto → talvez atualizar.

Para o SaaS de agente, o funil é: o usuário final faz uma pergunta → o agente chama sua ferramenta → ou tem sucesso dentro do nível gratuito, ou retorna um erro de atualização com uma URL de atualização direta.

Não há um passo de "se inscrever primeiro". Não pode haver — o agente não tem e-mail, nem método de pagamento, nem conceito de conta. A única maneira de a conversão acontecer é se seu fluxo de atualização for chamável como uma única URL que o agente mostra ao humano.

Concretamente: minha URL de atualização leva a um Checkout do Stripe que retorna uma chave de API utilizável no momento em que o pagamento é confirmado. Nenhum passo de criação de conta. Nenhuma verificação de e-mail. O comprador é o humano supervisionando o agente, e esse humano só quer que o agente continue funcionando. Adicionar qualquer fricção mata a conversão.

5. Sua proposta de valor agora é moldada pelo LLM

Quando o comprador era um desenvolvedor humano, "temos o melhor SDK Python" era uma proposta de valor. Quando o comprador é um LLM, não é. O LLM não se importa com seu SDK.

O que o LLM se importa (segundo minha análise de rastros de erro):

  • Latência. O agente irá expirar em ~10s. Qualquer coisa que leve >5s é tentada novamente, o que prejudica seus limites de taxa e a experiência do usuário.
  • Determinismo. Ferramentas que retornam dados ligeiramente diferentes para as mesmas entradas fazem com que o agente perca confiança no resultado e pergunte novamente.
  • Composabilidade. Ferramentas que se conectam facilmente a outras ferramentas (tipo de saída corresponde ao tipo de entrada da próxima ferramenta provável) são mais utilizadas. Ferramentas que exigem que o agente faça conversão de formato de dados são usadas menos.
  • Qualidade da descrição (veja o ponto 1).

Essa é uma proposta de valor diferente de "ótima DX para desenvolvedores." Seu README agora é um artefato para SEO e integração humana. Sua descrição da ferramenta é a superfície real do produto.

6. O "loop de crescimento" é de agente para agente

Aqui está o inesperado. Uma vez que um agente (digamos Claude) usou sua ferramenta com sucesso em uma conversa, o usuário final é mais propenso a usar Claude para esse tipo de pergunta no futuro. O valor de Claude para esse usuário aumentou por causa da sua ferramenta.

Isso significa que a roda de marketing é parcialmente: "agentes que usaram sua ferramenta entregam melhores respostas, o que torna a plataforma de agentes mais aderente, o que faz a plataforma investir mais na infraestrutura do MCP, o que faz mais agentes descobrirem sua ferramenta."

Você não está apenas vendendo para humanos através de agentes. Você está melhorando indiretamente a posição de mercado do agente, e as plataformas de agentes (Anthropic, OpenAI, Cursor) têm um incentivo para destacar ferramentas que fazem seus agentes parecerem bons.

Estou observando isso empiricamente. Smithery, Glama, mcp.so — essas são superfícies de compras de agentes. Elas não são para humanos navegarem. Elas são para plataformas de agentes rasparem e para os próprios agentes descobrirem ferramentas no momento da inicialização da sessão.

7. O preço pode ser muito mais baixo do que o SaaS humano

O preço mínimo viável do SaaS humano é aproximadamente $9-19/mês porque a atenção do humano para avaliar, se inscrever e integrar é o custo dominante. Abaixo disso, o tempo não vale a pena.

O SaaS de agente não tem esse piso. O agente não tem custo de atenção. A conversão acontece em um segundo quando o humano clica em "atualizar." Isso significa $5/mês ou até mesmo

Contexto Triplo Up

As empresas brasileiras devem adaptar suas APIs para atender não apenas a humanos, mas também a agentes de IA. Isso implica em melhorar a documentação e a estrutura de preços, além de otimizar a experiência do usuário final. A transformação do funil de conversão é crucial para capturar o potencial de vendas através de agentes autônomos.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.