MCP Server como produto: como empacotар suas ferramentas de forma profissional

O que significa "MCP server como produto"?

Um MCP server é, na essência, um processo que expõe ferramentas e recursos para que um modelo de linguagem (LLM) possa chamá-los durante uma conversa ou fluxo de agente. Tecnicamente, qualquer arquivo Python com @tool já funciona. Mas funcionar não é o mesmo que ser sustentável.

Quando falamos em "produto", estamos adicionando quatro dimensões que um script simples não tem:

1. Contrato de interface — cada ferramenta tem schema JSON fixo e documentado.
2. Ciclo de vida — a ferramenta nasce, madura, é depreciada e removida com aviso prévio.
3. Governança de acesso — nem todo agente pode chamar toda ferramenta.
4. Observabilidade — você sabe quantas vezes cada ferramenta foi chamada, com que latência e qual foi a taxa de erro.

Na prática, a diferença entre um MCP server de script e um MCP server de produto é basicamente a mesma diferença entre uma API interna feita às pressas e um serviço versionado com SLA.

Como escolher quais ferramentas expor

O erro mais comum que vejo em projetos é expor tudo que a empresa tem disponível. Conectar o MCP server a 40 endpoints de um ERP e depois reclamar que o modelo "chama a ferramenta errada" é previsível — e evitável.

O modelo de linguagem usa a descrição da ferramenta para decidir qual chamar. Se você tiver 10 ferramentas com nomes parecidos e descrições vagas, o modelo vai errar. Isso gera latência extra (retry), custo adicional de tokens e, em casos piores, ação errada no sistema.

Critérios práticos para decidir se uma ferramenta merece entrar no servidor:

• Frequência de uso esperada: alguém vai pedir isso pelo menos uma vez por hora de trabalho? Se não, deixa de fora por enquanto.
• Isolamento de efeito colateral: ferramentas de leitura são mais seguras que ferramentas de escrita. Priorize leitura primeiro.
• Custo de uma chamada errada: deletar um registro é diferente de ler um relatório. Ferramentas destrutivas precisam de confirmação humana.
• Unicidade: se duas ferramentas fazem a mesma coisa com parâmetros levemente diferentes, unifique-as numa com parâmetros opcionais.

Minha recomendação: comece com no máximo 7 ferramentas por servidor. Pesquisas internas de times que usam Claude em produção mostram queda de precisão de tool-calling quando o número ultrapassa 12. Adicione ferramentas com base em dados de uso, não em "seria legal ter".

Canvas de produto MCP

Antes de escrever uma linha de código, preencha este canvas para cada ferramenta que você planeja expor. Ele funciona como o "cartão de identidade" da ferramenta e alimenta a documentação do servidor.

Versionamento de ferramentas MCP

Uma das maiores fontes de dor em projetos MCP em produção é mudar o contrato de uma ferramenta sem aviso prévio. O agente que funciona perfeitamente hoje começa a falhar amanhã porque alguém renomeou um campo do output.

Use Versionamento Semântico aplicado ao nível da ferramenta e do servidor:

• PATCH (0.0.X): correções internas sem mudança de interface. Exemplo: corrigiu bug que retornava data em formato errado, mas o campo continua sendo data_entrega: string.
• MINOR (0.X.0): adicionou campo opcional no input ou no output, adicionou nova ferramenta ao servidor. Nada que quebre quem já usa.
• MAJOR (X.0.0): renomeou ferramenta, removeu parâmetro obrigatório, mudou tipo de retorno, removeu ferramenta. Qualquer coisa que quebre agentes existentes.

Na prática, mantenha sempre duas versões ativas durante transição. Quando lançar a v2 de uma ferramenta, mantenha a v1 funcionando por no mínimo 30 dias com header de deprecação. Isso dá tempo para os times de agente migrarem sem urgência.

O endpoint raiz do seu servidor deve sempre retornar metadados:

{
  "servidor": "mcp-crm-interno",
  "versao": "2.1.0",
  "ferramentas": 7,
  "deprecadas": ["buscar_contato_v1"],
  "remocao_planejada": {
    "buscar_contato_v1": "2026-06-30"
  }
}

Discovery automático: como os agentes encontram seu servidor

Em ambientes com múltiplos MCP servers, o agente precisa saber o que está disponível. Existem três abordagens, em ordem crescente de sofisticação:

1. Configuração estática: lista de servidores no arquivo de config do cliente MCP (ex.: claude_desktop_config.json). Funciona bem para times pequenos com poucos servidores. Problema: quando você adiciona um novo servidor, todo mundo precisa atualizar o config manualmente.
2. Registry centralizado: um endpoint HTTP onde agentes consultam a lista de servidores disponíveis e suas capacidades. Ver artigo sobre registry interno de ferramentas MCP.
3. Discovery dinâmico com perfil: o agente faz login, recebe seu perfil de permissões e o registry devolve apenas os servidores que aquele perfil pode acessar. É a abordagem mais segura e a que recomendo para qualquer empresa com mais de 3 equipes usando MCP.

Monetização e chargeback de MCP interno

"Monetização" pode soar estranho para um servidor interno, mas o conceito é simples: quem usa o quê e quanto custa. Em empresas com múltiplos times consumindo o mesmo MCP server, é fundamental ter chargeback — ou seja, atribuir o custo de uso a cada equipe.

Por que isso importa?

• Controle de custos: cada chamada a uma ferramenta consome recursos (CPU, memória, chamadas a APIs externas). Sem chargeback, o time de produto paga pela experimentação do time de dados.
• Priorização de desenvolvimento: se você sabe que a ferramenta X é chamada 5.000 vezes por dia e a ferramenta Y apenas 12 vezes, fica fácil decidir onde investir esforço de melhoria.
• Detecção de uso anômalo: um pico de 10x no uso de uma ferramenta destrutiva merece atenção imediata. Sem métricas, você não enxerga isso.

Na implementação prática, cada chamada ao MCP server deve registrar no mínimo: agent_id, team_id, tool_name, timestamp, duration_ms, tokens_consumidos (quando aplicável) e status.

Com esses dados, você gera um relatório mensal por equipe — exatamente como as clouds fazem com custo de infraestrutura.

Estrutura mínima de um MCP server pronto para produção

Independente da linguagem (Python, TypeScript, Go), um MCP server que vai para produção precisa ter pelo menos:

• Autenticação: o servidor valida quem está chamando antes de qualquer ferramenta. Sem isso, qualquer processo na rede pode chamar suas ferramentas.
• Autorização por scope: validar não só quem é o chamador, mas se ele tem permissão para aquela ferramenta específica.
• Logging estruturado: cada chamada gera uma linha de log em JSON com todos os campos mencionados na seção anterior.
• Health check: endpoint /health que retorna status 200 quando o servidor está operacional. Essencial para balanceadores de carga e orquestradores.
• Graceful shutdown: quando o processo recebe SIGTERM, ele termina as chamadas em andamento antes de fechar. Evita respostas truncadas.
• Rate limiting: proteção contra um agente que entra em loop e chama a mesma ferramenta centenas de vezes por segundo.

Para aprofundar nos aspectos de segurança, leia o artigo sobre segurança em MCP: allowlist, sandbox e logs.

Quando separar em múltiplos servidores MCP

Um erro de design comum é colocar tudo em um servidor só porque é mais simples de manter. Isso funciona até o momento em que você precisa dar permissão diferente para equipes diferentes — aí começa o problema.

Separe em servidores distintos quando:

• O conjunto de ferramentas tem domínio de negócio diferente (CRM vs. ERP vs. Analytics).
• Os requisitos de segurança são distintos (ferramentas de RH não devem estar no mesmo servidor que ferramentas de atendimento).
• A frequência de deploy é diferente — ferramentas estáveis não devem ser afetadas pelo deploy frequente de ferramentas experimentais.
• Times diferentes são donos de domínios diferentes (ownership claro reduz conflito).

Os 5 erros mais comuns ao criar um MCP server

1. Descrições vagas nas ferramentas. "Esta ferramenta busca dados" não ajuda o modelo a decidir quando usar. Escreva como se estivesse escrevendo para um colega júnior que não conhece o sistema.
2. Sem tratamento de erro estruturado. Quando a ferramenta falha, retorne um JSON com {"erro": true, "codigo": "...", "mensagem": "..."} — nunca deixe o modelo receber uma stack trace em texto puro.
3. Ferramentas com efeito colateral sem confirmação. Uma ferramenta que envia e-mail, cria pedido ou deleta registro deve ter um parâmetro confirmar: boolean ou um fluxo de dois passos (dry-run primeiro, execute depois).
4. Sem versionamento desde o início. É muito mais doloroso adicionar versionamento depois de 6 meses com 3 times em produção do que começar com v1.0.0 desde o primeiro deploy.
5. Sem métricas de uso. Sem dados, você não sabe o que está sendo usado, o que está falhando e o que pode ser removido sem impacto.

Próximo passo prático

Se você está começando agora, aqui está a sequência que funciona:

1. Identifique as 3 perguntas mais frequentes que os usuários fazem ao seu sistema hoje. Essas são suas primeiras ferramentas.
2. Preencha o canvas de produto para cada uma delas. Se não conseguir preencher todos os campos, a ferramenta ainda não está pronta para ir para o servidor.
3. Implemente com autenticação e logging desde o primeiro deploy. Não deixe para "depois".
4. Meça por 30 dias. Só depois expanda o número de ferramentas.

Para organizar o catálogo de múltiplos servidores, veja como montar um registry interno de ferramentas MCP. E para entender como esse modelo se encaixa na estratégia geral, leia MCP para empresas: o que é e quando implementar.