O que é um servidor ERP MCP?

Um servidor que transforma um sistema em ferramentas

O Protocolo de Contexto do Modelo tem três papéis. Um host é uma aplicação de IA como Claude ou ChatGPT. Dentro do host, um cliente é criado por servidor e fala apenas com aquele servidor. Um servidor é um serviço que oferece contexto e capacidades ao host através de um pequeno número de primitivos. Os princípios de design da especificação dizem que os servidores devem ser fáceis de construir, compostáveis e incapazes de ver toda a conversa ou outros servidores; o host mantém a conversa e impõe o consentimento, o servidor vê apenas as chamadas endereçadas a ele.

Um servidor ERP MCP, portanto, não é o ERP. É a superfície de ação do ERP, expressa como ferramentas com entradas tipadas, servidas em uma URL. A decisão de design interessante é o que é uma ferramenta. Um servidor de clima tem uma; um sistema de negócios tem centenas, e as úteis são ações que uma pessoa poderia realizar (criar uma fatura, registrar um pagamento, mover um negócio, reservar estoque) em vez de linhas em tabelas. O servidor de espaço de trabalho da Sois, por exemplo, publica ferramentas com nomes como criar fatura, registrarPagamento, searchContacts e examinarContato agrupados por módulo, e a lista exata que um chamador recebe depende de quem ele é.

Ferramentas, recursos e sugestões

A especificação define três primitivos de servidor, e eles diferem em quem controla seu uso. Ferramentas são controladas pelo modelo: o modelo decide quando chamar uma. Recursos são impulsionados pela aplicação: o host decide qual contexto anexar, muitas vezes com o usuário escolhendo de uma lista. Prompts são templates controlados pelo usuário. Um ERP precisa do primeiro, pode se beneficiar do segundo e raramente precisa do terceiro.

Duas características dos resultados das ferramentas são importantes para um sistema de negócios. Uma ferramenta pode declarar um outputSchema e retornar conteúdo estruturado que esteja em conformidade com isso, juntamente com o texto que um modelo lê, para que uma integração possa usar o resultado sem analisar prosa. E uma ferramenta que falha por um motivo comercial (uma fatura no estado errado, uma data no passado, uma permissão ausente) retorna um resultado normal com isError: true e uma explicação, em vez de um erro de protocolo, para que o modelo possa corrigir sua entrada e tentar novamente. Erros de protocolo são reservados para solicitações malformadas e ferramentas desconhecidas.

O transporte e a especificação atual

Dois transportes são padrão. Stdio é para um servidor que o cliente inicia como um processo local, que é como ferramentas de desktop, como acesso a arquivos, funcionam. HTTP transmitível é para servidores remotos e é o que um ERP usa: o servidor expõe um endpoint que aceita um HTTP POST por mensagem JSON-RPC e responde com um objeto JSON ou um fluxo de Eventos Enviados pelo Servidor escopado para essa solicitação, para que uma chamada longa possa enviar progresso antes de seu resultado final. O transporte HTTP anterior com SSE está obsoleto.

A revisão atual, 2026-07-28, mudou o transporte de uma maneira que importa para quem implanta um servidor atrás de um balanceador de carga. Ela removeu sessões em nível de protocolo: não há mais um handshake de inicialização ou um cabeçalho de identificador de sessão, cada solicitação carrega sua versão de protocolo e capacidades do cliente em seus próprios metadados, e um servidor que precisa de estado entre chamadas retorna um identificador explícito que o modelo passa de volta como um argumento. Servidores escritos contra a revisão de 2025-11-25, que usavam sessões, continuam funcionando porque os clientes são obrigados a detectar a era anterior e reverter; um novo servidor não deve adotar sessões.

Autorização: para quem é a chamada

Para transportes HTTP, a especificação define um fluxo OAuth 2.1. O servidor é um servidor de recursos e deve publicar metadados de recursos protegidos (RFC 9728) nomeando seu servidor de autorização; quando uma solicitação chega sem um token, ele responde 401 com um cabeçalho WWW-Authenticate apontando para esses metadados e, idealmente, o menor escopo necessário. O cliente descobre os endpoints do servidor de autorização, se identifica (documentos de metadados de ID do cliente são o caminho recomendado; o registro dinâmico é mantido por compatibilidade), executa um fluxo de código de autorização com PKCE e deve incluir a URI canônica do servidor como o parâmetro de recurso para que o token esteja vinculado apenas a este servidor. O servidor deve validar esse público, deve recusar tokens emitidos para qualquer outra coisa e nunca deve passar um token para outro serviço.

A consequência para um ERP é a mais importante. Como o token identifica uma pessoa, o servidor pode variar o resultado de tools/list pelas credenciais na solicitação, e a especificação diz isso explicitamente. Esse é o mecanismo para filtragem baseada em função: a lista de um usuário financeiro e a lista de um usuário de armazém vêm do mesmo servidor e são diferentes. Escopo insuficiente em tempo de execução é sinalizado com um 403 e um desafio de escopo que o cliente pode superar, embora para a maioria dos sistemas de negócios a verdadeira fronteira seja a função no ERP, em vez do escopo OAuth amplo.

A parte difícil: permissões e transações

Tudo o que foi mencionado acima pode ser implementado em uma tarde com um SDK. O que separa um servidor ERP MCP de uma demonstração é o tratamento das duas coisas que o protocolo deixa para o servidor: se uma chamada é permitida e o que uma chamada significa.

A permissão precisa ser verificada duas vezes. Filtrar a lista de ferramentas impede que o modelo escolha algo que não deveria, o que economiza tokens e confusão. Verificar novamente quando a ferramenta é executada é a verdadeira fronteira, porque um cliente pode enviar qualquer chamada que desejar. Uma recusa é melhor retornada como um erro de execução da ferramenta, para que o modelo a leia e a relate, em vez de como uma falha de transporte que encerra a vez. Isso é como uma chamada recusada aparece em um espaço de trabalho Sois: um resultado normal, sinalizado, com uma razão.

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Tool not permitted for this account: approveInvoice requires the finance approver role."
      }
    ],
    "isError": true
  }
}

Uma recusa de permissão retornada como um erro de execução da ferramenta. O modelo aprende o porquê e pode pedir à pessoa para aprovar em vez disso; nada foi escrito. Sois também reserva códigos de erro JSON-RPC para sessões não autorizadas, créditos insuficientes, ferramentas não permitidas e limites de orçamento atingidos.

Transações são a segunda metade. Uma ferramenta deve mapear para uma transação comercial com um claro antes e depois: criar fatura produz um rascunho com um identificador, registrarPagamento aplica um pagamento a uma fatura, e nenhum deles deixa um estado meio escrito se falhar. Modelos tentam novamente, então gravações devem ser seguras para repetir ou devem recusar uma repetição com uma mensagem clara; as anotações da especificação permitem que um servidor declare uma ferramenta como somente leitura, idempotente ou destrutiva, e clientes como ChatGPT usam essas dicas ao decidir se devem pedir confirmação. Onde um passo precisa de uma decisão que está acima da autoridade do agente, o servidor pode retornar um resultado que requer entrada, perguntando à pessoa uma questão através do cliente, em vez de adivinhar.

Como a Sois implementa um

Um espaço de trabalho Sois é um servidor MCP em uma única URL, o endereço do espaço de trabalho seguido por /api/mcpEle responde ao desafio 401 com metadados de recurso protegido, publica seus metadados de servidor de autorização, requer PKCE e emite tokens com escopo para o espaço de trabalho; um conector no Claude ou ChatGPT completa o login sem nada colado. Um token bearer com uma chave de API está disponível para scripts que não utilizam OAuth, com identidade e gastos mantidos em credenciais separadas de propósito.

A lista de ferramentas é gerada a partir das definições de ferramentas ao vivo e filtrada por função e aplicativos instalados; em seguida, cada chamada é verificada quanto a permissões na execução e falha de forma segura. As chamadas têm limite de taxa por conexão, são medidas onde o próprio agente do espaço de trabalho faz o raciocínio e são isentas de cobranças de IA onde o agente do chamador faz, limitadas por um orçamento definido pelo espaço de trabalho e registradas com entradas e resultados contra a pessoa que as fez. Aplicativos publicados no marketplace adicionam suas ferramentas à mesma lista sob as mesmas regras, de modo que o aplicativo de um desenvolvedor é operável por um agente no momento em que é instalado.

Perguntas que as pessoas fazem

Este artigo é revisado quando os produtos que descreve mudam. Próxima revisão agendada: 4 de dezembro de 2026.