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 anfitrião é uma aplicação de IA como Claude ou ChatGPT. Dentro do anfitrião, um cliente é criado por servidor e fala apenas com esse servidor. Um servidor é um serviço que oferece contexto e capacidades ao anfitrião 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, compostos e incapazes de ver toda a conversa ou outros servidores; o anfitrião mantém a conversa e aplica o consentimento, o servidor vê apenas as chamadas dirigidas a ele.

Um servidor ERP MCP não é, portanto, 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 meteorologia tem uma; um sistema de negócios tem centenas, e as úteis são ações que uma pessoa poderia realizar (criar uma fatura, registar um pagamento, mover um negócio, reservar stock) em vez de linhas em tabelas. O servidor de espaço de trabalho da Sois, por exemplo, publica ferramentas com nomes como criar fatura, registarPagamento, searchContacts e examinarContacto agrupados por módulo, e a lista exata que um chamador recebe depende de quem são.

Ferramentas, recursos e sugestões

A especificação define três primitivos de servidor, e eles diferem em quem controla o seu uso. As ferramentas são controladas pelo modelo: o modelo decide quando chamar uma. Os recursos são impulsionados pela aplicação: o anfitrião decide que contexto anexar, muitas vezes com o utilizador escolhendo de uma lista. Os prompts são modelos controlados pelo utilizador. Um ERP precisa do primeiro, pode 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 esquemaDeSaída e retornar conteúdoEstruturado que esteja em conformidade com ele, 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 uma razão de negócio (uma fatura no estado errado, uma data no passado, uma permissão em falta) retorna um resultado normal com isError: true e uma explicação, em vez de um erro de protocolo, para que o modelo possa corrigir a sua entrada e tentar novamente. Erros de protocolo são reservados para pedidos malformados 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 as ferramentas de desktop, como o acesso a ficheiros, funcionam. HTTP transmitível é para servidores remotos e é o que um ERP utiliza: o servidor expõe um endpoint que aceita um POST HTTP por mensagem JSON-RPC e responde com um objeto JSON ou um fluxo de Eventos Enviados pelo Servidor limitado a esse pedido, para que uma chamada longa possa enviar progresso antes do seu resultado final. O transporte HTTP anterior com SSE está obsoleto.

A revisão atual, 2026-07-28, alterou o transporte de uma forma que é importante para quem está a implementar um servidor atrás de um balanceador de carga. Removiu sessões a nível de protocolo: já não existe um handshake de inicialização ou um cabeçalho de identificador de sessão, cada pedido transporta a sua versão de protocolo e capacidades do cliente na sua própria metadata, 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 a funcionar porque os clientes são obrigados a detectar a era anterior e recuar; 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 o seu servidor de autorização; quando uma solicitação chega sem um token, responde com 401 e 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, identifica-se (documentos de metadados do ID do cliente são o caminho recomendado; o registo dinâmico é mantido para compatibilidade), executa um fluxo de código de autorização com PKCE e deve incluir a URI canónica do servidor como 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 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ções: a lista de um utilizador de finanças e a lista de um utilizador de armazém vêm do mesmo servidor e são diferentes. Um 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 o verdadeiro limite seja a função no ERP em vez do escopo OAuth grosseiro.

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

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

A permissão tem de 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 é o verdadeiro limite, porque um cliente pode enviar qualquer chamada que desejar. Uma recusa é melhor devolvida como um erro de execução da ferramenta, para que o modelo a leia e a reporte, em vez de como uma falha de transporte que termina a vez. Isto é como uma chamada recusada aparece de 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 devolvida 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. A 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 orçamentais atingidos.

As transações são a segunda metade. Uma ferramenta deve corresponder a uma transação comercial com um claro antes e depois: criar fatura produz um rascunho com um identificador, registarPagamento aplica um pagamento a uma fatura, e nenhum deles deixa um estado meio escrito se falhar. Os modelos tentam novamente, portanto, as 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 o 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 devolver um resultado que requer entrada pedindo à pessoa uma pergunta através do cliente, em vez de adivinhar.

Como a Sois implementa um

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

A lista de ferramentas é gerada a partir das definições de ferramentas em tempo real e filtrada por função e aplicações instaladas, sendo que cada chamada é verificada quanto a permissões na execução e falha em modo seguro. As chamadas têm limites de taxa por ligação, são medidas quando o agente próprio do espaço de trabalho faz o raciocínio e isentas de custos de IA quando o agente do chamador o faz, limitadas por um orçamento definido pelo espaço de trabalho, e registadas com entradas e resultados em relação à pessoa que as fez. As aplicações publicadas no mercado adicionam as suas ferramentas à mesma lista sob as mesmas regras, pelo que a aplicação de um desenvolvedor é operável por um agente no momento em que é instalada.

Perguntas que as pessoas fazem

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