Registro MCP e Gateway de IA: Arquitetura e Casos de Uso Empresariais

Entre 2020 e 2023, modelos de fundação como GPT-3 e GPT-4 provaram que grandes modelos de linguagem podem gerar texto semelhante ao humano, escrever código, resumir documentos e responder a perguntas complexas. Mas esses modelos eram sem estado e em sandbox, eles não conseguiam acessar sistemas internos, bancos de dados ou aplicativos — e não tinham como realmente realizar ações no mundo real.

Você poderia perguntar a um modelo:

“Escreva uma consulta MongoDB para listar todas as coleções no banco de dados de conformidade.”

Ele geraria uma saída que parecia uma consulta MongoDB válida — mas:

• Ele não tinha ideia se o banco de dados existia
• Não sabia quais coleções estavam presentes no BD
• Não conseguia determinar se a consulta sequer seria executada
• Não havia como inspecionar esquemas, verificar resultados, ou desencadear ações de acompanhamento como resumir ou notificar outro sistema

Era tudo adivinhação — sem ciclo de feedback.

Para resolver isso, os desenvolvedores começaram a construir camadas em torno dos LLMs:

• Encadeamento de prompts
  
• Wrappers personalizados em Python
  
• Injeção de chamadas de API REST via modelos de string
  
• Preenchimento manual de contexto
  (“usando o seguinte esquema, escreva a consulta”)

Estas eram soluções inteligentes, mas mais difíceis de manter.

Frameworks como LangChain, LlamaIndex, e Semantic Kernel surgiram para organizar esses fluxos de trabalho. Essas ferramentas ajudaram a organizar as coisas, mas os problemas não desapareceram. Os modelos ainda estavam alucinando campos, caindo em injeção de prompt, ignorando a validação e não tinham uma maneira padrão de executar funções reais definidas. Cada novo caso de uso ainda parecia uma reinvenção da roda.

O verdadeiro ponto de viragem veio quando os desenvolvedores perceberam:

“Não precisamos que os modelos adivinhem comandos. Precisamos que eles chamem funções reais — da mesma forma que os aplicativos de frontend chamam as APIs de backend.”

Por volta de meados de 2023, a OpenAI introduziu chamada de função, permitindo que os modelos retornem uma saída estruturada JSON que mapeava diretamente para chamadas de função reais.

Redefiniu o que era possível com a integração de modelos

• LLMs agora podiam interagir com ferramentas usando entradas e saídas claramente definidas
  
• Os modelos comportavam-se como clientes de API, em vez de geradores baseados em suposições
  
• As tarefas agora podiam ser automatizadas com múltiplos passos e interações com o sistema

Com a chamada de função, veio o surgimento de ferramentas e agentes — modelos que podiam encadear ações, seguir fluxos de trabalho e interagir com sistemas reais

Mas…
1. Cada implementação era específica do fornecedor.
2. Não havia nenhum formato padrão  para como as ferramentas eram descritas ou invocadas.

É aqui que MCP (Protocolo de Contexto de Modelo) entra em cena — proposto como um protocolo geral e aberto para comunicação estruturada entre modelos e ferramentas externas. Em vez de codificar APIs de ferramentas diretamente em cada aplicativo LLM, o MCP oferece um carregador universal para conexões de ferramentas de IA  — como OpenAPI, Anthropic etc., mas para LLMs que chamam ferramentas. É baseado em JSON-RPC 2.0, uma especificação amplamente utilizada que suporta chamadas de procedimento remoto (RPCs) usando JSON.

O que o MCP Define

• Como um modelo pode chamar um método de ferramenta (por exemplo, runAggregation)
  
• Como passar parâmetros e obter respostas estruturadas
  
• Como as ferramentas descrevem seus métodos disponíveis (via esquemas ou manifestos)
  
• Um padrão leve para integração de ferramentas em qualquer backend (BD, CLI, API de nuvem)

Pense no MCP como o contrato de API entre um modelo e uma ferramenta. Sem um protocolo padrão, cada integração exigia engenharia personalizada — cara, propensa a erros e repetitiva. O MCP resolveu isso criando uma linguagem universal, simplificando as integrações de ferramentas de uma vez por todas. Mas o que exatamente é o MCP e como ele funciona na prática? Vamos nos aprofundar.

Protocolo de Contexto de Modelo

‍MCP (Protocolo de Contexto de Modelo) é um protocolo leve construído especificamente para comunicação estruturada entre modelos de IA e ferramentas externas.

Em sua essência, o MCP utiliza JSON-RPC 2.0, um protocolo testado em batalha para chamar procedimentos remotos com entradas e saídas estruturadas — perfeito para transformar a saída de LLMs em invocações de ferramentas do mundo real.

Então por que inventar outro protocolo?

Opções existentes como REST ou GraphQL são ou muito genéricas, muito prolixas, ou simplesmente muito frágeis para fluxos de trabalho focados em IA. O MCP preenche essa lacuna ao fornecer uma estrutura clara, sobrecarga mínima e um foco explícito em fluxos de trabalho centrados em IA. Não se destina a substituir suas APIs — destina-se a permitir que os modelos as utilizem de forma segura, repetível e previsível.

• Aplicativo Host: Orquestra chamadas de ferramentas, lida com a saída do LLM, encadeia respostas — por exemplo, um Agente GRC que consulta o Mongo, resume os resultados e envia alertas.
• Servidor MCP: Implementa lógica específica do domínio como listCollections, runAggregation ou sendMessageToSlack.
• Cliente MCP: Uma biblioteca mínima que lida com a formatação de requisições, autenticação, novas tentativas e conecta o Host ao Servidor MCP apropriado.

Servidores geralmente expõem:

• Ferramentas: Comandos executáveis como listCollections, runAggregation ou sendSlackMessage.
• Recursos: Dados descritivos como definições de esquema, metadados de coleção ou estrutura de banco de dados.

Opcionalmente, os servidores também podem expor:

• Prompts: Prompts/modelos padronizados de agente
• Primitivos do lado do cliente: Dicas de cache ou agrupamento
• Notificações: Fluxos de eventos em tempo real (via SSE)

Opções de Transporte: STDIO vs HTTP/SSE

O MCP é agnóstico ao transporte e suporta dois modos:

Ambos os transportes seguem o mesmo formato JSON-RPC, então você pode alternar entre eles sem reescrever a lógica.

Essa é a grande ideia por trás do MCP — uma maneira mínima e limpa para os modelos chamarem ferramentas sem a cola frágil dos prompts. Sem comandos alucinados. Sem preenchimento manual de contexto. Apenas entradas e saídas claras. Mas como isso realmente funciona em um aplicativo real? Vamos analisar um exemplo com um assistente de conformidade alimentado por MongoDB.

Automatizando um Fluxo de Trabalho GRC Usando Mongo-MCP

Imagine que você está construindo um assistente de GRC (Governança, Risco e Conformidade).

Este assistente precisa:

• Buscar coleções e logs de auditoria de um banco de dados MongoDB
• Resumir as descobertas para um oficial de conformidade
• Notificar as equipes relevantes no Slack
• Opcionalmente, registrar um problema de acompanhamento no GitHub

Em uma configuração tradicional, você codificaria essa lógica usando chamadas REST ou scripts Python, inserindo esquemas e credenciais em modelos de prompt. Cada integração seria personalizada — e frágil.

Com o MCP, cada uma dessas ferramentas — MongoDB, Slack, GitHub — torna-se um provedor de funções de primeira classe, expondo métodos claramente definidos como:

• listCollections
• runAggregation
• sendMessage
• criarIssue

O Agente GRC (nosso Aplicativo Host) simplesmente chama essas ferramentas usando o esquema JSON-RPC do MCP

Cenário: Detectar e Relatar Violações de Política Instrução do usuário:  “Verifique o banco de dados de conformidade para quaisquer violações de política hoje e notifique a equipe no Slack.”

1. Entrada do Usuário → Aplicativo Host → LLM O Agente GRC (Aplicativo Host) envia a mensagem do usuário para o modelo. O modelo é ciente das ferramentas e responde com:

{
  "tool_calls": [
    {
      "name": "listCollections",
      "arguments": {
        "database": "compliance"
      }
    }
  ]
}

2. O Aplicativo Host Invoca o Mongo-MCP via Cliente MCP Esta chamada de ferramenta é convertida em uma solicitação JSON-RPC:

{
  "jsonrpc": "2.0",
  "method": "listCollections",
  "params": {
    "database": "compliance"
  },
  "id": "req-001"
}

3. O Mongo-MCP Executa a Função O Mongo-MCP mapeia esta chamada para:

def listCollections(database: str) -> List[str]:
    return mongo_client[database].list_collection_names()

Ele executa a função, obtém o resultado e responde:

{
  "jsonrpc": "2.0",
  "result": [
    "audit_logs",
    "policy_violations",
    "user_sessions"
  ],
  "id": "req-001"
}

4.  O Agente Encadeia a Próxima Chamada: runAggregation O modelo agora gera uma chamada de acompanhamento com base nas coleções disponíveis:

{
  "tool_calls": [
    {
      "name": "runAggregation",
      "arguments": {
        "database": "compliance",
        "collection": "policy_violations",
        "pipeline": [
          { "$match": { "timestamp": { "$gte": "2025-08-05" } } },
          { "$group": { "_id": "$severity", "count": { "$sum": 1 } } }
        ]
      }
    }
  ]
}

Isso resulta em outra chamada JSON-RPC para o Mongo-MCP, e o servidor retorna:

{
  "jsonrpc": "2.0",
  "result": [
    { "_id": "high", "count": 5 },
    { "_id": "medium", "count": 12 }
  ],
  "id": "req-002"
}

O agente passa este resultado de volta para o modelo com um prompt como:

“Resuma estes dados de violação de política em linguagem simples.”

O modelo responde:

“THoje, houve 5 violações de política de alta gravidade e 12 de média gravidade no banco de dados de conformidade.”

5. O Modelo Chama o Slack-MCP para Notificar a Equipe Agora o agente faz uma chamada de ferramenta estruturada final:

{
  "tool_calls": [
    {
      "name": "sendMessage",
      "arguments": {
        "channel": "#compliance-alerts",
        "message": "5 high and 12 medium policy violations detected today. Please review."
      }
    }
  ]
}

O servidor Slack-MCP envia a mensagem, e o fluxo de trabalho é concluído. Tudo isso aconteceu através de chamadas JSON estruturadas, não manipulação de strings ou engenharia de prompts.

Governing Enterprise AI at Scale: The MCP Gateway Blueprint

$2 Million

The

Wake-Up Call

Your integration architecture determines whether AI becomes a competitive advantage or unmanageable risk.

A Fortune 500 Spent $2M Fixing Ungoverned AI

Don't let this be you, get the complete Al governance blueprint.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Por que você precisa de um Registro de Servidor MCP no Gateway MCP?

A demonstração do Mongo-MCP parece limpa. O modelo fez chamadas de ferramentas estruturadas. Cada função funcionou como esperado. Sem alucinações. Sem modelos de string frágeis. Mas esse é um cenário ideal — e sistemas reais não são apenas sobre funcionar… são sobre funcionar com segurança, confiabilidade e observabilidade em escala.

Em produção, o MCP puro fica aquém em algumas áreas-chave:

1. Sem Controle de Acesso (RBAC) O MCP puro não tem uma forma integrada de restringir quem pode chamar o quê.

• E se você quiser permitir a execução de Aggregation, mas bloquear deleteCollection?
• E se um modelo só puder consultar certos conjuntos de dados (por exemplo, finanças não pode acessar RH)?

Em organizações reais, o RBAC (controle de acesso baseado em função) é inegociável — especialmente quando os modelos estão conectados a ferramentas sensíveis.

2. Sem Autenticação ou Chaves de API O MCP puro não lida com

• Validar qual agente ou modelo está fazendo a chamada
• Definir o escopo das credenciais por equipe, ambiente ou projeto
• Expiração ou revogação de tokens

Isso significa que qualquer pessoa com acesso ao servidor mcp pode chamar qualquer ferramenta — e não há trilha de auditoria.

3. Sem Observabilidade Você não pode consertar o que não pode ver.

• Qual é a latência de cada chamada de ferramenta?
• Qual é a taxa de falha ou a contagem de tentativas?
• Quais ferramentas estão sendo usadas em excesso ou estão a esgotar o tempo limite?

Com o MCP bruto, você não tem painéis, logs ou rastreamentos. Você está voando às cegas.

4. Sem Guardrails LLMs são criativos — às vezes, criativos demais.

O MCP bruto tem:

• Sem limites de token (por exemplo, para evitar agregações massivas)
• Sem limites de tamanho de resultado (por exemplo, retornar 5MB do Mongo)
• Sem disjuntores ou prompts de pausa (por exemplo, “Tem certeza de que deseja enviar este alerta do Slack?”)

Sem guardrails, um bug de prompt pode levar a milhares de mensagens do Slack ou a exclusões acidentais de dados.

5. Sem Retentativa, Limitação ou Cotas Em produção

Em produção, as ferramentas nem sempre se comportam perfeitamente — elas podem falhar, esgotar o tempo limite ou responder lentamente. Sem salvaguardas, mesmo modelos bem-comportados podem:

• Atingir limites de taxa
  
• Bombardear serviços com retentativas
  
• Expor ferramentas sensíveis ao uso indevido
  

O protocolo MCP bruto assume que tudo simplesmente funciona — um mundo de “caminho feliz”. Mas a infraestrutura do mundo real é complicada. Você precisa de lógica de retentativa inteligente, cache, limitação de taxa e controle de acesso para manter a sanidade em escala.

• Autenticação + acesso baseado em token
• RBAC por modelo, usuário, organização e ferramenta
• Observabilidade e rastreamento
• Cotas, limites e estratégias de repetição
• Fluxos de trabalho de aprovação para ações sensíveis

É exatamente isso que o Gateway TrueFoundry oferece.

De Demos em Servidor Único a Fluxos de Trabalho de Agentes de Nível Empresarial

No primeira metade deste artigo, aprendemos o que é o Protocolo Modelo-Contexto e usamos um servidor mcp Mongo para automatizar uma plataforma GRC legada. Esse exemplo simples é ótimo para um hackathon, mas rapidamente esbarra em problemas do mundo real:

O TrueFoundry Gateway de IA empacota a infraestrutura que faltava — um registro MCP, autenticação central, RBAC, guard-rails e observabilidade rica — para que as equipes possam passar de “agente hello-world” para produção com segurança e de forma repetível.

O que o Gateway Adiciona Além do MCP Puro

A TrueFoundry posiciona um dos melhores gateways MCP como um plano de controle que se posiciona entre seus agentes (ou interface de chat) e cada servidor MCP e provedor de LLM registrados.

Principais recursos incluem:

1. Registro MCP Central – adicione servidores públicos ou auto-hospedados uma vez; descubra-os em qualquer lugar 
2. Credenciais unificadas – gere um único Token de Acesso Pessoal (PAT) ou Token de Conta Virtual (VAT) com escopo de máquina que é automaticamente trocado por tokens OAuth / de cabeçalho por servidor nos bastidores 
3. RBAC granular – restrinja quais usuários, aplicativos ou ambientes podem ver ou executar quais ferramentas 
4. Playground de Agentes & cliente MCP integrado – prototipagem rápida sem escrever uma linha de código 
5. Observabilidade & guard-rails – latência, custo, rastreamentos, fluxos de aprovação, limites de taxa e cache incorporados 

Pense nisso como o gateway de API + malha de serviço + armazenamento de segredos para o ambiente MCP emergente. “Conforme observado no guia de autenticação do servidor MCP, o Gateway lida automaticamente com o armazenamento de credenciais e o ciclo de vida dos tokens.”

Mãos à Obra: Registrando Seu Primeiro Servidor MCP

O primeiro passo na interface do usuário é criar um grupo—por exemplo, dev-mcps ou prod-mcps. Os grupos permitem anexar diferentes regras RBAC e fluxos de aprovação a diferentes ambientes.

“Você pode seguir o guia de introdução do servidor MCP TrueFoundry para obter passos detalhados.”

Gateway de IA ➜ Servidores MCP ➜ “Adicionar Novo Grupo de Servidores MCP

name: prod-mcps
   access control:
       - Manage: SRE-Admins
       - User  : Prod-Runtime-Service-Accounts

Dentro do grupo, escolha Adicionar/Editar Servidor MCP e preencha três itens: 

Você pode adicionar com a mesma facilidade:

• Sem Autenticação servidores de demonstração (por exemplo, Calculadora)
• Autenticação por Cabeçalho servidores que aceitam uma chave de API estática (por exemplo, Hugging Face) 
• Qualquer número de servidores futuros (Atlassian, Datadog, microsserviços internos)

Nos bastidores, o Gateway armazena credenciais em seu repositório secreto e lida com a atualização de tokens.

Autenticação e RBAC

TrueFoundry suporta três esquemas de autenticação por servidor MCP:

“Esses modos são descritos em mais detalhes na documentação de Autenticação do Servidor MCP.”

Uma vez que um servidor é registrado, você não entrega tokens brutos a cada desenvolvedor. Em vez disso, eles se autenticam uma vez no Gateway e recebem:

• PAT – com escopo de usuário, amigável, bom para CLI / experimentos
• VAT – com escopo de conta de serviço, bloqueado para servidores selecionados, perfeito para aplicativos de produção 

The Gateway checks the calling token against:

1. Group-level permissions (can this user reach any server in prod-mcps?)
2. Server-level permissions (is slack-mcp whitelisted?)
3. Tool-level permissions (can they call sendMessageToChannel?)

If any check fails the request is rejected before it hits your Slack workspace.

From Playground to Code: The Agent API

After experimenting in the UI you can click “API Code Snippet” to generate working Python, JS, or cURL examples .Below is a trimmed JSON body that wires three servers together (GitHub, Slack, Calculator):

POST/api/llm/agent/responses

{
  "model": "gpt-4o",
  "stream": true,
  "iteration_limit": 5,
  "messages": [
    {
      "role": "user",
      "content": "Summarize open PRs on repo X and DM me the top blockers."
    }
  ],
  "mcp_servers": [
    {
      "integration_fqn": "truefoundry:prod-mcps:github-mcp",
      "tools": [ {"name": "listPullRequests"}, {"name": "createComment"} ]
    },
    {
      "integration_fqn": "truefoundry:prod-mcps:slack-mcp",
      "tools": [ {"name": "sendMessageToUser"} ]
    },
    {
      "integration_fqn": "truefoundry:common:calculator-mcp",
      "tools": [ {"name": "add"} ]
    }
  ]
}

“You can find a similar example in the Use MCP Server in Code Agent guide, which also includes complete Python and JS snippets.”

The streaming response interleaves:

1. assistant tokens (LLM reasoning)
2. tool-call chunks (function name + incremental arguments)
3. tool-result events (JSON output) 

This lets you build reactive UIs that show each step of the agentic loop in real time.

Observability, Guardrails & Policy

Even a “hello world” agent can cost real money and do real damage. TrueFoundry ships first-class observability:

• Latency / error dashboards – TTFT, task latency, HTTP errors, tool retries 
• Token & cost tracking – attribute spend per model, per team, per feature flag 
• OpenTelemetry traces – hop-by-hop spans across agent, MCP proxy, and LLM 
• Rate-limits & caching – prevent runaway loops and reuse identical web-search results
• Guard-rail hooks – enforce PII-scrubbing, NSFW filters, or “human-in-the-loop approval” on any destructive tool 

All metrics come out of the box; no side-car agents or custom exporters required.

Supporting All MCP Transports (HTTP & STDIO)

Many open-source servers still speak stdio (stdin/stdout) instead of HTTP. TrueFoundry recommends wrapping them with mcp-proxy and deploying as a regular service 

# wrap a Python stdio server
mcp-proxy --port 8000 --host 0.0.0.0 --server stream python my_server.py

Ready-made templates exist for Notion and Perplexity servers, plus K8s manifests for Node or Python images. Once proxied, registration is identical to any other HTTP MCP endpoint.

“TrueFoundry’s MCP Server STDIO guide covers this proxying approach and provides deployment templates.”

Example Walk-Through: Enterprise Compliance Bot

Let’s return to our legacy GRC scenario but crank the ambition up:

“Keep our compliance evidence up-to-date. If a policy file changes in GitHub, store the diff in MongodB, create a Jira ticket, and post a summary in Slack.”

Servers Involved

Flow

1. GitHub webhook hits a cloud function.
2. The function calls the Agent API (VAT token) with the four servers enabled.
3. LLM reasons → calls github.getFileDiff → mongo.insertDocument → jira.createIssue → slack.sendMessage.
4. Each tool call and result is streamed back; observability captures latency of every hop.
5. If the diff is > x (certain number of lines of code, as threshold), a guard-rail inserts “requires manual approval” and pauses execution; a security lead can approve via the Gateway UI.

Governance

• The VAT attached to the function only sees the four listed servers—least privilege.
• Separate dev and prod groups let you test against a sandbox Jira and staging Slack.
• Auditors can replay any incident: traces + full JSON payloads are retained 30 days by default.

Extending the Ecosystem: Building Your Own MCP Server

Because MCP is just JSON-RPC over HTTP or stdio, any internal service can expose tools, here is a small example : 

• Drop this container into your Kubernetes cluster.
• Register it in the dev group with No-Auth while developing.
• Change to Header-Auth ou OAuth2 antes de o mover para prod-mcps.

A partir desse momento, cada agente na sua empresa pode analisar os controlos de conformidade com exatamente a mesma ergonomia que o Slack ou o GitHub.

Guia Rápido de Melhores Práticas

“Esta folha foi adaptada do Visão Geral do MCP da TrueFoundry, estas diretrizes ajudam a garantir implementações seguras e fiáveis.”

Conclusão 

O MCP permite que os grandes modelos de linguagem (LLMs) falem a mesma língua que as ferramentas — mas não lida com aspetos como segurança, descoberta ou governação a nível empresarial. É aqui que entra o AI Gateway da TrueFoundry: ele adiciona tudo o que as equipas precisam de imediato — como um completo registo MCP, autenticação integrada, controlo de acesso baseado em funções (RBAC), observabilidade profunda e uma poderosa API de Agente para ligar tudo.

Perguntas Frequentes

O que é um registo MCP em sistemas de IA?

Um registo MCP é um catálogo centralizado que armazena e gere servidores do Protocolo de Contexto de Modelo (MCP) disponíveis e as suas capacidades específicas. Atua como um diretório pesquisável para agentes de IA, permitindo-lhes descobrir dinamicamente ferramentas e recursos. Este registo garante que os modelos podem identificar os serviços corretos necessários para executar tarefas complexas e de várias etapas.

Qual é a diferença entre um registo MCP e um gateway de IA?

Um registo MCP é um diretório passivo de ferramentas, enquanto um gateway de IA é a camada de aplicação ativa que gere o tráfego. O registo informa o sistema sobre os recursos existentes, enquanto o gateway controla o acesso, lida com a autenticação e aplica políticas de segurança como mascaramento de PII ou limitação de taxa durante a execução real dos pedidos do modelo.

Um gateway de IA pode funcionar sem um registo MCP?

Sim, um gateway de IA pode funcionar sem um registro MCP usando configurações estáticas, mas perde a flexibilidade da descoberta dinâmica de ferramentas. Sem um registro, os desenvolvedores precisam codificar manualmente cada conexão de servidor, tornando o sistema difícil de escalar e manter. A integração de um registro permite que o gateway se adapte automaticamente à medida que novas ferramentas são adicionadas ao ecossistema.

Como um gateway de IA aplica políticas de um registro MCP?

O gateway de IA recupera metadados e regras de governança do registro MCP para validar solicitações de entrada em tempo real. Ele faz referência cruzada às permissões de usuário e aos requisitos de segurança definidos no registro antes de rotear o tráfego para o servidor apropriado. Isso garante que cada interação permaneça em conformidade com os padrões organizacionais e os protocolos de residência de dados.