Não Construa Seu Servidor MCP como um Wrapper de API

A Anthropic publicou recentemente um post útil sobre a construção de agentes que alcançam sistemas de produção com MCP:

Construindo agentes que alcançam sistemas de produção com MCP

A linha mais importante para os construtores de servidores MCP não é "construa um servidor MCP." É a orientação de design subjacente a isso:

Agrupe ferramentas em torno da intenção, não de endpoints.

Essa distinção é fácil de subestimar.

Se você já tem uma API REST, a versão óbvia do seu servidor MCP é uma fina camada em torno dela:

list_responses
get_response
update_response
delete_response
export_responses
send_notification

Isso funciona para demonstrações. Não é suficiente para agentes de produção.

Eu tenho construído FORMLOVA, um produto de operações de formulários onde os usuários podem criar formulários, revisar respostas, classificar propostas de vendas, executar análises e acionar fluxos de trabalho através de clientes MCP. A parte mais difícil não tem sido expor operações de banco de dados. A parte difícil tem sido decidir qual significado a camada MCP deve carregar.

Este post é um guia prático para essa fronteira.

O problema com ferramentas moldadas por endpoints

Suponha que um usuário pergunte:

Mostre-me a taxa de conversão deste mês, excluindo propostas de vendas.

Com ferramentas moldadas por endpoints, o agente tem que fazer isto:

1. list_responses
2. lidar com paginação
3. inspecionar spam_label
4. decidir quais rótulos remover
5. filtrar por intervalo de datas
6. agregar a contagem
7. calcular a métrica
8. explicar o resultado

Isso é muita lógica de domínio para empurrar para o modelo em cada execução.

Quanto mais moldado pela produção o fluxo de trabalho se torna, pior isso fica:

• Qual rótulo significa "vendas"?
• As respostas incertas devem ser removidas também?
• As respostas não classificadas devem permanecer?
• O que acontece se um humano corrigir manualmente um rótulo?
• A consulta precisa respeitar linhas suavemente excluídas?
• O resultado deve ser permitido para acionar um fluxo de trabalho?

Se o seu servidor MCP não responder a essas perguntas, o modelo terá que reconstruí-las a partir das descrições das ferramentas e do contexto do prompt. Isso é frágil.

O servidor MCP não deve ser apenas um cliente HTTP com esquemas de ferramentas. Ele deve carregar a semântica operacional do produto.

Um pequeno exemplo: exclude_sales

FORMLOVA classifica as respostas de formulários recebidas em três rótulos:

type SpamLabel = "legítimo" | "vendas" | "suspeito";

O classificador não é a parte interessante para este post. O design do MCP é.

Várias ferramentas de resposta e análise aceitam um parâmetro exclude_sales:

server.registerTool("get_responses", {
  inputSchema: {
    form_id: z.number().int(),
    limit: z.number().int().min(1).max(100).default(50),
    exclude_sales: z.boolean().default(false),
  },
});

server.registerTool("get_form_analytics", {
  inputSchema: {
    form_id: z.number().int(),
    exclude_sales: z.boolean().default(false),
  },
});

A implementação é deliberadamente chata:

if (exclude_sales) {
  query = query.or("spam_label.is.null,spam_label.neq.sales");
}

Aquela linha codifica uma decisão de produto:

• vendas respostas são excluídas
• suspeito respostas permanecem visíveis
• null respostas permanecem visíveis

Por quê? Porque respostas incertas e não classificadas não devem desaparecer silenciosamente. Uma consulta real mal classificada como vendas é muito mais cara do que uma proposta de vendas escapando.

Esse é o tipo de regra que pertence ao servidor, não à memória de trabalho do modelo.

O usuário diz:

Analise respostas sem propostas de vendas.

O agente mapeia isso para:

{ "exclude_sales": true }

O servidor possui a regra de domínio.

Essa é a diferença entre um wrapper de API e uma ferramenta consciente da intenção.

Rótulos devem se tornar estado operacional

Um erro comum com recursos de classificação de IA é parar no distintivo.

Você executa uma classif