Arquitetura e Princípios de Funcionamento do Servidor MCP: Do Protocolo ao Fluxo de Execução

À medida que os sistemas de IA evoluem, tornam-se cada vez mais complexos. Paradigmas tradicionais de chamada de API (como requisições HTTP independentes e SDKs específicos do provedor) enfrentam desafios como baixa eficiência de desenvolvimento, altos riscos de segurança e baixa manutenibilidade ao construir sistemas sofisticados de Agentes de IA. Por exemplo, definições de API independentes carecem de um padrão unificado; diferentes modelos fornecem especificações de chamada de função variadas; e há uma falta de mecanismos eficientes de descoberta de capacidade e integração dinâmica.

O Model Context Protocol (MCP) surgiu para resolver esses problemas. Através da padronização no nível do protocolo, ele introduz um mecanismo extensível de chamada de ferramentas e recursos entre serviços, permitindo que os agentes de IA colaborem de forma robusta com sistemas externos. A filosofia central de design do MCP reside na abstração de protocolo e na separação de preocupações. Ele não dita implementações específicas, mas define uma linguagem universal para a interação entre aplicações de IA e capacidades externas.

Este artigo fornece uma explicação autorizada da arquitetura do Servidor MCP, princípios do protocolo e fluxo de execução, destacando por que uma camada de protocolo é preferida a um SDK e como o MCP suporta a chamada de ferramentas escalável exigida pelos sistemas inteligentes modernos.

Público-alvo:

• Entusiastas de tecnologia e aprendizes iniciantes
• Profissionais e gerentes que buscam melhorias de eficiência
• Tomadores de decisão empresariais e chefes de departamento de negócios
• Usuários em geral interessados nas tendências futuras da IA

Conteúdo:

• 1. Filosofia de Design Central do Protocolo MCP
• 2. Componentes Centrais do MCP
• 3. MCP vs. Integração Tradicional de API: Paradigmas Arquitetônicos
• 4. Como os Servidores MCP Colaboram com os Agentes de IA
• 5. Os Três Primitivos de Capacidade Centrais do MCP
• 6. Relação de Comunicação: Cliente MCP, Servidor e LLM
• 7. Processo Completo de Chamada do Servidor MCP
• 8. MCP vs. Chamada de API Tradicional / de Função: Diferenças na Camada de Interface do Modelo
• 9. Limitações e Desafios do MCP
• Conclusão
• Perguntas Frequentes (FAQ) sobre MCP

1. Filosofia de Design Central do Protocolo MCP

O MCP escolhe a abstração da camada de protocolo, oferecendo vantagens centrais como padronização, independência de linguagem e forte universalidade, em vez de fornecer um SDK unificado. Isso significa que qualquer programa que implemente a especificação do protocolo MCP – independentemente da linguagem de programação ou framework usado – pode se comunicar com outros. Este design maximiza a abertura ecológica e a interoperabilidade. A comunicação é baseada em JSON-RPC 2.0, um protocolo leve de chamada de procedimento remoto cujos formatos estruturados de requisição e resposta são ideais para interação automatizada máquina-a-máquina.

Formato da Mensagem de Comunicação

O MCP utiliza JSON-RPC 2.0 como seu formato de mensagem fundamental e padrão de comunicação.

JSON-RPC é um protocolo de chamada de procedimento remoto (RPC) sem estado e leve. Ele usa JSON como seu formato de dados e pode ser transportado por diferentes camadas de transporte, como STDIO ou HTTP.

No MCP, o JSON-RPC é responsável por:

• Definir estruturas de mensagens de requisição/resposta;
• Padronizar chamadas de método (por exemplo, initialize, tools/list, tools/call);
• Fornecer mecanismos extensíveis de tratamento de erros e processamento em lote.

Modelo de Arquitetura de Três Camadas

O MCP adota um modelo de arquitetura de três camadas: Cliente MCP, Servidor MCP e Recurso/Ferramenta.

• Hosts MCP: A aplicação LLM que inicia a requisição (por exemplo, Claude Desktop, um IDE ou uma ferramenta de IA).
• Clientes MCP: Localizados dentro do programa host, mantendo uma conexão 1:1 com o servidor MCP.
• Servidores MCP: Fornecem contexto, ferramentas e informações de prompt ao cliente MCP.

Este design em camadas reduz significativamente o acoplamento entre os módulos e aumenta a escalabilidade do Servidor MCP.

2. Componentes Centrais do MCP

Camada de Transporte O transporte padrão do MCP inclui STDIO e HTTP + Server-Sent Events (SSE), onde o SSE fornece capacidades de streaming de mensagens do servidor para o cliente. Atualmente, o MCP define dois mecanismos de transporte padrão para comunicação cliente-servidor:

• STDIO: Segurança e Desempenho em Primeiro Lugar. O Servidor MCP inicia como um processo filho e executa localmente com a aplicação de IA. Ele usa comunicação interprocessos local (IPC), oferecendo baixa latência e implantação simples. Como toda a comunicação permanece local, evita riscos de rede para credenciais e dados. Este é o método preferencial para integrar capacidades locais em ferramentas de produtividade pessoal como o Claude Desktop.
• HTTP with Server-Sent Events (SSE): Acessibilidade e Escalabilidade em Primeiro Lugar. O Servidor MCP é implantado como um serviço de rede acessível por múltiplos clientes remotos. Ele usa HTTP/POST combinado com JSON-RPC para transmissão de mensagens. Isso é adequado para hubs de capacidade compartilhada dentro de empresas ou serviços SaaS. HTTPS e autenticação HTTP padrão fornecem a base de segurança.

Este mecanismo permite que o MCP suporte tanto chamadas de ferramentas simples quanto servidores distribuídos em larga escala. A escolha depende do cenário: STDIO é mais eficiente para comunicação de processo local, enquanto HTTP oferece melhor escalabilidade para implantações de cluster remoto.

Camada de Protocolo

Na camada de protocolo, o MCP usa a especificação JSON-RPC 2.0 para definir métodos padrão, como:

• Inicialização de conexões (initialize);
• Descoberta de capacidade (tools/list);
• Execução de ferramentas (tools/call).

Este design variante mantém a estrutura central do protocolo JSON-RPC, ao mesmo tempo que introduz semânticas de comunicação específicas do MCP. Ferramentas JSON-RPC

Segurança e Autenticação

O MCP não fornece mecanismos de segurança diretamente. O design de segurança depende da implementação específica do Servidor MCP utilizando soluções estabelecidas, como:

• Transmissão criptografada HTTPS/TLS;
• Autenticação via OAuth2, API Keys ou mTLS;
• Controle de autorização de privilégio mínimo.

Isso significa que o protocolo MCP em si não contém especificações de segurança; em vez disso, os implementadores do servidor são responsáveis por projetar e integrar sistemas de segurança de terceiros. Por exemplo, plataformas empresariais podem integrar o MCP com sistemas de gerenciamento de identidade para controle de acesso seguro, governança e auditoria.

Extensibilidade e Arquitetura de Plugin

A extensibilidade do MCP decorre naturalmente do seu design de protocolo. Desenvolver uma "ferramenta personalizada" envolve a criação de um programa servidor que implementa o protocolo MCP. Quando este servidor inicia e se conecta à aplicação de IA (Cliente MCP), ele registra dinamicamente suas ferramentas através do método padrão tools/list. A aplicação de IA descobre e usa essas novas capacidades sem pré-configuração ou recompilação, alcançando verdadeira funcionalidade plug-and-play.

Os Servidores MCP geralmente incluem mecanismos para:

• Desenvolvimento de ferramentas personalizadas;
• Registro/descoberta dinâmica de ferramentas e capacidades;
• Suporte a plugins para estender o comportamento sem modificar o núcleo do protocolo.

Ciclo de Vida da Ferramenta e Gerenciamento de Sessão

O ciclo de vida de uma conexão MCP começa com o handshake initialize e termina quando a conexão é fechada. Durante este período, todas as chamadas de ferramentas e leituras de recursos compartilham uma sessão lógica. Para Servidores MCP que precisam atender múltiplos usuários ou sessões (especialmente no modo HTTP), a implementação deve gerenciar o isolamento de estado entre diferentes clientes ou requisições.

O Servidor MCP gerencia:

• Contexto da sessão: Salvando o estado entre múltiplas chamadas;
• Mecanismos de isolamento: Garantindo que as sessões entre diferentes clientes sejam isoladas para prevenir vazamento de dados ou poluição de estado.

Este gerenciamento suporta casos de uso avançados, como sessões longas e operações multi-passo.

Design de Desempenho e Confiabilidade do Sistema

Como um protocolo leve, o desempenho do MCP depende fortemente da eficiência da implementação do servidor e da latência da rede. Para requisitos de alta disponibilidade, múltiplas instâncias do Servidor MCP podem ser implantadas atrás de um balanceador de carga. O protocolo define uma interface de logging, permitindo que os servidores enviem logs de execução para o cliente, o que forma a base para auditoria.

Os designs de Servidores MCP frequentemente incluem:

• Balanceamento de carga para implantação de múltiplas réplicas;
• Recuperação de falhas para garantir alta disponibilidade;
• Registro e auditoria (Logging and Auditing) para rastreamento do histórico de chamadas e diagnóstico.

Esses mecanismos aumentam a estabilidade para casos de uso de nível empresarial.

Integração com Ecossistemas Modernos

Para se adaptar a ambientes cloud-native, os Servidores MCP frequentemente colaboram com Kubernetes e balanceadores de carga de nuvem para auto-escalonamento e implantação elástica. Os Servidores MCP podem ser containerizados e implantados em plataformas como Kubernetes, permitindo verificações de saúde e gerenciamento centralizado dentro de pilhas de infraestrutura empresarial modernas.

3. MCP vs. Integração Tradicional de API: Paradigmas Arquitetônicos

Comparado à integração de API independente, o MCP utiliza a abstração de protocolo para melhorar a segurança, manutenibilidade e capacidades multiplataforma.

4. Como os Servidores MCP Colaboram com os Agentes de IA

Em uma arquitetura típica de Agente de IA baseada em planejamento, os componentes incluem um Planner, Executor e Memória. O Servidor MCP atua como o backend de execução padronizado nesta arquitetura.

• Planner: (Geralmente a LLM) formula estratégias baseadas na entrada. Ele recupera a lista atual de Ferramentas disponíveis e suas descrições do Cliente MCP. O Planner então descreve uma sequência de passos (por exemplo, "Use a ferramenta A para consultar dados, então a ferramenta B para processar os resultados").
• Executor: (Geralmente o Cliente MCP) emite requisições tools/call para o Servidor MCP correspondente com base no plano.
• Memória: Armazena estado e contexto. Os resultados da execução são retornados ao Agente, armazenados na Memória e usados para planejamento subsequente. Além disso, Recursos podem fornecer proativamente conhecimento de fundo relevante para a tarefa.

O Servidor MCP atua como o provedor de capacidade para o Executor, permitindo que o Planner acesse ferramentas e recursos via um protocolo padrão.

A posição do MCP em uma arquitetura de Agente de IA é semelhante à interface de um sistema operacional para serviços externos, unificando e padronizando a execução de capacidades.

O MCP é complementar a frameworks como LangChain e AutoGen. Enquanto esses frameworks fornecem abstração e orquestração de alto nível para fluxos de trabalho de Agentes de IA, o MCP serve como a camada de execução de ferramentas padronizada. Ele resolve os problemas de "código cola" e fragmentação que esses frameworks enfrentam ao integrar ferramentas específicas.

5. Os Três Primitivos de Capacidade Centrais do MCP

Esses primitivos definem o modelo de dados do protocolo MCP e como as aplicações de IA interagem com o servidor.

• Ferramentas: Funções chamáveis como operações de busca ou banco de dados. Cada ferramenta tem um nome claro, descrição e um JSON Schema de parâmetros de entrada. O modelo de IA as aciona quando necessário (por exemplo, uma ferramenta send_email).
• Recursos: Fontes de dados acessíveis, como sistemas de arquivos ou armazenamento de objetos. Cada recurso tem um URI e tipo MIME. As aplicações de IA leem esses conteúdos para injetar contexto em prompts (por exemplo, um recurso file:///reports/weekly.md).
• Prompts: Modelos ou contextos predefinidos usados para auxiliar na tomada de decisões da LLM. Estes fornecem uma maneira estruturada para os usuários iniciarem tarefas específicas (por exemplo, um prompt "Planejar Viagem de Fim de Semana" que guia o modelo a usar ferramentas relevantes).

Este design de três camadas permite que o Servidor MCP expresse claramente suas funções executáveis, ao mesmo tempo que suporta a descoberta dinâmica. Além disso, o protocolo permite que os servidores solicitem a geração de modelo (LLM sampling) do cliente. Isso permite que o servidor use a LLM do cliente para raciocínio durante sua própria lógica de execução. Os clientes devem declarar essa capacidade durante a inicialização para suportá-la.

6. Relação de Comunicação: Cliente MCP, Servidor e LLM

Compreender a relação entre esses três é fundamental para entender o fluxo de trabalho do MCP:

• Quem inicia a conexão? O Cliente MCP (integrado na aplicação de IA) inicia ativamente a conexão com o Servidor MCP.
• Quem decide chamar uma ferramenta? A LLM (dentro da aplicação de IA) toma decisões com base na lógica interna. O Cliente MCP fornece a lista de ferramentas disponíveis como contexto, e a LLM decide se deve chamar uma ferramenta, qual e com quais parâmetros.
• Quem executa a operação? O Servidor MCP chama o serviço ou recurso real. Ele recebe a requisição padronizada tools/call do cliente, traduz-a em ações para o sistema subjacente (banco de dados, API, arquivo) e retorna o resultado padronizado.

7. Processo Completo de Chamada do Servidor MCP

Um fluxo de trabalho típico inclui:

1. Inicialização: Cliente e Servidor estabelecem uma conexão e trocam versões de protocolo e capacidades.
2. Descoberta de Capacidade: O Cliente recupera a lista de Ferramentas e Recursos do Servidor via tools/list.
3. Chamada de Ferramenta: Após a LLM tomar uma decisão, o Cliente emite uma requisição tools/call. O Servidor executa a operação real.
4. Injeção de Resultados: O Servidor retorna resultados estruturados, que o Cliente fornece de volta à LLM para geração da resposta final ou planejamento posterior.

Diagrama de tempo típico para um protocolo de chamada:

Abaixo está um diagrama de tempo simplificado para um caso de reserva de sala de conferências, mostrando a interação do protocolo central desde a inicialização até a execução:

8. MCP vs. Chamada de API Tradicional / de Função: Diferenças na Camada de Interface do Modelo

A integração tradicional de API depende de especificações e SDKs definidos pelo fornecedor. O MCP abstrai o comportamento de chamada em métodos JSON-RPC, mantendo uma interface padrão que é independente de SDKs específicos.

• Chamada de Função Tradicional Esta é uma capacidade fornecida por fornecedores de modelos específicos. Os desenvolvedores definem funções no formato do fornecedor, e o modelo aprende a gerar requisições nesse formato. É restrita à interface proprietária do fornecedor.
• Arquitetura MCP O MCP é um protocolo aberto agnóstico ao modelo. Ele define formatos universais e padronizados para descrição e chamada de capacidades. Qualquer aplicação de IA que suporte o MCP (independentemente do modelo subjacente) pode interagir com qualquer Servidor MCP. Ele liberta a integração de ferramentas do "vendor lock-in" (aprisionamento de fornecedor) do modelo.

O MCP é mais adequado para manutenção a longo prazo e construção de ecossistemas em ambientes de grande escala e multi-modelo.

Limites do Caso de Uso: Se você usa um único modelo com requisitos de ferramenta simples e fixos, a Chamada de Função pode ser suficiente. Se você está construindo um sistema de Agente complexo envolvendo múltiplos modelos e ferramentas que exigem escalabilidade a longo prazo, a padronização e o desacoplamento fornecidos pelo MCP são essenciais.

9. Limitações e Desafios do MCP

Embora o Servidor MCP forneça uma maneira padronizada para os Agentes de IA interagirem com as ferramentas, ele não é uma "solução mágica". É crucial entender o que o MCP não resolve e os desafios em ambientes de engenharia reais.

1. Conflito de Capacidades e Governança com Múltiplos Servidores MCP

Em sistemas complexos, múltiplos Servidores MCP são frequentemente conectados. Diferentes servidores podem expor ferramentas com semânticas semelhantes ou funções sobrepostas. O protocolo MCP lida com especificações de declaração e chamada, mas não inclui:

• Classificação de prioridade de ferramentas
• Detecção ou resolução de conflitos
• Estratégia para seleção ótima de ferramentas baseada no contexto

Isso significa: A responsabilidade pela tomada de decisões recai inteiramente sobre a camada do Cliente MCP ou do Agente de IA. O Planner ou módulo de estratégia deve implementar sua própria lógica de seleção de ferramentas. Portanto, o MCP é uma "camada de exposição e comunicação de capacidades", não um "sistema de agendamento inteligente".

2. Pressão de Contexto de Chamadas de Longo Prazo e Múltiplas Rodadas

Em cenários de Agente, as tarefas envolvem múltiplos passos:

• Planejamento
• Múltiplas chamadas de ferramentas (tools/call)
• Injeção de resultados
• Re-raciocínio e tomada de decisões

Este processo anexa continuamente informações à janela de contexto da LLM. É importante notar:

• O MCP não é responsável por poda, compressão ou sumarização de contexto.
• Ele não possui gerenciamento de memória ou otimização de contexto integrados.

Em tarefas longas, isso pode levar a:

• Aumento rápido dos custos de Token
• Aproximação dos limites de contexto do modelo
• Informações chave sendo "ofuscadas"

O gerenciamento de contexto continua sendo um desafio para a camada de arquitetura do Agente resolver, e não para o protocolo MCP.

3. Diferenças na Maturidade entre Implementações de Linguagem

Embora o protocolo seja agnóstico à linguagem, a maturidade varia na prática:

• Os ecossistemas JavaScript/Node.js e Python são os mais maduros.
• As implementações para Rust, Go e Java ainda estão evoluindo.
• O suporte para as especificações mais recentes pode variar entre as implementações.

As equipes de engenharia devem:

• Garantir a consistência entre implementações e especificações.
• Avaliar a estabilidade e manutenção das implementações do Servidor MCP para ambientes de produção.

Isso é comum para qualquer protocolo emergente em seus estágios iniciais.

4. Segurança e Permissões Dependem de Sistemas Externos

O MCP é projetado para ser "neutro ao protocolo" e não inclui um sistema de segurança integrado. Especificamente:

• O MCP define limites de capacidade (Ferramentas / Recursos).
• Ele não impõe mecanismos específicos de autenticação, autorização ou auditoria.

Na implantação no mundo real, a segurança deve ser implementada via sistemas externos, como:

• OAuth / OIDC
• API Gateways
• Arquiteturas Zero Trust
• Sistemas IAM empresariais

Um Servidor MCP deve ser visto como:

Um serviço de capacidade envolto em um sistema de segurança, em vez de ser o próprio centro de controle de segurança.

Esta é uma razão chave pela qual o MCP pode se adaptar flexivelmente a diferentes empresas e ambientes de nuvem, mas também aumenta a complexidade do design do sistema.

5. Rápida Evolução do Protocolo e Ecossistema

Como um novo protocolo para Agentes de IA, o MCP está evoluindo rapidamente:

• Detalhes e primitivos do protocolo estão sendo refinados.
• Existe um atraso para que diferentes implementações suportem novas funcionalidades.
• As melhores práticas para casos de uso avançados ainda estão sendo estabelecidas.

O MCP deve ser visto como um protocolo de infraestrutura de longo prazo, e não como um padrão finalizado e estático.

Os Servidores MCP focam em fornecer uma maneira padronizada de descobrir, chamar e combinar ferramentas. Compreender essas limitações ajuda os desenvolvedores a:

• Definir limites claros de responsabilidade.
• Evitar a dependência excessiva do próprio protocolo.
• Resolver a complexidade na camada arquitetural apropriada.

Conclusão

Na engenharia prática, o MCP atua como uma "base de protocolo de capacidade", cujo valor se torna mais aparente à medida que a complexidade do sistema cresce. O Servidor MCP não substitui APIs tradicionais ou Chamada de Função; em vez disso, ele fornece uma camada de protocolo padronizada, extensível e segura para Agentes de IA. Ao introduzir esta camada, ele aborda os desafios centrais de engenharia de escalonamento de Agentes de IA: reduzindo a complexidade de integração de N×M para N+M, fornecendo uma estrutura para descoberta dinâmica e execução segura, e desacoplando o ecossistema de ferramentas dos modelos de IA. Isso permite que agentes inteligentes:

• Acessem capacidades sistematicamente;
• Descobriam e chamem ferramentas/recursos dinamicamente;
• Interoperem entre modelos e plataformas.

O MCP estabelece as bases para um ecossistema de ferramentas de IA rico e composível. Ele marca uma mudança da "integração manual" para a "infraestrutura padronizada", fornecendo uma base para a construção de sistemas de IA empresariais interoperáveis, escaláveis e seguros.

Perguntas Frequentes (FAQ) sobre MCP

1. O MCP substituirá as APIs tradicionais ou a Chamada de Função?

Não. O MCP não é um substituto, mas atua em um nível superior, permitindo que o Cliente MCP descubra dinamicamente capacidades de um Servidor MCP via o método list.

• Para cenários simples, fixos e de modelo único, a Chamada de Função é eficiente.
• Para sistemas de Agente multi-modelo, multi-ferramenta e em evolução, o MCP oferece melhor desacoplamento e manutenibilidade.

Em sistemas do mundo real, os dois frequentemente têm uma relação complementar.

2. O MCP requer uma LLM específica?

Não. O MCP é agnóstico ao modelo. Ele regula a comunicação entre o Cliente e o Servidor e não se importa se o modelo subjacente é da OpenAI, Anthropic, Google ou um modelo de código aberto local. Desde que a aplicação de IA possa expor o contexto da ferramenta e iniciar chamadas de acordo com o protocolo MCP, ela pode usar o Servidor MCP.

3. O MCP possui segurança integrada?

Não. É neutro ao protocolo. A segurança (HTTPS, OAuth2, IAM) deve ser fornecida pelo ambiente de implantação e sistemas externos.

4. Como os conflitos de ferramentas são tratados com múltiplos Servidores MCP?

O MCP não resolve conflitos. Se múltiplos servidores oferecem ferramentas semelhantes, a responsabilidade pela seleção e prioridade da ferramenta recai sobre o Cliente ou a camada Planner do Agente.

5. O MCP causa inchaço na janela de contexto?

Pode, mas este é um desafio inerente dos Agentes LLM. O MCP não gerencia contexto; a sumarização e o gerenciamento de memória são responsabilidade da arquitetura do Agente.

6. O MCP é adequado para uso empresarial de alta concorrência?

Sim, desde que a implementação seja robusta. Alta concorrência depende da qualidade do servidor, implantação multi-instância e arquiteturas cloud-native como Kubernetes.

7. O custo de adoção do MCP é alto?

A codificação é relativamente simples, mas requer uma compreensão arquitetural de sistemas de Agente e governança de ferramentas. É mais adequado para equipes que constroem aplicações de IA de médio a grande porte.

8. O MCP é "estável"?

O design central é estável, mas o ecossistema ainda está evoluindo. É um protocolo de infraestrutura com visão de futuro, e não uma solução "pronta e acabada".

9. O MCP é adequado para desenvolvedores individuais?

Sim, se houver necessidade de escalabilidade. Para projetos muito simples, pode ser "excesso", mas evita altos custos de refatoração à medida que um sistema cresce.

10. Qual problema o MCP resolve melhor?

Ele se destaca na padronização do acesso a múltiplas ferramentas/serviços, desacoplando a descoberta de capacidade da execução e permitindo a reutilização de capacidade entre diferentes modelos e equipes.

Série de artigos MCP:

• Análise Abrangente do Servidor MCP: O Hub de Comunicação de Contexto e Ferramentas na Era dos Agentes de IA
• Que Problemas Chave o MCP Server Resolve? Por Que os Agentes de IA Precisam Dele
• Arquitetura e Princípios de Funcionamento do Servidor MCP: Do Protocolo ao Fluxo de Execução
• Guia Prático do Servidor MCP: Construção, Teste e Implantação do Zero ao Um
• Avaliação de Cenários de Aplicação e Guia de Seleção Técnica do Servidor MCP

Sobre o Autor

Este conteúdo é compilado e publicado pela Equipe Editorial de Conteúdo do NavGood. NavGood é uma plataforma focada em ferramentas de IA e ecossistemas de aplicação, acompanhando o desenvolvimento e a implementação de Agentes de IA, fluxos de trabalho automatizados e IA Generativa.

Isenção de Responsabilidade: Este artigo representa a compreensão e experiência pessoal do autor. Não representa a posição oficial de nenhum framework ou empresa e não constitui aconselhamento comercial ou de investimento.

Referências: [1]: https://json-rpc.dev/learn/mcp-basics "Compreendendo JSON-RPC para Integração de IA" [2]: https://modelcontextprotocol.io/docs/learn/architecture "Visão geral da arquitetura - Model Context Protocol" [3]: https://json-rpc.org/specification "Especificação JSON-RPC 2.0" [4]: https://modelcontextprotocol.io/docs/learn/architecture "Sobre o MCP: Visão geral da arquitetura"