Protocolo de Contexto do Modelo (MCP), e notas sobre a implementação do servidor MCP em Go

Longread sobre especificações e implementação do MCP em GO

Conteúdo da página

Aqui temos uma descrição do Protocolo de Contexto do Modelo (MCP), notas breves sobre como implementar um servidor MCP em Go, incluindo a estrutura da mensagem e especificações do protocolo.

Robots e MCP

Visão Geral do Protocolo de Contexto do Modelo (MCP)

Protocolo de Contexto do Modelo (MCP) é um quadro aberto e padronizado (introduzido pela Anthropic no final de 2024) para conectar modelos de linguagem artificial a fontes de dados externas, ferramentas e sistemas. Seu objetivo é resolver o problema de “N×M integração” ao fornecer uma interface universal para coisas como ler arquivos, executar funções (ferramentas) e usar prompts contextuais em diferentes aplicações. O MCP não é um protocolo proprietário ou interno; é um padrão aberto com uma especificação oficial e uma implementação de referência de código aberto. Na verdade, principais fornecedores de IA (incluindo a OpenAI e a Google DeepMind) anunciaram suporte ao MCP após sua introdução, reforçando que ele é intencionado como um padrão amplamente adotado, e não uma solução específica para fornecedores.

Propósito e Arquitetura do MCP

O MCP visa padronizar como as aplicações fornecem contexto aos LLMs – a analogia frequentemente usada é “uma porta USB-C para aplicações de IA”. Ao definir um protocolo comum, o MCP permite que assistentes de IA e ferramentas interfacerem-se de forma seamles com bancos de dados, sistemas de arquivos, APIs e outros recursos, sem integrações personalizadas. Isso ajuda os modelos de linguagem a gerar respostas mais relevantes e atualizadas, ao lhes dar acesso seguro aos dados de que precisam.

Arquitetura: O MCP segue um modelo cliente-servidor com uma separação clara de papéis:

  • MCP Host: A aplicação principal (por exemplo, um cliente de chat ou IDE) que gerencia as conexões. Ele contém uma ou mais MCP clients (conectores).
  • MCP Client: Uma instância de conector (dentro do host) que estabelece uma sessão 1:1 com um servidor MCP. O cliente gerencia o ciclo de vida da sessão, roteia mensagens e impõe quaisquer permissões de usuário ou políticas de segurança.
  • MCP Server: Um serviço leve que expõe capacidades específicas (acesso a certos dados ou funções) via o protocolo MCP. Cada servidor pode envolver uma fonte de dados (arquivos, banco de dados, API, etc.) ou ferramenta. Vários servidores podem ser executados em paralelo, cada um fornecendo diferentes integrações.
  • Fontes de Dados/Serviços: Os recursos reais com os quais os servidores se interfaceiam – isso pode incluir arquivos locais e bancos de dados ou serviços remotos (APIs da web, aplicações SaaS, etc.). O servidor MCP atua como um adaptador para esses recursos, garantindo que o LLM acesse os dados apenas por meio do protocolo padronizado.

Este design é inspirado no Protocolo de Servidor de Linguagem (LSP) do mundo das IDEs. Assim como o LSP permite que qualquer editor suporte qualquer linguagem de programação por meio de um protocolo comum, o MCP permite que qualquer aplicação de IA se conecte a qualquer integração de dados/ferramentas que fale MCP. Essa desconexão significa que os desenvolvedores de ferramentas de IA podem escrever um servidor MCP uma vez e tê-lo funcionando com muitos clientes de IA, e os desenvolvedores de aplicações de IA podem adicionar novas integrações simplesmente conectando um servidor MCP, evitando código de integração personalizado.

Protocolo e Estrutura da Mensagem

Comunicação: A comunicação do MCP é construída sobre sessões persistentes e com estado usando mensagens JSON-RPC 2.0. Todos os pedidos e respostas conformam-se ao formato JSON-RPC (com um campo "jsonrpc": "2.0", nomes de métodos, parâmetros e IDs correlacionados). Qualquer um dos lados – cliente ou servidor – pode enviar pedidos ou notificações, permitindo interação bidirecional. Uma sessão MCP geralmente começa com um aperto de mãos:

  • O cliente inicia com uma initialize solicitação, propondo uma versão do protocolo e anunciando suas capacidades (quais recursos suporta). Por exemplo, o cliente pode indicar que pode lidar com pedidos de “amostragem” direcionados pelo servidor ou fornecer certas raízes para acesso a arquivos. O servidor responde com sua própria versão do protocolo suportada e capacidades, finalizando quais recursos estão habilitados para esta sessão (o MCP usa um sistema de negociação de capacidades semelhante a recursos opcionais no LSP). Se capacidades críticas ou versão forem incompatíveis, a conexão é abortada com elegância.
  • Após o acordo, o cliente envia uma initialized notificação para marcar a preparação. Após isso, as operações normais podem prosseguir. A sessão permanece aberta para uma troca contínua de mensagens JSON-RPC até que um dos lados envie um desligamento.

Transportes: O MCP não exige um único transporte – ele funciona sobre qualquer canal que possa transportar texto JSON. Comumente, um servidor MCP é executado como um subprocesso e comunica-se por meio de STDIO (tubos stdin/stdout) para integrações locais. Isso é análogo ao modo como servidores de linguagem operam e é conveniente para ferramentas locais (o host pode iniciar o processo do servidor e encaminhar mensagens). Alternativamente, servidores MCP podem ser executados como serviços independentes acessíveis via HTTP. A especificação MCP define um transporte HTTP de streaming onde o servidor expõe um único ponto de extremidade HTTP para chamadas JSON-RPC (os clientes POSTam solicitações, e o servidor pode responder ou transmitir resultados via Server-Sent Events para operações de longa duração). Em qualquer caso, as mensagens são linhas JSON UTF-8, e o protocolo suporta respostas de streaming e mensagens iniciadas pelo servidor (a abordagem HTTP+SSE permite que o servidor envie notificações ou resultados parciais de forma assíncrona). Diretrizes de segurança recomendam que servidores locais se vinculem ao localhost e validem cabeçalhos Origin para evitar acesso remoto indesejado, e que autenticação adequada (por exemplo, tokens ou fluxos OAuth) seja usada para servidores remotos.

Formato da Mensagem: O MCP aproveita os três tipos de mensagens do JSON-RPC: Pedidos, Respostas e Notificações. Um pedido contém um id, uma string method e (opcionalmente) params (normalmente um objeto JSON de argumentos). O receptor deve responder com uma resposta correspondente (com id correspondente) contendo um result ou um objeto error. As notificações são como mensagens unidirecionais com um method e parâmetros, mas sem id (portanto, não recebem resposta). O MCP impõe algumas regras adicionais sobre o JSON-RPC base (por exemplo, id deve ser não nulo e não reutilizado durante uma sessão) para manter a clareza.

Sessão e Estado: A conexão é considerada com estado – o cliente e o servidor mantêm contexto sobre as capacidades um do outro e possivelmente algum estado da sessão (como assinaturas para alterações, operações em andamento, etc.). Há também procedimentos definidos para desligamento elegante (por exemplo, um cliente pode enviar uma solicitação de desligamento ou simplesmente fechar o transporte; os servidores devem lidar com a limpeza, e ambos os lados implementam tempos de espera para operações pendentes). O tratamento de erros segue convenções JSON-RPC (respostas de erro têm um código e uma mensagem) e a especificação define códigos de erro padrão para certas condições (por exemplo, permissão negada, ferramenta não encontrada, etc.). O MCP também fornece utilitários para preocupações transversais: por exemplo, há notificações integradas para atualizações de progresso, cancelamento de uma solicitação de longa duração (CancelledNotification), mensagens de log/debug e alterações de configuração. Esses ajudam a gerenciar interações longas ou complexas (o cliente pode cancelar uma chamada de ferramenta em andamento, ou o servidor pode enviar avisos ao cliente, etc.).

Recursos e Operações do MCP

Após a inicialização, uma sessão MCP permite a troca de contexto e comandos de forma estruturada. Os recursos principais do lado do servidor do MCP são Prompts, Recursos e Ferramentas (cada um dos quais o servidor declara se suporta durante a inicialização):

  • Prompts: Modelos de prompt pré-definidos ou instruções que o servidor pode fornecer ao cliente. Esses geralmente são auxiliares acionados pelo usuário (o usuário escolhe explicitamente um prompt para inserir na conversa, por exemplo, via um comando de barra na interface). O MCP fornece métodos para listar prompts disponíveis e recuperar o conteúdo de um prompt. Por exemplo, o cliente pode chamar prompts/list para obter uma lista de modelos de prompt (cada um com um nome, descrição e parâmetros opcionais). Para obter um prompt, o cliente usa prompts/get com o nome do prompt e quaisquer valores de argumento; o servidor então retorna o conteúdo do prompt (geralmente como um conjunto de mensagens que o cliente injetará no contexto do LLM). Os prompts permitem reutilizar instruções ou fluxos de trabalho complexos (por exemplo, “modelo de revisão de código”) que o usuário pode invocar sob demanda. Os servidores indicam uma capacidade prompts (com sub-recursos opcionais como listChanged para notificar o cliente se o conjunto de prompts mudar dinamicamente).

  • Recursos: Dados estruturados ou conteúdo que fornece contexto ao modelo. Recursos geralmente são coisas como arquivos, documentos, entradas de banco de dados – informações que um assistente de IA pode ler ou referenciar. O MCP padroniza como os recursos são identificados e transferidos: cada recurso tem um identificador URI (por exemplo, file:///path/to/file.txt ou um esquema personalizado para bancos de dados). Os clientes podem consultar quais recursos estão disponíveis via resources/list (o servidor pode expor uma árvore de diretórios, uma lista de documentos recentes, etc.). A resposta do servidor inclui metadados para cada recurso (URI, nome, tipo, descrição, etc.). Em seguida, o cliente pode solicitar o conteúdo de um recurso específico com resources/read, passando o URI. O servidor responde com o conteúdo do recurso, que pode ser texto (para arquivos) ou dados estruturados (o MCP suporta diferentes tipos de conteúdo, como texto, JSON, binário, etc., com tipos MIME). Há também suporte para modelos de recursos (recursos parametrizados identificados por URIs de modelo, que o cliente pode preencher, por exemplo, uma consulta de banco de dados onde o usuário fornece um parâmetro). Se habilitado, os servidores podem enviar notificações quando os recursos mudarem (por exemplo, notifications/resources/updated) ou permitir que os clientes se inscrevam em mudanças em um recurso (resources/subscribe). No design do MCP, os recursos são contexto controlado pela aplicação: a aplicação hospedeira (cliente) geralmente decide quais conteúdos de recursos alimentarão realmente o prompt do modelo (muitas vezes após a confirmação do usuário ou com base no contexto da interface).

  • Ferramentas: Funções ou ações executáveis que o servidor expõe para o modelo invocar. Ferramentas representam operações que a IA pode executar – por exemplo, chamar uma API externa, executar uma consulta de banco de dados, enviar um e-mail ou modificar um arquivo. Cada ferramenta tem um nome e um esquema JSON para seus parâmetros de entrada (e opcionalmente saída), então a IA (ou cliente) sabe quais argumentos espera. As ferramentas são geralmente controladas pelo modelo: a ideia é que o modelo de linguagem (agente) decida se e quando usar uma ferramenta durante uma conversa para cumprir a solicitação do usuário. No entanto, por segurança, um usuário humano ou a aplicação hospedeira pode mediar o uso da ferramenta (por exemplo, exigir um clique de confirmação). O uso de ferramentas no MCP envolve duas operações principais: listar e chamar. Um cliente pode chamar tools/list para obter as ferramentas disponíveis e seus esquemas. Por exemplo, um servidor pode listar uma ferramenta get_weather com uma descrição e um esquema de entrada que exige uma string “location”. Em seguida, quando o modelo decidir usar uma ferramenta (ou o usuário a invocar), o cliente envia uma solicitação tools/call com o nome da ferramenta e um objeto JSON de argumentos. O servidor executa a função e retorna o resultado, normalmente como um campo result.content que pode conter texto ou dados estruturados (o MCP suporta o retorno de múltiplos partes de conteúdo, por exemplo, texto mais uma imagem, etc., embora o texto seja comum). Um exemplo simples: chamar uma ferramenta get_weather pode retornar uma carga útil de texto como “Clima atual em Nova York: 72°F, parcialmente nublado” como conteúdo para o assistente apresentar. As ferramentas também podem indicar erros (a resposta tem um sinalizador isError ou um objeto de erro se algo sair errado). Assim como prompts e recursos, a capacidade tools pode ter um sinalizador opcional listChanged para notificar quando ferramentas disponíveis mudarem no tempo de execução (por exemplo, um plugin dinâmico carregado/desinstalado).

Além das funcionalidades acima oferecidas pelo servidor, o MCP também define funcionalidades oferecidas pelo cliente (capacidades que servidores podem aproveitar se o cliente as suportar). Essas incluem Amostragem, Raízes e Elicitação:

  • Amostragem permite que um servidor solicite ao cliente (e ao seu LLM) que execute inferência de modelo dentro da sessão. Por exemplo, um servidor poderia iniciar uma chamada LLM (talvez para continuar uma cadeia de pensamento ou resumir algo) enviando uma solicitação como sampling/request – o cliente então promoveria o modelo e retornaria o resultado. Isso permite comportamentos agentes onde o servidor pode impulsionar a IA para ajudar em suas próprias subtarefas. (Todas essas ações estão sujeitas à aprovação do usuário e políticas – por exemplo, um usuário pode ter que optar por permitir que um servidor acione o modelo para consultas adicionais.)

  • Raízes permite que o servidor inquira ou opere dentro de certas raízes de sistema de arquivos ou URI permitidas. O cliente pode fornecer uma lista de “raízes” de diretórios/URIs que o servidor é permitido acessar, via roots/list. Isso é uma característica de segurança que garante que o servidor saiba os limites (por exemplo, quais árvores de pastas ele pode ler).

  • Elicitação permite que o servidor peça ao cliente para obter mais informações do usuário, se necessário. Por exemplo, se uma ferramenta precisar de uma peça de informação faltante que não foi fornecida, o servidor pode enviar uma solicitação de eliciação, que o cliente (interface) traduziria em um prompt para o usuário (“A integração X precisa da sua chave API, por favor, insira-a”). Dessa forma, o servidor pode coletar interativamente entradas via o cliente.

Essas funcionalidades são todas opcionais e negociadas de antemão. Um aspecto importante do design do MCP é que a negociação de capacidades ocorre durante a inicialização – o cliente e o servidor anunciam quais das funcionalidades acima suportam, então ambas as partes sabem quais operações estão disponíveis na sessão. Por exemplo, se um servidor não declarar a capacidade tools, o cliente não tentará nenhuma operação tools/list ou tools/call com ele. Essa extensibilidade significa que o MCP pode evoluir com novas funcionalidades ao longo do tempo, mantendo a compatibilidade para trás (métodos não suportados simplesmente não serão usados se não negociados).

Implementações, SDKs e Construindo um Servidor MCP (especialmente em Go)

Especificação Oficial & Documentação: A especificação autoritativa do MCP está disponível publicamente, incluindo um esquema formal de todos os tipos de mensagens. Ela é mantida no site do Protocolo de Contexto do Modelo e no GitHub. A especificação é definida em um arquivo de esquema TypeScript (com um esquema JSON correspondente) que documenta com precisão todas as solicitações, respostas e estruturas. O site de documentação (modelcontextprotocol.io) fornece guias, um FAQ e explicações detalhadas de cada funcionalidade e tipo de mensagem, bem como uma ferramenta de “MCP Inspector” para depuração interativa. Embora o MCP ainda não seja um padrão IETF ou ISO, ele é desenvolvido como um padrão aberto com contribuições da comunidade e usa a terminologia familiar de RFC 2119 para requisitos. É um protocolo em evolução (as versões são marcadas com datas; por exemplo, 2025-06-18 é uma revisão recente), com uma política de versionamento para gerenciar mudanças.

Implementações de Referência: Quando o MCP foi introduzido, a Anthropic abriu mão de uma série de conectores de servidor MCP e SDKs. Existe uma organização do GitHub chamada modelcontextprotocol que hospeda a especificação e vários repositórios. Destacavelmente, um repositório “servers” contém uma coleção de implementações pré-construídas de servidores MCP para serviços e fontes de dados comuns. Essas servem como integrações de referência e podem frequentemente ser usadas prontas para uso ou como modelos para servidores personalizados. Por exemplo, o repositório oficial inclui servidores para Google Drive (acesso e pesquisa em Google Drive), Slack (mensagens de workspace e conteúdo de canais), GitHub/Git (contexto de repositórios de código), PostgreSQL (consultas de banco de dados somente leitura com informações de esquema), Google Maps (API de localização e direções), Puppeteer (navegação e raspagem da web), e muitos outros. Ao instalar ou executar esses servidores, uma aplicação de IA como Claude ou Cursor pode imediatamente obter essa integração. Há também um serviço de registro MCP comunitário (em Go, open-source) para indexar servidores disponíveis, e muitas contribuições de terceiros que estendem o MCP a diversos domínios (do CRM até dados de blockchain).

SDKs e Bibliotecas: Para facilitar a construção de seus próprios servidores/clientes MCP, existem SDKs oficiais em múltiplas linguagens. Em 2025, o projeto fornece SDKs para TypeScript/Node, Python, Java (e Kotlin), C# (desenvolvido com a Microsoft), Ruby (com Shopify), Swift e outros. Essas bibliotecas lidam com a parte interna do protocolo – por exemplo, gerenciando o transporte JSON-RPC, implementando o esquema da especificação e fornecendo APIs auxiliares para registrar ferramentas ou servir recursos. Por exemplo, o SDK TypeScript pode ser usado para escrever rapidamente um servidor em Node.js, e o SDK Python permite integrar o MCP em aplicações Python. A abordagem do SDK significa que os desenvolvedores não precisam construir manualmente mensagens JSON-RPC ou implementar a máquina de estado completa; em vez disso, eles chamam métodos de alto nível para enviar solicitações ou publicar capacidades.

Implementação em Go: Go surgiu como uma escolha popular para servidores MCP devido à sua performance e forças de concorrência (boa para lidar com múltiplas solicitações simultâneas). Um SDK oficial em Go agora está disponível, mantido em colaboração com a equipe de Go da Google. (Isso foi anunciado em torno de abril de 2025 e a primeira versão estável está prevista para agosto de 2025.) O SDK em Go fornece um pacote mcp para construir clientes/servidores e um jsonschema auxiliar para esquemas de ferramentas. Usando o SDK em Go, os desenvolvedores podem criar um servidor MCP com apenas algumas chamadas. Por exemplo, você pode instanciar um novo servidor com um nome e versão, depois adicionar ferramentas via AddTool fornecendo uma definição de ferramenta (nome, descrição, esquema de entrada) junto com uma função de manipulador em Go para executar quando essa ferramenta for chamada. O SDK cuida de expor a ferramenta no protocolo (anunciando-a em tools/list e lidando com solicitações tools/call). Da mesma forma, você poderia expor recursos ou prompts com APIs análogas. Finalmente, você executa o servidor – por exemplo, server.Run(ctx, mcp.NewStdioTransport()) iniciará o processamento de mensagens JSON-RPC por meio de stdio até que o cliente se desconecte. Do lado do cliente, o SDK em Go pode gerar um processo filho e conectar-se via mcp.NewCommandTransport(exec.Command("myserver")), depois o cliente pode chamar session.CallTool(ctx, params) para invocar uma ferramenta e obter facilmente o resultado no código Go.

Exemplo: A documentação oficial do SDK em Go mostra um servidor “greeter” simples. O servidor registra uma ferramenta "greet" que aceita um nome e retorna uma string de saudação. O cliente então chama essa ferramenta pelo nome e imprime o resultado. Isso ilustra o padrão básico: definir ferramenta -> cliente chama ferramenta -> obter resultado. Em segundo plano, isso corresponde a mensagens JSON-RPC ("method": "tools/call", params: {"name": "greet", ...} e a resposta contendo result.content com texto) conforme definido pela especificação MCP.

Antes do lançamento oficial do SDK em Go, a comunidade criou suas próprias bibliotecas em Go. Destacavelmente, o projeto mcp-go de Ed Zynda (mark3labs/mcp-go) foi amplamente usado e influenciou o design do SDK oficial. Outra biblioteca, mcp-golang por Metoro, forneceu uma implementação e API em Go (o post do blog da comunidade Dev por Elton Minetto usa essa biblioteca desde o início de 2025). Essas bibliotecas da comunidade permitiram que os desenvolvedores em Go experimentassem com o MCP cedo – por exemplo, um tutorial mostra como construir um servidor MCP que busca códigos postais brasileiros (CEP) expondo uma ferramenta “zipcode” via a biblioteca mcp-golang da Metoro. Nesse exemplo, o servidor Go registra uma função que chama uma API externa para encontrar um endereço a partir de um CEP e retorna o resultado como texto – permitindo que um assistente de IA obtenha informações de endereço sob demanda via MCP. Outro guia demonstra como envolver um banco de dados em memória personalizado (DiceDB) como um servidor MCP usando o SDK mcp-go da mark3labs: ele define uma ferramenta ping para verificar a conectividade do DB e outras ferramentas para operações de dados. Esses exemplos destacam como pode ser simples criar uma integração MCP: a maior parte do código é apenas a lógica de negócios (chamadas de API, consultas de banco de dados, etc.), enquanto o SDK cuida da fiação JSON-RPC.

Construindo um Servidor MCP em Go (Destaque do Tutorial)

Para esboçar o processo, aqui está um fluxo típico com o Go SDK ou uma biblioteca semelhante:

  1. Configurar o Servidor: Inicialize uma nova instância de servidor com informações básicas (nome, versão e declare as capacidades suportadas). Por exemplo, em Go: server := mcp.NewServer("MyServer", "1.0.0", nil) criará um servidor que, por padrão, suporta recursos do protocolo principal. Você pode habilitar capacidades específicas, como prompts/recursos/ferramentas, por meio de opções ou simplesmente registrando esses recursos (adicionar uma ferramenta ou recurso implica que essa capacidade está disponível).

  2. Registrar Recursos: Adicione as funcionalidades que deseja expor:

    • Se estiver expondo Ferramentas, defina o esquema de cada ferramenta e o manipulador. Por exemplo, usando o AddTool do SDK Go: forneça um mcp.Tool{Name: "...", Description: "..."} e uma função manipuladora que receba a solicitação de chamada e retorne um resultado (que pode incluir texto ou outros conteúdos). O SDK gerará automaticamente um JSON Schema para entradas com base nos tipos de parâmetros do manipulador (ou você pode especificá-lo).
    • Se estiver expondo Recursos, você pode usar uma API para registrar listagens de recursos ou um callback para ler conteúdo. No SDK Python, por exemplo, você pode subclassificar um ResourceProvider; no Go, o SDK ainda está em evolução, mas você provavelmente fornecerá funções para listar e ler recursos. Cada recurso deve ter um URI estável.
    • Se estiver expondo Prompts, defina modelos de prompt (podem ser arquivos estáticos ou strings) e registre-os com nomes e parâmetros opcionais. O servidor anunciará esses prompts para que o cliente os obtenha e os exiba aos usuários.

  3. Implementar Transporte: Decida como o servidor será executado. O mais simples para uso local é o stdio – por exemplo, server.Run(ctx, mcp.NewStdioTransport()) no Go iniciará a leitura de JSON-RPC do stdin. Se o servidor precisar ser acessado em rede, você pode implementar um manipulador HTTP que use o SDK Go para aceitar JSON-RPC por HTTP (o SDK Go oficial pode incluir em breve um auxiliar para o transporte HTTP/SSE também).

  4. Teste com o Cliente: Você pode testar o servidor com um cliente compatível com MCP. Por exemplo, o Claude 2 (Claude para Desktop) da Anthropic suporta carregar servidores MCP locais; você configuraria o Claude para iniciar ou se conectar ao seu binário de servidor. Existe também uma ferramenta CLI chamada mcp-cli e a interface gráfica MCP Inspector para testar servidores sem um cliente AI completo – essas ferramentas enviam solicitações MCP para seu servidor e mostram os resultados, ajudando no depuração.

  5. Segurança e Permissões: Ao construir um servidor, considere autenticação e escopo. Para servidores locais, o host pode executá-lo com certas permissões do sistema operacional ou fornecer chaves de API por meio do ambiente. Para servidores remotos, use cabeçalhos de autenticação ou fluxos OAuth. O MCP inclui uma especificação de autorização para transportes HTTP (o servidor pode exigir um token e o cliente pode enviá-lo). Sempre garanta que o servidor acesse apenas os dados que o usuário permitiu (por exemplo, respeite as diretorias raiz fornecidas pelo cliente e não vazar dados para outros lugares) – as diretrizes do MCP enfatizam o consentimento do usuário, a privacidade dos dados e a segurança das ferramentas como fundamentais.

Em resumo, o MCP é um protocolo formal, mas flexível, para conectar LLMs ao mundo exterior. Ele não é uma API interna vinculada a uma única empresa, mas um padrão aberto com crescente adoção e uma rica ecossistema de integrações. O protocolo define estruturas claras de mensagens (baseadas em JSON-RPC) e um conjunto de operações (métodos para prompts, ferramentas, recursos, etc.) que qualquer cliente/servidor compatível pode implementar. Documentação oficial e especificações estão disponíveis, e diversos SDKs, bibliotecas e servidores de exemplo (incluindo em Go) tornam mais fácil a implementação. Ao usar o MCP, os desenvolvedores podem construir aplicações AI que aproveitem de forma segura dados e serviços existentes, sem recriar a lógica de integração para cada novo modelo ou conjunto de dados.