O que é o Protocolo de Contexto do Modelo (MCP)

O Model Context Protocol (MCP) foi criado para enfrentar um desafio básico da criação de aplicativos de IA agentiva: conectar grandes modelos de linguagem (LLMs) isolados do mundo exterior. Por padrão, os LLMs são motores de raciocínio poderosos, mas de conhecimento é estático, vinculado a uma data de corte de treinamento, e eles não têm a capacidade nativa de acessar dados em tempo real nem executar ações em sistemas externos.

A conexão de LLMs a sistemas externos tradicionalmente é feita por meio de integrações diretas e personalizadas de API. Essa abordagem é eficaz, mas exige que cada desenvolvedor de aplicativos aprenda a API específica de cada ferramenta, crie o código para lidar com consultas, analisar resultados e manter essa conexão ao longo do tempo. À medida que o número de aplicações de IA e ferramentas disponíveis cresce, surge uma oportunidade para um método mais padronizado e eficiente.

O MCP oferece esse protocolo padronizado, inspirando-se em padrões comprovados, como REST para serviços web e o Language Server Protocol (LSP) para ferramentas de desenvolvedor. Em vez de forçar todos os desenvolvedores de aplicativos a se tornarem especialistas na API de todas as ferramentas, o MCP define uma linguagem comum para essa camada de conectividade.

Isso cria uma clara separação de responsabilidades. Além de abrir as portas para que os fornecedores de plataforma e ferramentas exponham os serviços por meio de um único servidor MCP reutilizável que é inerentemente compatível com LLM. A responsabilidade de manter a integração pode então passar do desenvolvedor individual da aplicação de IA para o proprietário do sistema externo. E assim promover um ecossistema robusto e interoperável onde qualquer aplicativo compatível pode se conectar a qualquer ferramenta compatível, simplificando o desenvolvimento e a manutenção.

Arquitetura MCP

O MCP opera em um modelo cliente-servidor projetado para conectar um mecanismo de raciocínio (o LLM) a um conjunto de recursos externos. A arquitetura começa com o LLM e, progressivamente, revela os componentes que permitem que ele interaja com o mundo exterior.

Esta arquitetura consiste em três componentes principais:

1. Hosts são aplicativos LLM que querem acessar dados por meio do MCP (por exemplo, Claude Desktop, IDEs, agentes de IA).
2. Os servidores são programas leves que expõem recursos específicos por meio do MCP.
3. Os clientes mantêm conexões 1:1 com os servidores, dentro do aplicativo hospedado.

Clientes ou hosts do MCP

Os clientes ou hosts MCP são os aplicativos que orquestram a interação entre LLMs e um ou mais servidores MCP. O cliente é fundamental; ele contém a lógica específica do app. Embora os servidores ofereçam recursos brutos, o cliente é responsável por utilizá-los. Ele analisa a seguinte funcionalidade para isso:

• Montagem do prompt: reunir o contexto de vários servidores para criar o prompt final e eficaz para o LLM
• Gerenciamento de estado: manter o histórico de conversação e o contexto do usuário em várias interações
• Orquestração: decidir quais servidores consultar para quais informações e executar a lógica quando um LLM decide usar uma ferramenta

Os clientes MCP conectam-se aos servidores por meio de solicitações de rede padrão (normalmente via HTTPS) para um endpoint de servidor conhecido. O poder do protocolo é que ele padroniza o contrato de comunicação entre eles. O protocolo em si é independente em relação à linguagem, com um formato baseado em JSON. Assim, qualquer cliente, independentemente da linguagem em que foi desenvolvido, pode se comunicar corretamente com qualquer servidor.

Exemplos de clientes da especificação do MCP

Servidores MCP

Um servidor MCP é um programa backend que atua como um encapsulador padronizado para uma fonte de dados ou ferramenta específica. Ele implementa a especificação MCP para expor recursos, como ferramentas executáveis ou recursos de dados, pela rede. Basicamente, ele traduz o protocolo exclusivo de um serviço específico (como uma consulta ao banco de dados ou uma REST API de terceiros) na linguagem comum do MCP, tornando-o compreensível para qualquer cliente MCP.

Exemplos de servidores da especificação do MCP

Prática: Como criar seu primeiro servidor MCP?

Vamos pegar o exemplo de um servidor que expõe ferramentas (mais sobre quais são as ferramentas logo abaixo). Esse servidor precisa lidar com duas solicitações principais do cliente:

1. Instale o SDK.
   

   # Python
   pip install mcp
   
   # Node.js
   npm install @modelcontextprotocol/sdk
   
   # Ou veja a especificação
   git clone https://github.com/modelcontextprotocol/specification
   

2. Crie seu primeiro servidor.
   

   from mcp.server.fastmcp import FastMCP
   import asyncio
   
   mcp = FastMCP("weather-server")
   
   @mcp.tool()
   async def get_weather(city: str) -> str:
       """Veja a previsão do tempo para uma cidade."""
       return f"Clima em {city}: Ensolarado, 72°F"
   
   if __name__ == "__main__":
       mcp.run()
   
   
   

3. Conecte-se ao Claude Desktop.
   

   {
     "mcpServers": {
       "clima": {
         "command": "python",
         "args": ["/full/path/to/weather_server.py"],
         "env": {}
       }
     }
   }
   
   

SDKs e recursos oficiais

Você pode começar a criar seus próprios clientes e servidores MCP usando os SDKs oficiais open source:

• Python SDK
• TypeScript SDK
• Especificação oficial do MCP
• Implementações de servidores comunitários

Ferramentas MCP

Uma ferramenta é uma capacidade específica e executável que um servidor MCP expõe a um cliente. Diferente dos recursos de dados passivos (como um arquivo ou documento), as ferramentas representam ações que o LLM pode decidir invocar, como enviar um e-mail, criar um ticket de projeto ou consultar um banco de dados em tempo real.

As ferramentas interagem com os servidores da seguinte forma: um servidor MCP declara as ferramentas que oferece. Por exemplo, um servidor da Elastic vai expor uma ferramenta "list_indices", definindo o nome, finalidade e parâmetros necessários (por exemplo, "list_indices", "get_mappings", "get_shards" e "buscar").

O cliente se conecta ao servidor e descobre essas ferramentas disponíveis. O cliente apresenta as ferramentas disponíveis ao LLM como parte do prompt ou contexto do sistema. Quando a saída do LLM indica uma intenção de usar uma ferramenta, o cliente analisa isso e faz uma solicitação formal ao servidor apropriado para executar essa ferramenta com os parâmetros especificados.

Exemplo de padrões de ferramentas da especificação MCP

Na prática: uma implementação de servidor MCP de baixo nível

Embora o exemplo de baixo nível seja útil para entender a mecânica do protocolo, a maioria dos desenvolvedores usará um SDK oficial para criar servidores. Os SDKs cuidam do boilerplate do protocolo, como a análise de mensagens e o roteamento de solicitações, permitindo que você se concentre na lógica do núcleo das ferramentas.

O exemplo a seguir usa o SDK oficial do Python do MCP para criar um servidor simples que expõe uma ferramenta get_current_time. Essa abordagem é muito mais concisa e declarativa do que a implementação de baixo nível.

import asyncio
import datetime
from typing import AsyncIterator

from mcp.server import (
    MCPServer,
    Tool,
    tool,
)

# --- Implementação da ferramenta ---
# O decorador @tool do SDK lida com o registro e a geração do esquema.
# Definimos uma função assíncrona simples que será exposta como uma ferramenta MCP.

@tool
async def get_current_time() -> AsyncIterator[str]:
    """
    Retorna a hora e data UTC atuais como uma string ISO 8601.
    
    Essa docstring é usada automaticamente como a descrição da ferramenta para o LLM.
    """
    # O SDK espera um iterador assíncrono, para então produzirmos o resultado.
    yield datetime.datetime.now(datetime.timezone.utc).isoformat()


# --- Definição do Servidor ---
# Criamos uma instância do MCPServer, passando as ferramentas que queremos expor.
# O SDK descobre automaticamente todas as funções decoradas com @tool.

SERVER = MCPServer(
    tools=[
        # O SDK seleciona automaticamente nossa função decorada.
        Tool.from_callable(get_current_time),
    ],
)


# --- Bloco de Execução Principal ---
# O SDK oferece um ponto de entrada principal para executar o servidor.
# Isso cuida de toda a lógica de comunicação subjacente (stdio, HTTP, etc.).

async def main() -> None:
    """Executa o servidor de ferramentas simples."""
    await SERVER.run()


if __name__ == "__main__":
    asyncio.run(main())

Este exemplo prático demonstra o poder de usar um SDK para criar servidores MCP:

1. @tool Decorador: Este decorador registra automaticamente a função get_current_time como uma ferramenta MCP. Ele inspeciona a assinatura e a docstring da função para gerar o esquema e a descrição necessários para o protocolo, poupando você de escrevê-los manualmente.
2. MCPServer Instância: a classe MCPServer é o núcleo do SDK. Você fornece uma lista das ferramentas que deseja expor, e ele cuida do resto.
3. SERVER.run(): Este único comando inicia o servidor e gerencia toda a comunicação de baixo nível, incluindo o tratamento de diferentes métodos de transporte, como stdio ou HTTP.

Como você pode ver, o SDK abstrai quase toda a complexidade do protocolo, permitindo que você crie ferramentas poderosas com apenas algumas linhas de código Python.

O MCP padroniza como um LLM interage com o mundo exterior ao definir três primitivas núcleo que um servidor pode expor. Essas primitivas oferecem um sistema completo para conectar LLMs a funcionalidades externas.

1. Recursos: Fornecendo contexto
   • Função: Acesso a dados
   • Analogia: endpoints GET
   • Os recursos são o principal mecanismo para fornecer contexto a um LLM. Eles representam fontes de dados que o modelo pode recuperar e usar para informar as respostas, como documentos, registros de banco de dados ou os resultados de uma consulta. Geralmente, são operações de apenas leitura.
2. Ferramentas: ativar ações
   • Função: Ações e computação
   • Analogia: endpoints POST ou PUT
   • Ferramentas são funções executáveis que permitem a um LLM realizar ações e ter um impacto direto em sistemas externos. Isso é o que permite que um agente vá além da simples recuperação de dados e realize ações como enviar um e-mail, criar um tíquete de projeto ou chamar uma API de terceiros.
3. Prompts: orientar a interação
   • Função: Modelos de interação
   • Analogia: receitas de fluxo de trabalho
   • Os prompts são modelos reutilizáveis que orientam a interação do LLM com um usuário ou um sistema. Eles permitem que os desenvolvedores padronizem fluxos conversacionais comuns ou complexos, garantindo um comportamento mais consistente e confiável do modelo.

Conceitos básicos

O MCP oferece uma maneira padronizada para aplicativos LLM (hosts) se integrarem com dados e recursos externos (servidores). A especificação é criada conforme o formato de mensagem  JSON-RPC 2.0 e define um conjunto de componentes obrigatórios e opcionais para permitir interações ricas e com estado.

Protocolo principal e recursos

No núcleo, o MCP padroniza a camada de comunicação. Todas as implementações devem ser compatíveis com o protocolo base e a gestão de ciclo de vida.

• Protocolo base: toda a comunicação utiliza mensagens padrão JSON-RPC (Solicitações, Respostas e Notificações).
• Recursos do servidor: os servidores podem oferecer qualquer combinação dos seguintes recursos aos clientes:
  • Recursos: dados contextuais para o usuário ou modelo consumir
  • Prompts: mensagens e fluxos de trabalho modelados
  • Ferramentas: funções executáveis para o LLM invocar
• Recursos do cliente: Os clientes podem oferecer esses recursos aos servidores para fluxos de trabalho mais avançados e bidirecionais:
  • Amostragem: permite que um servidor inicie comportamentos autônomos ou interações recursivas de LLM
  • Elicitação: permite que um servidor solicite informações adicionais ao usuário

Protocolo base MCP

O MCP é criado sobre uma base necessária de um protocolo base e gestão de ciclo de vida. Toda comunicação entre clientes e servidores deve seguir a especificação JSON-RPC 2.0, que define três tipos de mensagens:

• Solicitações: enviadas para iniciar uma operação. Elas precisam de uma string ou número inteiro único de id para rastreamento e não devem reutilizar a mesma id na mesma sessão.
• Respostas: enviadas em resposta a uma solicitação. Elas devem incluir a id da solicitação original e conter um objeto resultado para operações bem-sucedidas ou um objeto erro para falhas.
• Notificações: mensagens unilaterais enviadas sem um identificador que não requerem resposta do destinatário.

Recursos do cliente: habilitar fluxos de trabalho avançados

Para uma comunicação mais complexa e bidirecional, os clientes também podem oferecer recursos aos servidores:

• Amostragem: a amostragem permite que um servidor solicite uma inferência do LLM via cliente. Este é um recurso poderoso para permitir fluxos de trabalho autônomos de várias etapas, nos quais uma ferramenta pode precisar "fazer uma pergunta" ao LLM para ter mais informações antes de concluir a tarefa.
• Elicitação: a elicitação oferece um mecanismo formal para o servidor solicitar mais informações ao usuário final. Isso é crucial para ferramentas interativas que possam precisar de esclarecimento ou confirmação antes de prosseguir com uma ação.

Recursos do servidor: expor recursos

Os servidores expõem os recursos aos clientes por meio de um conjunto de recursos padronizados. Um servidor pode implementar qualquer combinação das seguintes:

• Ferramentas: as ferramentas são o principal mecanismo que permite que um LLM execute ações. São funções executáveis que um servidor expõe, permitindo que o LLM interaja com sistemas externos, como chamar uma API de terceiros, consultar um banco de dados ou modificar um arquivo.
• Recursos: recursos representam fontes de dados contextuais que um LLM pode recuperar. Ao contrário das ferramentas, que executam ações, os recursos são principalmente para a recuperação de dados somente leitura. Eles são o mecanismo para fundamentar um LLM em informações externas em tempo real, formando uma parte fundamental dos pipelines RAG avançados.
• Prompts: os servidores podem expor modelos de prompts pré-definidos que um cliente pode usar. Isso permite a padronização e o compartilhamento de prompts comuns, complexos ou altamente otimizados, garantindo interações consistentes.

Segurança e confiança

A especificação coloca uma forte ênfase na segurança, delineando os princípios-chave que os implementadores devem seguir. O próprio protocolo não pode impor essas regras; a responsabilidade recai sobre o desenvolvedor do aplicativo.

• Consentimento e controle do usuário: os usuários devem dar o consentimento explícito e manter o controle sobre todo o acesso aos dados e uso das ferramentas. É super importante ter interfaces de usuário claras para autorização.
• Privacidade de dados: os hosts não devem transmitir dados do usuário a um servidor sem consentimento explícito e devem implementar controles de acesso apropriados.
• Segurança da ferramenta: a invocação da ferramenta representa a execução de código arbitrário e deve ser tratada com cautela. Os hosts devem ter o consentimento explícito do usuário antes de invocar qualquer ferramenta.

O principal benefício do MCP está na padronização da camada de comunicação e interação entre modelos e ferramentas. Isso cria um ecossistema previsível e confiável para os desenvolvedores. As principais áreas de padronização incluem:

• API de conector uniforme: uma interface única e consistente para conectar qualquer serviço externo
• Contexto padronizado: um formato de mensagem universal para transmitir informações críticas, como histórico de sessões, embeddings, resultados produzidos por ferramentas e memórias de longo prazo.
• Protocolo de invocação de ferramentas: padrões acordados de solicitação e resposta para ferramentas externas, garantindo previsibilidade
• Controle de fluxo de dados: regras integradas para filtrar, priorizar, transmitir e agrupar contexto em lotes para otimizar a construção de prompts
• Padrões de segurança e autenticação: hooks comuns para autenticação de chave de API ou OAuth, limitação de taxa e criptografia para proteger a troca de dados
• Regras de ciclo de vida e roteamento: convenções que definem quando buscar o contexto, por quanto tempo armazená-lo em cache e como rotear os dados entre os sistemas
• Metadados e observabilidade: campos de metadados unificados que permitem logging, métricas e rastreamento distribuído consistentes em todos os modelos e ferramentas conectados
• Pontos de extensão: hooks definidos para adicionar lógica personalizada, como etapas de pré e pós-processamento, regras de validação personalizadas e registro de plugin

Em escala: resolver o pesadelo de integração de redimensionamento multiplicativo "M×N"

No cenário de IA em rápida expansão, os desenvolvedores enfrentam um desafio significativo de integração. Os aplicativos de IA (M) precisam acessar várias fontes de dados e ferramentas externas (N), desde bancos de dados e mecanismos de busca até APIs e repositórios de código. Sem um protocolo padronizado, os desenvolvedores são forçados a resolver o problema M×N, criando e mantendo uma integração única e personalizada para cada par de aplicativo-fonte.

Essa abordagem leva a vários problemas críticos:

• Esforços redundantes de desenvolvedores: as equipes resolvem de forma repetida os mesmos problemas de integração para cada novo aplicativo de IA, desperdiçando tempo e recursos valiosos.
• Complexidade avassaladora: diferentes fontes de dados lidam com funções similares de maneiras únicas, criando uma camada de integração complexa e inconsistente.
• Manutenção excessiva: a falta de padronização resulta em um ecossistema frágil de integrações personalizadas. Uma pequena atualização ou mudança na API de uma única ferramenta pode interromper conexões, exigindo manutenção constante e reativa.

O MCP transforma esse problema M×N em uma equação M+N muito mais simples. Ao criar um padrão universal, os desenvolvedores só precisam criar M clientes (para os aplicativos) e N servidores (para as ferramentas), reduzindo a complexidade e a sobrecarga de manutenção.

O MCP não é uma alternativa a padrões populares como RAG (Retrieval-Augmented Generation) ou frameworks como o LangChain; é um protocolo de conectividade fundamental que os torna mais poderosos, modulares e fáceis de manter. Ele resolve o problema universal de conectar um aplicativo a uma ferramenta externa padronizando a "última etapa" da integração.

Veja como o MCP se integra à pilha moderna de IA:

Alimentando o RAG avançado

O RAG padrão é poderoso, mas normalmente se conecta a um banco de dados vetorial estático. Para casos de uso mais avançados, é necessário recuperar informações dinâmicas de sistemas complexos e em tempo real.

• Sem MCP: um desenvolvedor precisa escrever um código personalizado para conectar o aplicativo RAG diretamente à linguagem de consulta específica de uma API de pesquisa, como o Elasticsearch.
• Com o MCP: o sistema de busca expõe as capacidades por meio de um servidor MCP padrão. O aplicativo RAG agora pode consultar essa fonte de dados ao vivo usando um cliente MCP simples e reutilizável, sem precisar conhecer a API específica do sistema subjacente. Isso torna a implementação do RAG mais limpa e mais fácil de substituir por outras fontes de dados no futuro.

Integração com frameworks independentes (por exemplo, LangChain, LangGraph)

Os frameworks independentes oferecem excelentes ferramentas para criar lógica de aplicativos, mas ainda precisam de uma maneira de se conectar a ferramentas externas.

• As alternativas:
  • Código personalizado: desenvolver uma integração direta do zero, o que demanda um esforço significativo de engenharia e manutenção contínua
  • Kits de ferramentas específicos para frameworks: usar um conector pré-criado ou escrever um wrapper personalizado para um framework específico (isso cria uma dependência da arquitetura desse framework e prende você ao ecossistema dele).
• A vantagem do MCP: o MCP oferece um padrão aberto e universal. Um fornecedor de ferramentas pode criar um único servidor MCP para o seu produto. Agora, qualquer framework, LangChain, LangGraph ou uma solução personalizada, pode interagir com esse servidor usando um cliente MCP genérico. Essa abordagem é mais eficiente e evita a dependência de fornecedores.

Por que um protocolo simplifica tudo

Por fim, o valor do MCP está em oferecer uma alternativa aberta e padronizada aos dois extremos da integração:

1. Escrever um código personalizado é algo frágil e acarreta altos custos de manutenção.
2. O uso de wrappers específicos para frameworks cria um ecossistema semifechado bem como a dependência de fornecedores.

O MCP transfere a responsabilidade pela integração para o proprietário do sistema externo, permitindo que ele forneça um único endpoint MCP estável. Os desenvolvedores de aplicativos podem então consumir esses endpoints, simplificando muito o trabalho necessário para criar, redimensionar e manter aplicativos de IA poderosos e sensíveis ao contexto.

Como: implementar um servidor MCP do Elasticsearch

A Elastic desenvolveu um servidor MCP para o Elasticsearch que permite conectar de forma fácil seus dados a qualquer host compatível com MCP. Com o servidor, é possível conceder aos modelos acesso para consultar índices, inspecionar mapeamentos e realizar buscas.

Configurar o servidor é simples. Este servidor MCP é fornecido como uma imagem Docker em docker.elastic.co/mcp/elasticsearch compatível com os protocolos stdio, SSE e streamable-HTTP do MCP.

A configuração do Claude Desktop é a seguinte:

{
 "mcpServers": {
   "elasticsearch-mcp-server": {
    "command": "docker",
    "args": [
     "run", "-i", "--rm",
     "-e", "ES_URL", "-e", "ES_API_KEY",
     "docker.elastic.co/mcp/elasticsearch",
     "stdio"
    ],
    "env": {
      "ES_URL": "<elasticsearch-cluster-url>",
      "ES_API_KEY": "<elasticsearch-api-key>"
    }
   }
 }
}

O servidor MCP é iniciado no modo stdio com este comando:

docker run -i --rm -e ES_URL -e ES_API_KEY docker.elastic.co/mcp/elasticsearch stdio

Siga as demais etapas conforme nosso repositório no GitHub.

Aprofunde-se mais na criação com a Elastic

Fique por dentro de tudo relacionado à IA e aos aplicativos de busca inteligente. Conheça nossos recursos para aprender mais sobre como criar usando a Elastic.

• Funções do LLM com o Elasticsearch para transformação inteligente de consultas
• Agentes de IA e o Elastic AI SDK para Python
• Protocolo de Contexto de Modelo para Elasticsearch

Comece a criar agora com o workshop prático gratuito "Introdução ao MCP com o Elasticsearch MCP Server".