Protocolo MCP para ferramentas da empresa: permissões e primeiros passos

O Model Context Protocol (MCP) é um padrão aberto que permite a uma aplicação de IA descobrir e chamar ferramentas oferecidas por um servidor separado, usando um formato de mensagem consistente. Para uma empresa, expor ferramentas internas pelo MCP significa que cada capacidade ganha um nome definido, entradas tipadas e uma fronteira de permissão antes que um agente possa usá-la. O ponto de partida mais seguro é um conjunto pequeno de ferramentas somente leitura, ligadas a um papel útil e bem delimitado, e não um catálogo de tudo que o seu software consegue fazer.

Principais pontos

• O MCP padroniza como um agente encontra e chama ferramentas. Ele não decide quem pode usá-las, e essa decisão pertence à sua camada de permissões.
• Cada ferramenta exposta precisa de uma finalidade estreita, entradas tipadas, um resultado claro e um registro de qual cliente a chamou.
• Comece com ferramentas de leitura que respondam perguntas que a sua equipe hoje busca manualmente.
• Mantenha pagamentos, assinaturas, exclusões e mensagens para fora com uma etapa de aprovação, ou deixe essas ações de fora da primeira versão.
• Avalie as primeiras ferramentas com um critério de sucesso observável antes de adicionar outras.

O que realmente envolve expor uma ferramenta da empresa pelo MCP?

Um sistema da empresa, como uma agenda de agendamentos, um cadastro de clientes ou uma biblioteca de documentos, já costuma ter uma API ou um conjunto de funções internas. Expor esse sistema pelo MCP significa colocar um servidor pequeno entre ele e o cliente de IA. O servidor descreve cada ferramenta que oferece, incluindo o nome, uma descrição simples e os parâmetros aceitos. O cliente lê essa lista e pode chamar apenas as ferramentas que o servidor permite.

O detalhe importante é onde ficam as credenciais. O modelo nunca deve receber a senha do sistema nem um token de acesso amplo dentro do prompt. O servidor MCP mantém a conexão com o software, aplica as regras de cada chamada e devolve um resultado. Se um pedido estiver fora dessas regras, o servidor recusa, e o agente recebe uma recusa que pode informar à pessoa que está atendendo.

Esse arranjo move a questão da permissão do prompt para o servidor. Uma instrução dizendo que o agente só pode alterar agendamentos com a confirmação do cliente é um pedido ao modelo. Uma verificação no servidor que rejeita a alteração sem uma aprovação registrada é um controle. Construa controles e trate as instruções como orientação que fica por cima deles.

Por que um protocolo padrão muda a questão da permissão?

Sem um padrão, cada agente ganha uma conexão própria com cada sistema, e o acesso tende a crescer uma integração de cada vez. Um protocolo comum oferece um único lugar para revisar o que um cliente conectado consegue alcançar. Isso reduz o número de caminhos escondidos até o seu software, que é o principal ganho prático.

Ele também concentra risco. Um único servidor que expõe muitas capacidades dá a qualquer cliente conectado todas elas, a menos que você restrinja cada uma. As orientações de autorização da OWASP são diretas nesse princípio: verificar o acesso em cada requisição, negar por padrão e nunca confiar que a interface esconde uma função. Aplique isso a cada ferramenta separadamente, e não apenas ao servidor como um todo.

O conteúdo devolvido pelas ferramentas exige a mesma cautela. Um documento, um e-mail ou uma página web devolvidos por uma ferramenta podem conter texto escrito para parecer uma instrução. As orientações da OWASP sobre injeção de prompt recomendam tratar a entrada do modelo e o conteúdo recuperado como não confiáveis. Na prática, o resultado de uma ferramenta pode orientar um rascunho, mas nunca deve, sozinho, autorizar um pagamento, uma exclusão ou uma mensagem a um cliente.

O escopo também muda com o tempo. Uma ferramenta criada para um papel pode ser reaproveitada depois por um segundo agente, e esse reaproveitamento deve disparar uma nova revisão, e não herdar a aprovação anterior. Registre para qual papel cada ferramenta foi aprovada, para que o motivo do acesso continue visível quando a configuração crescer.

Como escolher as primeiras ferramentas a expor?

Escolha as primeiras ferramentas a partir do trabalho, e não do menu do software. A sequência abaixo mantém a escolha pequena e testável, seguindo a mesma lógica descrita em o que é MCP e por que importa para agentes de negócio.

• Defina o único papel que o agente vai exercer, como responder dúvidas de agendamento ou preparar acompanhamentos com fornecedores.
• Anote as perguntas que esse papel precisa responder e os registros que precisa consultar para isso.
• Para cada registro, decida se o agente apenas lê, prepara um rascunho a partir dele ou escreve de volta nele.
• Exponha primeiro as ferramentas de leitura, começando pelos registros que uma pessoa busca manualmente com regularidade.
• Adicione ferramentas de rascunho apenas onde uma pessoa revisa o resultado e envia.
• Deixe de fora qualquer ação de escrita que não possa ser desfeita, que movimente dinheiro, assine um documento ou contate um cliente sem revisão.
• Confirme que o sistema de origem tem uma interface estável e documentada antes de construir qualquer coisa. Se não tiver, o primeiro passo é arrumar essa interface, e não conectar um agente a ela.

Que nível de permissão cada ferramenta deve ter?

A maioria das ferramentas de negócio se encaixa em três níveis. As ferramentas de leitura devolvem informação e não mudam nada. As ferramentas de rascunho criam um item pendente, como uma resposta em uma fila de revisão ou uma proposta de alteração na agenda, que uma pessoa aceita. As ferramentas de escrita alteram um registro ativo ou enviam algo para fora. Dê a cada ferramenta o menor nível que ainda complete a tarefa.

A distinção importa mais do que o próprio protocolo. Uma ferramenta de leitura que devolve o histórico completo de um cliente pode expor mais dados pessoais do que o papel precisa, então limite os campos, e não só as ações. Uma ferramenta de rascunho só é segura se quem revisa conseguir ver exatamente o que vai acontecer ao aprovar. Uma ferramenta de escrita deve exigir um registro de aprovação, e o servidor deve guardar quem aprovou a alteração e quando. Para um tratamento mais aprofundado dessa sequência, veja menor privilégio para agentes de IA e a diferença entre permissões de leitura, rascunho e envio.

Um cenário ilustrativo: um coordenador de reagendamentos

O cenário a seguir é ilustrativo e não descreve um cliente real. Uma pequena empresa de serviços quer que um agente trate pedidos de reagendamento feitos por clientes. O primeiro servidor MCP expõe quatro ferramentas. Uma ferramenta list_availability lê os horários livres da agenda. Uma ferramenta get_appointment lê um agendamento, devolvendo apenas a data, o endereço e o tipo de serviço. Uma ferramenta draft_reschedule cria uma alteração pendente, com o horário proposto e a mensagem do cliente. Uma ferramenta confirm_reschedule grava a alteração na agenda, mas o servidor só aceita quando a aprovação de um membro da equipe está registrada naquele rascunho específico.

O agente responde à maioria das dúvidas de reagendamento lendo a disponibilidade e propondo um rascunho. Um coordenador revisa a fila toda manhã e aprova ou corrige cada item. As confirmações só são enviadas depois dessa aprovação, nunca por julgamento próprio do agente. Se a mensagem de um cliente pedir ao agente que cancele todas as visitas e emita um reembolso, o agente encaminha o pedido para uma pessoa, porque nenhuma ferramenta da lista cancela ou reembolsa. A fronteira se mantém porque ela vive no servidor, e não na redação do prompt.

O que registrar e como saber se funciona?

Cada chamada de ferramenta deve deixar um registro: qual cliente fez a chamada, qual ferramenta usou, os parâmetros com campos sensíveis mascarados, o status do resultado e a referência de aprovação, se houver. Sem esse rastro, você não consegue saber se o agente está funcionando como previsto ou apenas parece estar. Os conceitos de observabilidade do OpenTelemetry descrevem o padrão geral de traces, logs e métricas, e a mesma disciplina se aplica às chamadas de ferramentas de agentes.

Defina o sucesso antes que a primeira ferramenta entre em operação. No exemplo de agendamento, o critério pode ser que o revisor consiga aceitar ou corrigir cada rascunho sem reabrir a conversa com o cliente. Verifique esse critério com um conjunto fixo de pedidos realistas e repita a verificação após qualquer mudança no servidor, no modelo ou no software da agenda. Uma ferramenta que passa hoje pode falhar depois que um campo for renomeado no sistema de origem, por isso a avaliação recorrente faz parte da manutenção e não é um extra opcional.

As falhas também precisam de regras. Quando uma chamada falha, o agente deve informar que a ferramenta falhou e parar, em vez de tentar de novo com parâmetros diferentes até algo funcionar. Os limites de nova tentativa pertencem ao servidor, para que um único pedido não gere uma sequência de chamadas repetidas contra um sistema em produção. Revise o registro de falhas junto com o de sucessos, porque recusas repetidas costumam indicar uma permissão estreita demais ou alguém testando discretamente os limites.

Como a Be Human cuida de servidores MCP em operações gerenciadas

A Be Human delimita o primeiro servidor MCP em torno de um papel, define permissões de leitura, rascunho e escrita para cada ferramenta e mantém as credenciais do lado do servidor, e não em prompts ou notas compartilhadas. A operação gerenciada então cobre as partes que mudam depois do lançamento: monitoramento das chamadas de ferramentas, avaliações recorrentes contra o critério combinado, manutenção quando as interfaces de origem mudam, revisão periódica de permissões e resposta a incidentes quando um limite é testado. O objetivo é que os limites acordados no início continuem valendo depois da próxima mudança, e que cada nova ferramenta seja adicionada só depois que a primeira tenha sido verificada.

Se você não tem certeza de qual das suas ferramentas merece ser a primeira, o diagnóstico gratuito de IA da Be Human pode ajudar a identificar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

MCP é a mesma coisa que dar acesso total do meu software a um agente de IA? Não. O MCP é uma forma de um cliente se conectar a ferramentas que um servidor escolhe expor. O acesso que o agente recebe depende de quais ferramentas você constrói, do que cada uma pode fazer e de como o servidor verifica cada chamada. Um servidor bem desenhado expõe poucas capacidades estreitas, e não o sistema inteiro.

Preciso de MCP para conectar um agente às minhas ferramentas de negócio? Nem sempre. Algumas integrações usam uma API direta ou um conector nativo da plataforma, e isso pode ser uma boa escolha para um sistema só. O MCP se torna mais útil quando várias ferramentas precisam ser oferecidas de forma consistente a um ou mais agentes, e quando você quer um único lugar para revisar o que cada cliente consegue alcançar.

Qual ferramenta devo expor primeiro? Escolha uma ferramenta somente leitura que responda a uma pergunta que a sua equipe já responde consultando o mesmo registro. Mantenha-a estreita, devolva apenas os campos que o papel precisa e registre cada chamada. Adicione ferramentas de rascunho ou de escrita só depois que as ferramentas de leitura passarem na verificação combinada de antemão.

Quem deve aprovar alterações em um servidor MCP? O responsável pelo processo de negócio deve aprovar o que o agente pode fazer, e o responsável pelos sistemas deve aprovar como o servidor chega até eles. Mantenha um registro escrito das duas decisões. Revise as permissões de novo sempre que uma ferramenta for adicionada, um campo mudar ou uma etapa de aprovação for contornada.

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