MCP em Python: Guia Completo (2026) |

Introdução: Por Que o MCP Está Redefinindo a Integração de IA em 2026

Se você acompanhou nossos guias anteriores sobre Function Calling e Tool Use em Agentes de IA, Pipelines RAG em Produção e Sistemas Multi-Agentes, já deve ter notado um padrão bem irritante: cada provedor de LLM implementa a integração com ferramentas externas do seu próprio jeito. OpenAI tem o formato de function calling deles, Anthropic tem o tool use, Google tem o deles — e você, que é desenvolvedor, fica no meio disso tudo, reescrevendo código toda santa vez que troca de modelo ou precisa plugar uma ferramenta nova.

É exatamente esse problema que o Model Context Protocol (MCP) resolve.

Lançado pela Anthropic em novembro de 2024, o MCP se tornou em menos de dois anos o padrão universal de integração entre LLMs e ferramentas externas. A analogia mais direta (e que todo mundo usa, com razão) é o USB-C: assim como o USB-C padronizou a conexão de dispositivos a periféricos, o MCP padroniza a conexão de modelos de IA a fontes de dados, APIs e sistemas externos. Os números falam por si: os downloads de servidores MCP saltaram de cerca de 100 mil em novembro de 2024 para mais de 8 milhões em abril de 2025. Hoje, em março de 2026, já são mais de 5.800 servidores MCP e 300 clientes MCP disponíveis no ecossistema.

A adoção corporativa também impressiona bastante. Block, Bloomberg, Amazon e centenas de empresas Fortune 500 já usam MCP em produção. Em dezembro de 2025, o protocolo foi doado para a Agentic AI Foundation sob a Linux Foundation, o que garante governança neutra — ninguém controla o protocolo sozinho. E segundo a Gartner, até o final de 2026, 75% dos fornecedores de API gateway e 50% dos fornecedores de iPaaS terão funcionalidades MCP integradas.

Neste guia, vamos do conceito à implementação completa. Você vai entender a arquitetura do MCP, construir servidores e clientes em Python, implementar autenticação OAuth 2.1 para produção e aprender os padrões de segurança que a OWASP recomenda. Então, bora.

O Que é o Model Context Protocol e Por Que Ele Importa

Antes do MCP, integrar um LLM com ferramentas externas significava enfrentar o que a Anthropic chamou de problema N×M: para cada novo modelo (N) e cada nova ferramenta (M), você precisava escrever uma integração customizada. Três modelos e dez ferramentas? Trinta integrações pra manter. Adicionou um modelo novo? Mais dez. Uma ferramenta nova? Mais três. Dá pra sentir a dor só de ler, né?

O MCP transforma esse problema N×M em N+M. Cada modelo implementa o protocolo uma vez (como cliente), cada ferramenta implementa uma vez (como servidor), e tudo se conecta. É o mesmo princípio que fez protocolos como HTTP e SMTP funcionarem — padronização reduz complexidade exponencialmente.

MCP vs Function Calling: Qual a Diferença Real?

Essa é de longe a pergunta que mais aparece, então vou ser direto. Function calling e MCP não são concorrentes — são complementares. O function calling é o mecanismo pelo qual um LLM decide invocar uma ferramenta. O MCP é o protocolo que padroniza como essa ferramenta é descoberta, invocada e gerenciada.

Pense assim: function calling é como uma tomada na parede. MCP é o padrão elétrico que garante que qualquer aparelho funcione em qualquer tomada. Faz sentido?

Aspecto	Function Calling	MCP
Arquitetura	Embutido na requisição ao LLM	Protocolo cliente-servidor separado
Acoplamento	Fortemente acoplado à aplicação	Desacoplado e modular
Portabilidade	Específico do provedor	Universal, cross-provider
Escalabilidade	Limitada	Alta
Complexidade inicial	Baixa	Moderada
Manutenção a longo prazo	Alta (cada integração separada)	Baixa (construa uma vez, use em qualquer lugar)

Quando usar function calling puro: protótipos rápidos, 2-3 funções simples, aplicação pequena que vai ficar com um único provedor.

Quando usar MCP: sistemas em produção, múltiplas ferramentas, necessidade de trocar ou combinar provedores de LLM, equipes grandes.

Quando usar ambos: honestamente, a maioria dos sistemas maduros usa os dois. O LLM usa function calling pra decidir qual ferramenta chamar, e o MCP cuida de como essa chamada é roteada, autenticada e executada. É uma combinação que funciona muito bem na prática.

Arquitetura do MCP: Host, Client e Server

A arquitetura do MCP segue um modelo cliente-servidor com três componentes distintos. Entender cada um deles é fundamental pra construir sistemas robustos — e evitar confusões que eu já vi acontecerem em mais de um projeto.

MCP Host

O Host é a aplicação que contém o LLM e apresenta a interface ao usuário. Pense no Claude Desktop, IDEs com extensões de IA (como VS Code com Copilot), ou a sua própria aplicação customizada. O Host é responsável por:

Gerenciar a interação com o usuário
Processar requisições usando o LLM
Instanciar e gerenciar um ou mais MCP Clients
Decidir quais servidores MCP o LLM pode acessar

MCP Client

O Client fica dentro do Host e funciona como um tradutor bidirecional entre o LLM e os servidores MCP. Um detalhe importante: cada Client mantém uma conexão 1:1 com um servidor específico. Então se seu Host precisa se conectar a 5 servidores MCP diferentes, ele instancia 5 clientes. Simples assim.

MCP Server

O Server é o componente que expõe ferramentas, recursos e dados pro LLM. Ele se conecta a sistemas externos — bancos de dados, APIs, sistemas de arquivos — e os torna acessíveis através de uma interface padronizada. Um servidor MCP expõe três primitivas fundamentais:

Tools (Ferramentas): funções que o LLM pode chamar pra executar ações — consultar uma API, fazer um cálculo, enviar um e-mail
Resources (Recursos): dados somente leitura que podem ser consumidos pelo LLM — arquivos, registros de banco de dados, respostas de API
Prompts: templates reutilizáveis que definem padrões de interação pra tarefas específicas

Camada de Transporte

A comunicação entre client e server usa JSON-RPC 2.0 sobre dois métodos de transporte principais:

STDIO (Standard Input/Output): ideal pra servidores locais, oferece transmissão rápida e síncrona. Client e server rodam na mesma máquina.
Streamable HTTP: preferido pra servidores remotos, permite que servidores MCP rodem como serviços web escaláveis. Substituiu o SSE (Server-Sent Events) como transporte remoto padrão na versão atualizada do protocolo.

Construindo Seu Primeiro Servidor MCP em Python

Chega de teoria — vamos ao código. Vamos construir um servidor MCP que expõe ferramentas para consultar dados de clima de uma API externa. Escolhi esse exemplo porque demonstra os conceitos fundamentais (definição de tools, chamadas HTTP assíncronas, tratamento de erros) sem complicar desnecessariamente.

Passo 1: Configurando o Ambiente

Você vai precisar do Python 3.10 ou superior. Vamos usar o uv como gerenciador de pacotes — é o recomendado pela documentação oficial do MCP e, sinceramente, é bem mais rápido que o pip.

# Crie um novo projeto
uv init mcp-weather-server
cd mcp-weather-server

# Crie e ative o ambiente virtual
uv venv
source .venv/bin/activate

# Instale o SDK MCP com dependências CLI
uv add "mcp[cli]" httpx

A estrutura do projeto fica assim:

mcp-weather-server/
├── server.py          # Servidor MCP principal
├── pyproject.toml     # Dependências do projeto
└── .venv/             # Ambiente virtual

Passo 2: Criando o Servidor com FastMCP

O FastMCP é a interface de alto nível do SDK Python pra criar servidores MCP. A parte legal é que ele usa type hints e docstrings do Python pra gerar automaticamente os schemas das ferramentas — zero necessidade de escrever JSON Schema na mão.

import sys
import httpx
from mcp.server.fastmcp import FastMCP

# Inicializa o servidor MCP
mcp = FastMCP(
    name="weather-server",
    version="1.0.0"
)

# URL base da API de clima (exemplo com Open-Meteo, gratuita e sem chave)
GEOCODING_URL = "https://geocoding-api.open-meteo.com/v1/search"
WEATHER_URL = "https://api.open-meteo.com/v1/forecast"


@mcp.tool()
async def get_weather(city: str) -> str:
    """Obtém a previsão do tempo atual para uma cidade.

    Args:
        city: Nome da cidade (ex: "São Paulo", "Lisboa", "Tokyo")

    Returns:
        String formatada com temperatura, umidade e condição do tempo.
    """
    async with httpx.AsyncClient(timeout=10.0) as client:
        # Primeiro, busca as coordenadas da cidade
        geo_response = await client.get(
            GEOCODING_URL,
            params={"name": city, "count": 1, "language": "pt"}
        )
        geo_response.raise_for_status()
        geo_data = geo_response.json()

        if not geo_data.get("results"):
            return f"Cidade '{city}' não encontrada."

        location = geo_data["results"][0]
        lat = location["latitude"]
        lon = location["longitude"]
        city_name = location.get("name", city)
        country = location.get("country", "")

        # Agora busca o clima atual
        weather_response = await client.get(
            WEATHER_URL,
            params={
                "latitude": lat,
                "longitude": lon,
                "current": "temperature_2m,relative_humidity_2m,wind_speed_10m,weather_code",
                "timezone": "auto"
            }
        )
        weather_response.raise_for_status()
        weather_data = weather_response.json()

        current = weather_data["current"]
        temp = current["temperature_2m"]
        humidity = current["relative_humidity_2m"]
        wind = current["wind_speed_10m"]

        return (
            f"Clima em {city_name}, {country}:\n"
            f"Temperatura: {temp}°C\n"
            f"Umidade: {humidity}%\n"
            f"Vento: {wind} km/h"
        )


@mcp.tool()
async def compare_weather(city_a: str, city_b: str) -> str:
    """Compara o clima atual entre duas cidades.

    Args:
        city_a: Primeira cidade para comparação
        city_b: Segunda cidade para comparação

    Returns:
        Comparação formatada entre as duas cidades.
    """
    result_a = await get_weather(city_a)
    result_b = await get_weather(city_b)

    return f"--- Comparação de Clima ---\n\n{result_a}\n\n---\n\n{result_b}"


if __name__ == "__main__":
    mcp.run(transport="stdio")

Alguns pontos importantes sobre esse código:

O decorador @mcp.tool() registra a função como uma ferramenta MCP. O FastMCP extrai automaticamente o nome, descrição (da docstring) e parâmetros (dos type hints)
Usamos async/await porque operações de I/O como chamadas HTTP devem ser assíncronas pra manter o servidor responsivo
O httpx.AsyncClient com timeout de 10 segundos previne travamentos caso a API externa demore demais ou não responda

Passo 3: Adicionando Resources

Além de ferramentas, podemos expor recursos — dados somente leitura que o LLM pode consultar. Vamos adicionar um resource que lista as cidades mais consultadas:

# Adicione ao server.py, antes do if __name__

@mcp.resource("weather://popular-cities")
def get_popular_cities() -> str:
    """Lista as cidades mais populares para consulta de clima."""
    cities = [
        "São Paulo, Brasil",
        "Lisboa, Portugal",
        "Nova York, EUA",
        "Londres, Reino Unido",
        "Tóquio, Japão"
    ]
    return "\n".join(f"- {city}" for city in cities)


@mcp.resource("weather://config/{parameter}")
def get_weather_config(parameter: str) -> str:
    """Retorna informações de configuração do servidor de clima.

    Args:
        parameter: O parâmetro de configuração desejado
                   (api_version, supported_units, update_frequency)
    """
    config = {
        "api_version": "1.0.0",
        "supported_units": "metric (Celsius, km/h)",
        "update_frequency": "Dados atualizados a cada 15 minutos"
    }
    return config.get(parameter, f"Parâmetro '{parameter}' não encontrado.")

Recursos estáticos usam URIs fixos como weather://popular-cities. Já recursos dinâmicos usam templates de URI como weather://config/{parameter}, onde o parâmetro é extraído automaticamente. Na prática, resources são perfeitos pra dados de configuração e referência que o LLM pode precisar consultar durante a conversa.

Passo 4: Testando com o MCP Inspector

O SDK MCP inclui uma ferramenta visual de teste chamada MCP Inspector que facilita muito a vida durante o desenvolvimento. Basta executar:

# Modo de desenvolvimento com Inspector
mcp dev server.py

Isso abre uma interface web em http://localhost:6274 onde você pode visualizar todas as tools e resources expostos, testar cada ferramenta com parâmetros reais e ver as mensagens JSON-RPC trocadas entre client e server. É uma mão na roda pra depurar problemas.

Quando tiver tudo funcionando, execute em modo produção:

# Executar diretamente
mcp run server.py

# Ou instalar no Claude Desktop
mcp install server.py

Construindo um Cliente MCP em Python

Agora vamos pro outro lado da equação: construir um cliente que se conecta a qualquer servidor MCP e usa suas ferramentas. Essa parte é essencial quando você tá construindo sua própria aplicação de IA e quer integrar servidores MCP existentes.

import asyncio
import json
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client


async def main():
    # Configuração do servidor ao qual vamos nos conectar
    server_params = StdioServerParameters(
        command="uv",
        args=["run", "server.py"],
        env=None
    )

    # Conecta ao servidor MCP via STDIO
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            # Inicializa a conexão (handshake do protocolo)
            await session.initialize()

            # Lista todas as ferramentas disponíveis
            tools_result = await session.list_tools()
            print("Ferramentas disponíveis:")
            for tool in tools_result.tools:
                print(f"  - {tool.name}: {tool.description}")

            # Lista todos os recursos disponíveis
            resources_result = await session.list_resources()
            print("\nRecursos disponíveis:")
            for resource in resources_result.resources:
                print(f"  - {resource.uri}: {resource.name}")

            # Chama a ferramenta get_weather
            print("\n--- Chamando get_weather ---")
            result = await session.call_tool(
                "get_weather",
                arguments={"city": "São Paulo"}
            )
            print(result.content[0].text)

            # Lê um recurso
            print("\n--- Lendo recurso popular-cities ---")
            resource_data = await session.read_resource(
                "weather://popular-cities"
            )
            print(resource_data.contents[0].text)


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

O fluxo é bem direto: cria uma sessão, inicializa o handshake, descobre ferramentas e recursos disponíveis, e faz chamadas. O detalhe mais legal aqui é que o cliente não precisa saber antecipadamente quais ferramentas o servidor oferece — ele descobre tudo dinamicamente via list_tools(). Essa é uma das maiores vantagens do MCP sobre function calling tradicional.

Conectando ao Claude Desktop

Uma das formas mais práticas de usar seu servidor MCP é conectá-lo ao Claude Desktop. A configuração é simples — basta editar o arquivo de configuração do cliente:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "weather-server": {
      "command": "uv",
      "args": [
        "--directory", "/caminho/absoluto/para/mcp-weather-server",
        "run", "server.py"
      ]
    }
  }
}

Salve o arquivo e reinicie o Claude Desktop. Você vai ver um ícone de ferramentas indicando que o servidor MCP tá conectado. A partir daí, é só perguntar ao Claude algo como "Qual o clima em Lisboa?" e ele vai usar automaticamente a ferramenta get_weather do seu servidor. A primeira vez que você vê isso funcionando é bem satisfatório, devo admitir.

Servidor MCP Remoto com Streamable HTTP

O transporte STDIO funciona bem pra servidores locais, mas em produção você geralmente precisa de servidores remotos acessíveis via rede. O Streamable HTTP é o transporte recomendado pra esse cenário — ele substituiu o SSE que era usado nas versões anteriores do protocolo.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP(
    name="weather-server-remote",
    version="1.0.0",
    host="0.0.0.0",
    port=8080
)


# ... definições de tools e resources (mesmas de antes) ...


if __name__ == "__main__":
    mcp.run(transport="streamable-http")

Com o transporte HTTP, o servidor expõe um endpoint em http://localhost:8080/mcp que qualquer cliente MCP compatível pode acessar. Isso abre possibilidades como balanceamento de carga, deploy em containers e integração com API gateways.

Atenção importante: nunca exponha um servidor MCP com 0.0.0.0 sem autenticação em produção. Isso não é paranoia — pesquisadores escanearam quase 2.000 servidores MCP acessíveis publicamente e descobriram que todos permitiam acesso às listagens de ferramentas internas sem qualquer autenticação. Todos mesmo.

Segurança e Autenticação: OAuth 2.1 para Produção

Segurança é provavelmente o aspecto mais negligenciado dos servidores MCP — e, ironicamente, o mais crítico. A especificação MCP atualizada em junho de 2025 classificou servidores MCP como servidores de recurso OAuth 2.1, estabelecendo um padrão claro de autenticação. Ainda assim, uma pesquisa recente revelou que apenas 8,5% dos servidores MCP implementam um modelo de autenticação seguro e moderno. Dá pra fazer melhor que isso.

Implementando OAuth 2.1 com FastMCP

O FastMCP 3.0 trouxe suporte nativo a autenticação, o que facilita bastante. Veja como configurar:

from mcp.server.fastmcp import FastMCP
from fastmcp.server.auth import BearerTokenProvider

# Configuração com autenticação OAuth
mcp = FastMCP(
    name="weather-server-secure",
    version="1.0.0",
    auth=BearerTokenProvider(
        jwks_url="https://seu-provider.auth0.com/.well-known/jwks.json",
        issuer="https://seu-provider.auth0.com/",
        audience="https://api.seu-app.com"
    )
)


@mcp.tool()
async def get_weather(city: str, ctx=None) -> str:
    """Obtém a previsão do tempo para uma cidade (autenticado)."""
    # Verifica permissões do usuário via contexto
    if ctx and ctx.user:
        print(f"Requisição de: {ctx.user.sub}", file=sys.stderr)
    # ... lógica de clima ...
    return "Dados do clima"

Princípios de Segurança Essenciais da OWASP para MCP

A OWASP publicou um guia dedicado à segurança de servidores MCP que vale a pena ler na íntegra. Mas aqui estão os princípios que considero mais importantes:

Elimine credenciais estáticas: quase metade dos servidores MCP em produção armazena chaves de API em arquivos .env não criptografados. Use OAuth com tokens de curta duração e rotação automática
Autorização no nível da ferramenta: não basta autenticar o usuário no servidor — implemente RBAC (controle de acesso baseado em papel) pra cada ferramenta individualmente. Um atendente pode consultar dados de conta, mas não deveria poder modificar cobranças
Proteção contra SSRF: valide todas as URLs recebidas, rejeite http:// em produção (exceto loopback), e implemente allowlists pra domínios externos
Defesa contra prompt injection: sanitize inputs, valide schemas com Pydantic, e implemente rate limiting pra detectar scanning malicioso
IDs de sessão seguros: use geradores de números aleatórios criptograficamente seguros (como secrets.token_urlsafe()), nunca IDs sequenciais ou previsíveis

Checklist de Segurança para Produção

# checklist_seguranca_mcp.py
"""
Checklist de segurança para servidores MCP em produção:

[x] OAuth 2.1 com tokens de curta duração
[x] HTTPS obrigatório (exceto localhost em dev)
[x] RBAC por ferramenta, não apenas por servidor
[x] Validação de input com Pydantic em todas as tools
[x] Rate limiting por usuário/IP
[x] Logging estruturado (sem dados sensíveis)
[x] Health check endpoint
[x] Variáveis de ambiente via secrets manager (não .env)
[x] Session IDs com secrets.token_urlsafe()
[x] Proteção contra SSRF em chamadas externas
"""

Padrões Avançados para Produção

Composição de Servidores

Em sistemas mais complexos, você vai acabar tendo múltiplos servidores MCP — um pra clima, outro pra banco de dados, outro pra e-mail, e por aí vai. O FastMCP permite compor servidores usando o método import_server, o que simplifica bastante a organização:

from mcp.server.fastmcp import FastMCP

# Servidor principal que agrega outros
gateway = FastMCP(name="api-gateway", version="1.0.0")

# Importa ferramentas de servidores especializados
# Cada servidor mantém suas próprias tools e resources
weather_server = FastMCP(name="weather")
db_server = FastMCP(name="database")

# ... defina tools em cada servidor ...

gateway.import_server("weather", weather_server)
gateway.import_server("db", db_server)

if __name__ == "__main__":
    gateway.run(transport="streamable-http")

Isso cria um ponto único de entrada que expõe ferramentas de múltiplos domínios. Na prática, facilita muito a governança e o controle de acesso centralizado — especialmente quando a equipe cresce.

Context API: Progresso e Logging

Pra ferramentas que demoram a executar (e acredite, em produção elas vão demorar), o MCP oferece a Context API pra reportar progresso ao cliente:

from mcp.server.fastmcp import FastMCP, Context

mcp = FastMCP(name="data-processor")


@mcp.tool()
async def process_large_dataset(file_path: str, ctx: Context) -> str:
    """Processa um dataset grande com reporte de progresso."""
    total_steps = 100

    for i in range(total_steps):
        # Reporta progresso ao cliente
        await ctx.report_progress(
            progress=i,
            total=total_steps
        )

        # Logging seguro (vai para stderr, não stdout)
        await ctx.info(f"Processando batch {i + 1}/{total_steps}")

        # ... processamento real aqui ...

    return f"Dataset processado: {total_steps} batches concluídos."

Cuidado crítico com logging: em servidores STDIO, nunca use print() sem redirecionar pra sys.stderr. Eu sei que parece um detalhe bobo, mas o print() padrão escreve em stdout, que é exatamente o canal de comunicação JSON-RPC. Escrever nele corrompe as mensagens e quebra o servidor inteiro. Use sempre ctx.info(), ctx.warning() ou print(..., file=sys.stderr). Já vi gente perder horas debugando por causa disso.

Middleware: Cache e Rate Limiting

O FastMCP 3.0 trouxe middlewares que podem ser encadeados pra adicionar funcionalidades transversais:

from mcp.server.fastmcp import FastMCP
from fastmcp.server.middleware import (
    ResponseCachingMiddleware,
    ResponseLimitingMiddleware
)

mcp = FastMCP(
    name="weather-server-cached",
    version="1.0.0",
    middleware=[
        # Cache de respostas por 5 minutos
        ResponseCachingMiddleware(ttl_seconds=300),
        # Limita tamanho das respostas a 10KB
        ResponseLimitingMiddleware(max_size_bytes=10240)
    ]
)

O cache é particularmente útil pra ferramentas que fazem chamadas a APIs externas — evita requisições duplicadas e reduz latência de forma significativa. No caso de um servidor de clima, faz todo sentido cachear por 5 ou 10 minutos, já que a previsão não muda a cada segundo.

Ecossistema MCP em 2026: O Que Mudou

O ecossistema MCP amadureceu num ritmo que poucos esperavam. Aqui estão os marcos mais relevantes pra quem tá construindo com MCP em 2026:

Adoção universal: OpenAI adotou oficialmente o MCP em março de 2025. Google DeepMind e Microsoft seguiram. Hoje, todos os principais provedores de LLM suportam MCP nativamente
Governança neutra: a transferência pra Linux Foundation (Agentic AI Foundation) em dezembro de 2025 garantiu que nenhum fornecedor controla o protocolo sozinho
FastMCP 3.0: lançado em janeiro de 2026, trouxe versionamento de componentes, autorização granular, instrumentação OpenTelemetry e múltiplos providers (FileSystem, Skills, OpenAPI)
Roadmap 2026: as quatro prioridades são escalabilidade de transporte, prontidão empresarial (audit trails, SSO), maturação da governança e comunicação entre agentes
70% dos servidores MCP em todas as linguagens usam alguma versão do FastMCP — o que diz muito sobre a qualidade da ferramenta
SDKs oficiais disponíveis em Python, TypeScript, C# (com Microsoft), Java (com Spring AI), PHP e Rust

Roadmap de Aprendizado: Do Iniciante ao Avançado

Se você tá começando com MCP agora, aqui vai uma progressão que faz sentido, baseada nos conceitos que cobrimos neste guia e nos artigos anteriores da série:

Function Calling Básico: entenda como LLMs invocam ferramentas (dá uma olhada no nosso guia sobre Function Calling e Tool Use)
Primeiro Servidor MCP: construa um servidor simples com 1-2 ferramentas usando FastMCP e STDIO
Integração com Claude Desktop: conecte seu servidor ao Claude Desktop pra testar de forma interativa
Servidor Remoto: migre pra Streamable HTTP e adicione autenticação OAuth 2.1
RAG + MCP: combine pipelines RAG (veja nosso guia de RAG em Produção) com servidores MCP pra criar agentes que buscam e processam informação
Multi-Agente + MCP: use MCP como camada de integração pra sistemas multi-agentes (veja nosso guia de Sistemas Multi-Agentes)

Perguntas Frequentes (FAQ)

O que é o Model Context Protocol (MCP) e para que serve?

O Model Context Protocol (MCP) é um protocolo aberto criado pela Anthropic que padroniza a forma como modelos de linguagem (LLMs) se conectam a ferramentas externas, bancos de dados e APIs. A analogia do "USB-C para IA" é batida mas certeira — em vez de criar integrações customizadas pra cada combinação de modelo e ferramenta, o MCP define uma interface universal. Isso reduz drasticamente o esforço de desenvolvimento e permite que a mesma ferramenta funcione com qualquer LLM compatível.

Qual a diferença entre MCP e function calling?

Function calling é o mecanismo pelo qual um LLM decide chamar uma função externa — tá embutido na API do provedor e é específico pra cada um (OpenAI, Anthropic, Google). O MCP é um protocolo cliente-servidor que padroniza como essas chamadas são descobertas, roteadas e executadas, independentemente do provedor. Na prática, eles funcionam juntos: o LLM usa function calling pra decidir o que chamar, e o MCP cuida de como a chamada é feita.

Preciso de autenticação no meu servidor MCP?

Pra desenvolvimento local com transporte STDIO, não — o servidor roda na sua máquina e se comunica diretamente com o host. Mas pra qualquer servidor remoto acessível via rede, autenticação é obrigatória. A especificação MCP define OAuth 2.1 como o padrão. Pesquisadores encontraram que praticamente todos os servidores MCP públicos sem autenticação permitiam acesso irrestrito às ferramentas internas. Não vale o risco.

É possível usar MCP com OpenAI, Google e outros provedores além do Claude?

Sim, com certeza. Embora o MCP tenha sido criado pela Anthropic, é um protocolo aberto e agnóstico de provedor. A OpenAI adotou oficialmente o MCP em março de 2025, e Google DeepMind e Microsoft também já o suportam. O SDK da OpenAI pra agentes (openai-agents-python) inclui suporte nativo a clientes MCP. Essa interoperabilidade é justamente uma das maiores vantagens do protocolo.

Qual a diferença entre STDIO e Streamable HTTP como transporte MCP?

STDIO (Standard Input/Output) é ideal pra servidores locais que rodam na mesma máquina que o host — é rápido, simples e não precisa de configuração de rede. Streamable HTTP é o transporte pra servidores remotos, permitindo que múltiplos clientes se conectem via rede, com suporte a balanceamento de carga e deploy em containers. Regra simples: pra desenvolvimento e protótipos, use STDIO. Pra produção com múltiplos usuários, use Streamable HTTP com autenticação OAuth 2.1.