Por Dentro do Protocolo de Contexto do Modelo (MCP): Arquitetura, Motivação e Uso Interno

Introdução

Aplicações baseadas em LLM criaram uma necessidade premente para que os modelos acessem dados atualizados e específicos do domínio de fontes diversas. O MCP aborda isso fornecendo um protocolo unificado que padroniza como as aplicações podem expor dinamicamente dados e capacidades a qualquer aplicação baseada em LLM.

Visão Geral do MCP

No seu cerne, o MCP segue uma arquitetura cliente-servidor baseada em JSON-RPC, onde uma aplicação host pode se conectar a múltiplos servidores:

• Hosts MCP são aplicações baseadas em LLM, como Claude Desktop, IDEs ou ferramentas de IA, que desejam acessar dados através do MCP.
• Clientes MCP implementam o protocolo MCP do lado do cliente em diferentes linguagens de programação. Eles são a ponte através da qual os Hosts MCP se conectam com os Servidores MCP.
• Servidores MCP expõem dados e capacidades específicas através do protocolo MCP. Ele pode fornecer três tipos principais de capacidades:
  • Recursos são dados que os servidores MCP disponibilizam para as aplicações lerem. Eles podem incluir conteúdos de arquivos, respostas de API, etc. Os recursos são controlados pela aplicação; as aplicações decidem como incluí-los no fluxo do usuário.
  • Ferramentas são capacidades e dados expostos pelos servidores MCP. Por exemplo, um servidor MCP Kubernetes pode expor ferramentas para obter todos os pods e excluir um pod. As ferramentas são controladas pelo modelo. Os LLMs decidem chamá-las com base no contexto fornecido.
  • Prompts são interações de usuário ou fluxos de trabalho baseados em modelos expostos pelo servidor MCP. Eles são controlados pelo usuário. As aplicações LLM decidem como expô-los para que o usuário possa selecionar o prompt apropriado.

Transporte

Os transportes definem como um Cliente MCP e um Servidor MCP se comunicam entre si.

STDIO

Nesta configuração, o Cliente MCP dentro do Host MCP é responsável por iniciar o Servidor MCP na mesma máquina. A comunicação entre o Cliente MCP e o Servidor MCP ocorre via STDIN e STDOUT. Neste caso, um Servidor MCP comunica-se apenas com um único cliente MCP.

Uma configuração típica é a seguinte:

Exemplo: Pode executar o Servidor MCP do GitHub localmente usando Docker e um Token de Acesso Pessoal (PAT)

GitHub - github/github-mcp-server: Servidor MCP oficial do GitHub  

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

Autorização

Tipicamente, a autorização pode ocorrer de duas formas

1. Os utilizadores podem usar variáveis de ambiente para passar o seu token para o processo do Servidor MCP. Este é o método amplamente utilizado.
2. O Servidor MCP pode implementar o fluxo de dispositivo OAuth2. No entanto, a especificação oficial do MCP não especifica nada.

Limitações

• O dispositivo do utilizador, executando a aplicação alimentada por LLM, deve instalar Docker ou Node/Python. Embora isso não seja um problema para um desenvolvedor, reduz drasticamente o número de pessoas que podem usar o Servidor MCP.
• Dado que o Servidor MCP está presente e em execução no dispositivo do utilizador, as atualizações tornam-se complicadas e a iteração rápida é afetada.
• Aplicações web executadas no navegador não podem utilizá-lo.
• Sem o fluxo de dispositivo OAuth2, os utilizadores devem configurar os seus tokens para cada Servidor MCP. Os tokens frequentemente não são armazenados de forma segura no dispositivo, e a rotação é complicada.

Dadas as limitações, o transporte STDIO é inadequado para criar Servidores MCP personalizados sobre o serviço e a fonte de dados de uma empresa ou assinaturas SaaS como GitHub ou Slack. No entanto, será útil para casos de uso de ferramentas de desenvolvedor em IDEs.

HTTP Transmissível

O HTTP Transmissível permite que os Servidores MCP lidem com múltiplos clientes MCP que se conectam e comunicam usando o protocolo HTTP. Isso remove muitas das limitações do transporte STDIO. Principalmente:

1. Já não precisamos hospedar o Servidor MCP no dispositivo do utilizador; pode ser hospedado em qualquer lugar.
2. Novas capacidades adicionadas ao servidor MCP tornam-se instantaneamente disponíveis a todos os utilizadores.
3. Aplicativos web executados no navegador podem usar isso.

Autorização

A autorização neste transporte está sendo ativamente desenvolvida. A especificação mais recente, lançada em 26-03-2025, menciona:

1. A implementação de autenticação MCP deve seguir o OAuth 2.1.
2. A implementação de autenticação MCP deve seguir o Registro Dinâmico de Cliente.

Um fluxo de autenticação típico seria algo assim:

No fluxo acima, o Servidor MCP que emite tokens atua como um Recurso e um Servidor de Autorização. Isso é impraticável para Servidores MCP para Slack, GitHub, etc., onde o provedor já implementa seu Servidor de Autorização OAuth2. Os serviços internos de uma empresa, hospedados por trás de Servidores de Autorização fornecidos por IDP, sofrem do mesmo problema (Ex: instalação do ArgoCD por trás de um Servidor de Autorização fornecido pela Okta).

A especificação permite delegar isso a um servidor de autorização de terceiros, mas o Servidor MCP deve emitir seu próprio token e gerenciar o relacionamento com o token de terceiros. Isso anula todos os benefícios de um servidor de autorização de terceiros, já que o Servidor MCP precisa implementar o gerenciamento seguro de tokens e as rotas OAuth2.

Limitação

• Servidores MCP com autenticação exigem infraestrutura como um banco de dados para armazenar e gerenciar com segurança o ciclo de vida de seus tokens. Cada Servidor MCP se tornaria, na prática, seu próprio Servidor de Autorização, o que é redundante e impossível de manter dentro de uma empresa. A comunidade está trabalhando ativamente para alterar a especificação de autorização para melhorar isso.
• Provedores como Atlassian, Sentry, Slack, Github, etc., não suportam o Registro Dinâmico de Cliente (DCR) ou sequer suportam cliente público OAuth2. Construir Servidores MCP sobre esses provedores torna-se mais difícil para a comunidade e mais trabalhoso para o provedor. A Atlassian publicou recentemente seu próprio Servidor MCP, mas sua implementação de DCR permite apenas localhost e algumas URIs de redirecionamento selecionadas, como Claude, etc.

Abordagem da TrueFoundry

Na TrueFoundry, queremos que nossos colegas possam conectar ativamente suas contas Atlassian, Sentry, Slack, GitHub, etc., a LLMs como contexto adicional. Também queremos garantir que cada funcionário possa acessar recursos ou agir sobre eles via LLMs apenas se estiver autorizado. MCP + OAuth2 parece a maneira perfeita de expor isso.

• Queremos focar na criação de servidores MCP de boa qualidade para expor os dados e capacidades de forma mais eficiente a LLMs. Queremos fazer isso de forma segura, aderindo aos limites de RBAC definidos dentro do provedor.
• Não queremos manter Servidores de Autorização adicionais para diferentes Servidores MCP. Queremos reutilizar as capacidades OAuth2 dos provedores.
• Os provedores geralmente suportam apenas clientes confidenciais OAuth2. DCR e clientes públicos nem sequer são uma opção.
• A especificação de Autorização MCP ainda está em constante mudança e desenvolvimento. Não podemos esperar que ela se estabilize antes de trabalhar nisso.

Diante do exposto, propusemos a seguinte arquitetura.

Há alguns componentes aqui.

Servidores MCP

Desenvolvemos Servidores MCP HTTP para provedores como Slack, Sentry, Atlasian, Github, etc., utilizando o transporte HTTP Streamable.

Esses Servidores MCP atuam como proxy entre o LLM e as APIs HTTP do Provedor. Note que esta não é uma tradução 1:1. As APIs HTTP desses provedores contêm muito conteúdo desnecessário que pode facilmente desviar o LLM e preencher a janela de contexto. Por exemplo, uma ferramenta de listagem de pods em um Servidor MCP Kubernetes terá muito conteúdo duplicado, pois a especificação do pod se repete em vários pods. Campos grandes, como managedFields, não serão necessários para a maioria das solicitações dos usuários. Outros provedores SaaS terão entidades pai aninhadas, campos não funcionais, como URL do Avatar, etc. É aqui que queremos dedicar a maior parte do nosso tempo de desenvolvimento. Eventualmente, precisaremos de um sistema no MCP que possa ajudar os LLMs a descobrir o modelo de dados de um sistema e, em seguida, consultar dinamicamente campos específicos de recursos.

Esses servidores MCP esperam um cabeçalho de Autorização HTTP e o repassam diretamente para a API HTTP do Provedor.

Registrando Servidores MCP no TrueFoundry

Após implantar os Servidores MCP, criamos Aplicativos OAuth2 ou clientes confidenciais para cada Provedor. É assim que fica para o Slack.

Acima, você também pode notar que o URI de redirecionamento do autorizador está configurado. Geralmente, ele se parece com https://base-url/mcp-integrations/oauth2/callback.

Em seguida, integramos o Servidor MCP com a URL.

Podemos usar os escopos para tornar toda esta integração somente leitura, se quisermos, ou conceder permissão para tipos de recursos específicos. Mesmo que o servidor MCP tenha ferramentas para “escrever” quaisquer recursos e o usuário tenha acesso de “escrita”, os LLMs não conseguirão obter o mesmo privilégio.

Selecionando o Servidor MCP no Gateway TrueFoundry e Autorizando

Uma vez integrado, podemos selecionar o Servidor MCP no Gateway Playground.

Se o usuário não estiver autorizado, usamos as informações do cliente OAuth2 na integração e conduzimos o usuário pelo fluxo de código de Autorização OAuth2. Ao final do processo, o TrueFoundry salva com segurança os Tokens de Acesso e de Atualização (se suportados e habilitados).

Podemos remover nossas credenciais do TrueFoundry ou até mesmo revogá-las diretamente do Provedor.

Comece a usar!

Uma vez autorizado, você pode usar o contexto dos servidores MCP diretamente em nosso Playground.

Observe que não passamos nenhuma Credencial OAuth2 para o frontend. O frontend chama uma API:

curl -X POST "https://base-url/api/llm/agent/responses" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai-main/gpt-4o-mini",
    "messages": [
      {
        "role": "user",
        "content": "what are the issues in my app"
      }
    ],
    "tools": [
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:sentry",
        "tools": ["list_projects", "list_issues"]
      },
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:slack"
      }
    ]
  }'

‍

O LLM Gateway implementa o loop “agêntico”, enviando as mensagens iniciais e as descrições das ferramentas do Servidor MCP para o LLM. O usuário também pode filtrar as ferramentas expostas ao LLM. Com base na Resposta do LLM, o LLM Gateway pode se comunicar com os Servidores MCP e transmitir as credenciais dos chamadores. Atualizamos automaticamente quaisquer credenciais de curta duração. As atualizações são enviadas para o frontend usando SSE.

Conclusão

Este fluxo MCP + OAuth2 permitiu que nossos colegas incorporassem dados de provedores como Slack, GitHub, Sentry, etc., de forma segura, em seu fluxo de trabalho centrado em LLM.

Alguns casos de uso,

• LLMs podem acessar o Sentry via MCP para buscar detalhes de erros e correlacionar com alterações de código relacionadas do GitHub para depuração mais rápida.
• LLMs criam, atualizam e consultam tickets Jira através do MCP, otimizando os fluxos de trabalho dos desenvolvedores.
• LLMs podem acessar conversas do Slack via MCP para analisar e resumir longas discussões, ajudando as equipes a entender rapidamente decisões e itens de ação sem ler registros de chat inteiros.