MCP para empresas: quais sistemas internos expor como ferramentas

Um servidor MCP para empresas é um conjunto delimitado de ferramentas que permite a um agente de IA ler ou agir em um dos seus sistemas internos pelo Model Context Protocol, um padrão aberto para conectar modelos a ferramentas e dados. A decisão útil não é se um sistema pode ser conectado, mas quais das suas ações um agente deve executar sem uma pessoa no circuito. Exponha primeiro o acesso de leitura e ações restritas e reversíveis, e mantenha pagamentos, compromissos legais, exclusões e tudo o que o cliente vê atrás de uma interface que uma pessoa opera.

Principais pontos

• Exponha um sistema por meio de um servidor de ferramentas somente quando uma tarefa específica e recorrente precisar dele, e não porque a conexão está disponível.
• Comece com ferramentas somente de leitura que devolvam resultados delimitados e identificados, e depois acrescente ações de escrita restritas, uma de cada vez.
• Mantenha movimentação de dinheiro, compromissos legais, exclusões, alterações em massa e mensagens para clientes atrás de uma interface operada por pessoas.
• Dê a cada ferramenta um responsável nomeado, um escopo de permissão, um registro de chamadas e uma forma de revogar o acesso sem reconstruir o agente.
• Avalie cada exposição por um critério de sucesso observável, revisado em data marcada.

O que o MCP padroniza e o que fica com você

O Model Context Protocol oferece a um cliente uma forma consistente de descobrir as ferramentas que um servidor oferece, ler suas descrições e formatos de entrada e chamá-las. Essa consistência importa. Uma ferramenta construída uma vez para o seu sistema de pedidos pode ser acessada por diferentes clientes de agente sem um conector específico para cada um. O protocolo, porém, não decide o que a ferramenta pode fazer. Essas decisões ficam no servidor, nas credenciais que ele guarda e no sistema por trás dele.

Trate cada ferramenta como uma fronteira de autorização. A orientação da OWASP sobre autorização deixa o princípio claro: as verificações de acesso pertencem à lógica do servidor, executada em cada requisição, e não às instruções dadas ao modelo. Uma ferramenta que aceita qualquer identificador de cliente e devolve os registros dele não está protegida por uma frase no prompt que manda o agente consultar apenas o cliente atual. A verificação precisa existir dentro da própria ferramenta.

As descrições das ferramentas e o conteúdo devolvido também são texto que o modelo lê. Documentos, e-mails e páginas da web podem conter instruções dirigidas ao agente, que é o problema de injeção de prompt descrito na folha de referência da OWASP sobre o assunto. Uma ferramenta exposta deve partir do pressuposto de que as entradas podem ser hostis, validá-las contra um formato rígido e nunca permitir que uma string devolvida conceda novas permissões ou amplie um pedido.

Um guia de decisão para cada sistema interno

Passe pelas mesmas perguntas para cada sistema da sua lista. Um sistema que falha nas duas primeiras pode esperar, não importa como sua API seja.

• Existe uma tarefa recorrente que precise dos dados ou das ações deste sistema, com uma pessoa nomeada que vai usar o resultado? Se não, não o exponha.
• O sistema consegue limitar o acesso a uma conta, projeto, região ou tipo de objeto? Se não, o próprio servidor precisa acrescentar esse limite, ou o sistema fica de fora.
• Cada ação pode ser desfeita dentro de um prazo conhecido, ou é definitiva? Ações definitivas ficam atrás de uma interface humana.
• A ação toca dinheiro, uma posição assinada ou legal, um registro de paciente ou cliente, ou uma mensagem que sai da empresa? Essas exigem decisão humana.
• O sistema aceita uma chave de idempotência ou oferece verificação de duplicidade? Sem isso, uma nova tentativa após um tempo esgotado pode repetir uma escrita.
• Você consegue registrar cada chamada com a identidade usada, as entradas, o resultado e a hora? Se não, a ferramenta não está pronta.
• Quem revoga o acesso e com que rapidez? Defina o nome da pessoa e o procedimento antes do lançamento.

A maioria das empresas descobre que a primeira triagem elimina mais sistemas do que esperava. Uma lista de contatos pode muitas vezes ser exposta para consultas. Uma conta bancária raramente deveria ser exposta para qualquer coisa além da consulta de saldo, e mesmo essa merece uma revisão separada antes de ser conectada.

Comece com ferramentas de leitura que devolvem resultados delimitados

O acesso de leitura é o ponto de partida de menor risco, e também o mais revelador. Uma ferramenta de leitura mostra onde os dados estão bagunçados, quais campos faltam e quais perguntas as pessoas realmente fazem. Essas descobertas moldam qualquer ação de escrita que você acrescente depois. Para a parte técnica do acesso de leitura a bancos de dados, veja como conectar um agente de IA a um banco de dados com acesso somente leitura.

Uma boa ferramenta de leitura é delimitada de quatro formas. Ela devolve um número máximo fixo de linhas, usa cursores para as páginas seguintes e inclui apenas os campos que a tarefa exige. Cada resposta traz a hora da última sincronização, para que um dado desatualizado nunca seja apresentado como atual. Quando nada corresponde, a ferramenta diz isso explicitamente, em vez de devolver um palpite próximo.

Uma ferramenta de leitura que informa que nenhum registro foi encontrado é mais útil do que uma que devolve o registro mais parecido.

Cenário ilustrativo: um distribuidor expõe uma única ferramenta de leitura que devolve o status dos pedidos de compra em aberto de um fornecedor, com limite fixo de linhas e a hora da última sincronização em cada resposta. A equipe de vendas consulta a previsão de entrega sem abrir o ERP, e ninguém consegue alterar um pedido por meio dessa ferramenta. Se o cadastro do fornecedor não tem uma data de entrega, a resposta informa que a data não está no sistema, em vez de estimar uma.

Quais ações de escrita podem ser entregues com segurança

As ações de escrita devem começar restritas e reversíveis. Criar um rascunho, anexar um arquivo a um registro, adicionar uma nota interna ou propor um reagendamento dentro de regras publicadas são bons primeiros candidatos. Alterar um registro já confirmado, enviar uma mensagem ou encerrar um chamado é uma decisão posterior, tomada somente depois que o comportamento de leitura e de rascunho tiver sido revisado em uso real.

As duplicidades são a falha de escrita mais comum. Um agente que tenta de novo após um tempo esgotado pode criar um segundo pedido, uma segunda reserva ou uma segunda fatura se a ação não for idempotente. Alguns fornecedores já incluem esse mecanismo. A Stripe, por exemplo, documenta chaves de idempotência que permitem repetir uma requisição com segurança, sem repetir o efeito. Quando o sistema de destino não oferece nada parecido, o servidor de ferramentas precisa manter o próprio registro de ações concluídas e consultá-lo antes de escrever. O padrão é tratado com mais profundidade em ações idempotentes em agentes de IA.

Mantenha as entradas da ferramenta de escrita tão rígidas quanto as de leitura. Aceite apenas os campos que a ação exige, rejeite valores fora das faixas permitidas e devolva um objeto de resultado claro que informe o que mudou. Uma mensagem de sucesso vaga torna a análise de incidentes mais difícil do que precisa ser.

O que deve ficar atrás de uma interface operada por pessoas

Uma interface operada por pessoas é a própria tela do sistema ou uma fila de aprovação em que uma pessoa faz a confirmação final. O agente prepara o trabalho, reúne os fatos, redige o documento ou preenche o formulário. A pessoa revisa e confirma. Isso não é uma falha da automação. Em certas ações, é o desenho correto, porque as consequências de um erro são maiores do que o tempo economizado ao eliminar o clique.

As categorias abaixo devem ficar atrás dessa fronteira, a menos que um caso específico e revisado justifique o contrário:

• Pagamentos, reembolsos, notas de crédito e qualquer alteração em dados bancários ou de repasse.
• Assinaturas e qualquer compromisso que vincule a empresa a um terceiro.
• Exclusões, edições em massa e alterações em permissões, papéis ou preços.
• Mensagens para clientes ou pacientes que nenhuma pessoa tenha revisado.
• Decisões sobre elegibilidade, crédito, conteúdo clínico ou exposição jurídica.

A fronteira não é permanente. Atravessá-la deve seguir evidências: um período de uso registrado e revisado, um critério de sucesso claro e uma pessoa nomeada que aceite a mudança. No caso de pagamentos, em especial, os limites merecem regras escritas próprias, como discutido em limites seguros para pagamentos feitos por agentes de IA.

Checklist antes do lançamento e como o processo continua depois

Antes de qualquer servidor de ferramentas entrar em produção, confirme por escrito cada item:

• Uma matriz de ferramentas de uma página lista cada ferramenta, seu responsável, seu escopo, as ações permitidas e a regra de aprovação. Um modelo para isso está descrito em matriz de permissões de ferramentas para agentes de IA.
• Cada ferramenta usa a própria credencial, com o menor escopo que funciona, e nenhuma ferramenta compartilha uma conta ampla com outra.
• Cada chamada é registrada com identidade, entradas, resultado e hora, e alguém revisa esses registros em uma agenda definida.
• As ferramentas de escrita têm verificação de duplicidade ou chave de idempotência, e as novas tentativas foram testadas.
• Existe um procedimento de revogação, com uma pessoa nomeada, e ele foi ensaiado ao menos uma vez.
• Um critério de sucesso observável está definido para cada ferramenta, e a data da revisão está no calendário.

A Be Human projeta e opera esse tipo de camada para empresas. As decisões de exposição descritas acima são registradas em uma matriz de ferramentas, com responsáveis, escopos e limites de aprovação, antes de qualquer conexão. A operação gerenciada mantém essas decisões atualizadas: monitoramento das chamadas, revisões de permissão quando uma equipe muda, resposta a incidentes quando a API de um fornecedor se altera e melhorias controladas quando uma ferramenta ganha mais alcance. O primeiro trabalho define um papel útil, a memória e as ferramentas de que ele precisa, seus limites de aprovação e um critério de sucesso, o que mantém a primeira exposição pequena o bastante para ser medida. Se você não tem certeza de qual dos seus sistemas deve ser exposto primeiro, o diagnóstico gratuito da Be Human pode ajudar a identificar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Um servidor MCP é o mesmo que dar a um agente de IA acesso total a um sistema? Não. Um servidor MCP expõe apenas as ferramentas que você define, e cada ferramenta pode ser limitada a ações, objetos e dados específicos. O acesso deve ser desenhado como um conjunto de ferramentas restritas, cada uma com credencial própria, e não como uma única conexão com tudo o que o sistema permite fazer.

Devemos esperar o protocolo amadurecer antes de expor qualquer coisa? Não necessariamente. O protocolo cuida de como as ferramentas são descritas e chamadas, enquanto o trabalho que carrega risco real, que é definir escopos, registrar, impedir duplicidades e aprovar, é o mesmo qualquer que seja o padrão usado. Uma pequena ferramenta somente de leitura pode ser construída e revisada agora, e migrada depois se as ferramentas do seu cliente mudarem.

Como saber se uma ferramenta funciona bem o suficiente para ganhar mais permissões? Defina, antes do lançamento, um critério de sucesso observável, como a proporção de consultas que uma pessoa aceita sem correção, e revise esse critério em uma agenda. Amplie a ferramenta somente quando o critério se sustentar por um período de uso real e os registros de chamadas não mostrarem padrões inesperados. Se os registros trouxerem surpresas, corrija a causa antes de qualquer mudança de escopo.

Quem deve ser o responsável por um servidor de ferramentas dentro da empresa? Designe um responsável de negócio, que decide o que a ferramenta pode fazer, e um responsável técnico, que mantém credenciais, registros e as mudanças dos fornecedores. O responsável de negócio aprova as mudanças de escopo, enquanto o técnico pode revogar o acesso imediatamente caso ocorra um incidente.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.