O Protocolo de Contexto do Modelo (MCP): o que é e como construir um servidor

O aplicativo da sua equipe, alimentado por LLM, se comunica com um índice de busca através de uma integração personalizada, um repositório de código através de outra, um banco de dados Postgres através de uma cadeia de ferramentas LangChain, e um sistema de arquivos através de chamadas de I/O em Python puro. Cada nova fonte de dados significa escrever uma nova integração. Cada integração usa um modelo de autenticação diferente e retorna dados em uma forma diferente. O aplicativo LLM está intimamente ligado a cada backend que toca, e trocar um requer mudar o código do aplicativo diretamente.

O Protocolo de Contexto do Modelo (MCP) existe para substituir essa tubulação sob medida por uma única interface padronizada. Pense nisso como uma porta USB-C para aplicativos LLM: uma forma de conector, um protocolo, e qualquer servidor compatível pode se conectar a qualquer cliente compatível sem fiação personalizada.

Por que um protocolo padrão é importante

As ferramentas alimentadas por LLM explodiram em capacidade nos últimos dois anos, mas a história da integração não acompanhou. Cada aplicativo de IA (assistente de IDE, cliente de chat, estrutura de agente) historicamente construiu seus próprios conectores para bancos de dados, APIs, armazenamentos de documentos e repositórios de código. Não havia um contrato compartilhado. Se você quisesse usar uma ferramenta de busca de código específica com dois assistentes de IA diferentes, precisaria de duas integrações separadas.

O MCP empresta sua filosofia de design do Protocolo de Servidor de Linguagem (LSP), que padronizou como editores de código se comunicam com analisadores de linguagem. Antes do LSP, cada editor tinha seu próprio plugin para cada linguagem. Após o LSP, um servidor de linguagem funcionava com todos os editores. O MCP visa fazer o mesmo para ferramentas de IA e as fontes de dados que elas precisam.

O protocolo é um padrão aberto, criado originalmente na Anthropic e publicado sob a licença MIT. A especificação alcançou estabilidade na versão 2025-11-25, e o SDK Python (mcp no PyPI) está na versão 1.27.2 em maio de 2026. Uma versão alpha 2.0.0 foi publicada em junho de 2026 com uma camada de transporte atualizada.

Como o MCP funciona

O MCP usa JSON-RPC 2.0 como seu formato de mensagem. Um cliente (o aplicativo de IA) se conecta a um servidor (um serviço que fornece contexto) através de um dos três tipos de transporte:

• stdio: o cliente gera o servidor como um processo filho e se comunica através de stdin/stdout. Melhor para configurações locais de usuário único.
• SSE (Eventos Enviados pelo Servidor): o servidor funciona como um endpoint HTTP, o cliente se conecta via HTTP. Funciona entre máquinas.
• HTTP Streamable: um transporte mais recente que permite streaming bidirecional via HTTP. Adicionado na especificação de 2025-11-25.

Aqui está a arquitetura conceitual:

flowchart LR
    subgraph Client["Cliente (App de IA)"]
        A["Host<br/>IDE / Chat / Agente"]
        B["Cliente MCP<br/>Manipulador de protocolo"]
    end
    subgraph Server["Servidor MCP"]
        C["Servidor MCP<br/>Manipulador de protocolo"]
        D["Recursos<br/>dados de contexto"]
        E["Ferramentas<br/>funções executáveis"]
        F["Prompts<br/>fluxos de trabalho modelados"]
    end
    A <--> B
    B <-->|JSON-RPC 2.0<br/>stdio / SSE / HTTP| C
    C --> D
    C --> E
    C --> F

Cada sessão MCP começa com um aperto de mão de negociação de capacidade. O cliente anuncia quais recursos suporta (amostragem, raízes, elicitação). O servidor anuncia quais recursos oferece (recursos, ferramentas, prompts). Ambos os lados concordam com um conjunto de recursos antes que qualquer troca de dados aconteça.

Primitivas do servidor

Os servidores oferecem três categorias principais de funcionalidade:

Recursos expõem dados para o LLM. Pense neles como endpoints GET em uma API REST. Um recurso tem um URI e retorna conteúdo em um formato estruturado. Exemplo: file:///logs/2026-06-01.txt retorna o conteúdo desse arquivo de log. Recursos são como o LLM carrega contexto.

Ferramentas são funções que o LLM pode invocar. Pense nelas como endpoints POST. Uma ferramenta tem um nome, uma descrição e um esquema de entrada (JSON Schema). O LLM pode chamar uma ferramenta para executar código, consultar um banco de dados ou acionar uma ação externa. Ao contrário dos recursos, as ferramentas são invocadas sob demanda.

Prompts são templates reutilizáveis para interações com LLM. Um prompt define um template de mensagem com slots de parâmetro. O cliente pode preencher o template e apresentar o resultado ao usuário como uma interação pré-construída.

Primitivas do cliente

Os clientes também podem oferecer recursos aos servidores:

• Amostragem: o servidor pode solicitar que o cliente gere uma resposta do LLM, permitindo loops agentes onde um modelo delega a outro.
• Raízes: o servidor pode solicitar informações sobre limites de sistema de arquivos ou URI, para que saiba onde pode operar.
• Elicitação: o servidor pode solicitar informações adicionais do usuário através da interface do cliente.

Construindo um servidor MCP em Python

O pacote mcp (v1.27.2) fornece uma API de alto nível chamada FastMCP que torna a construção de um servidor simples. Aqui está um servidor completo que expõe uma ferramenta de clima e um recurso de saudação:

from mcp.server.fastmcp import FastMCP

# Crie um servidor MCP
mcp = FastMCP("Demonstração do Clima")

# Adicione uma ferramenta: obter clima para uma cidade
@mcp.tool()
def get_weather(city: str, units: str = "celsius") -> str:
    """Obtenha o clima atual para uma cidade."""
    # Em produção, chame uma API de clima real aqui
    return f"Clima em {city}: 22 graus {units}, parcialmente nublado"

# Adicione um recurso: dados da cidade por URI
@mcp.resource("city://{name}")
def city_info(name: str) -> str:
    """Obtenha informações sobre uma cidade."""
    cities = {
        "dubai": "Dubai, EAU. Po