MCP Transformou Minha IA de Chatbot em um Agente Real

Fiquei encarando minha tela por uns trinta segundos, genuinamente confuso.

O Claude tinha acabado de criar uma nota no meu cofre do Obsidian — não porque eu copiei e colei texto, não porque usei alguma integração do Zapier — mas porque eu pedi. Em português simples. "Crie uma nota sobre café de prensa francesa." E lá estava, no meu cofre como se eu mesmo tivesse escrito.

Isso foi há três semanas. Desde então, conectei o Claude ao meu gerenciador de tarefas, meu calendário, um web scraper, transcrições do YouTube e — não estou exagerando — Kali Linux. Minha IA agora pode hackear por mim. Bom, mais ou menos. Mas o ponto é válido: algo fundamental mudou, e a maioria dos desenvolvedores com quem converso ainda não percebeu.

A mudança tem nome. Chama-se MCP — o Model Context Protocol. E quando você entende o que ele faz, percebe que a distância entre "chatbot de IA" e "agente de IA" não é algum problema de pesquisa distante. É um arquivo de configuração.

Eis o que eu não esperava: a parte mais difícil não foi a tecnologia. A parte mais difícil foi desaprender como eu pensava sobre IA.

O Problema Sobre o Qual Ninguém Fala

Assisti recentemente à análise do NetworkChuck sobre MCP — um mergulho profundo de 38 minutos que já ultrapassou 1,2 milhão de visualizações — e algo que ele disse no início fez clique na minha cabeça de um jeito que meses lendo documentação não tinham conseguido.

Ele comparou LLMs a pessoas. Fique comigo aqui.

Quando você ou eu queremos usar uma ferramenta — digamos, ClickUp para gerenciamento de tarefas — interagimos através de uma interface gráfica. Botões, menus, arrastar e soltar. A GUI abstrai toda a complexidade subjacente. Não precisamos conhecer o esquema do banco de dados nem os endpoints da API. Simplesmente clicamos.

LLMs odeiam GUIs. Tecnicamente podem interagir com elas (existem agentes baseados em screenshots), mas é lento, pouco confiável e parece ensinar alguém a dirigir mostrando fotos de volantes.

Ok, então dê APIs a eles? É para isso que APIs existem — para um programa conversar com outro programaticamente. E sim, funciona. Mas aqui está o problema que o Chuck acertou em cheio: cada API tem centenas de endpoints com esquemas de autenticação únicos, formatos de parâmetros e estruturas de resposta. Só a API do ClickUp é enorme. A do Obsidian também. E a do GitHub. E a de qualquer outra ferramenta que você queira que sua IA use.

Para conectar um LLM a apenas cinco ferramentas via APIs brutas, você precisaria escrever código de integração personalizado para cada uma, lidar com autenticação para cada uma, parsear respostas de cada uma, e então de alguma forma ensinar o LLM quais endpoints chamar e quando.

Já fiz isso. Para um projeto de cliente ano passado, passei duas semanas construindo uma camada personalizada de chamada de ferramentas para o GPT-4 que se conectava a três APIs internas. Duas semanas. Três ferramentas.

O MCP muda essa equação completamente.

O Que o MCP Realmente É (Sem o Hype)

O Model Context Protocol é, em sua essência, uma interface padronizada entre LLMs e ferramentas externas. A Anthropic o criou, mas se tornou um padrão da indústria adotado pela OpenAI, Google e basicamente todas as empresas de ferramentas de IA.

Pense nele como USB-C para ferramentas de IA. Antes do USB-C, cada dispositivo tinha seu próprio conector proprietário. Você precisava de uma gaveta cheia de cabos. O USB-C disse: "Aqui está um padrão. Todo mundo use." O MCP faz a mesma coisa para a comunicação entre LLMs e ferramentas.

Aqui está a arquitetura em termos simples:

LLM (Claude, GPT, Llama)
    ↕ fala o protocolo MCP
MCP Server (roda local ou remotamente)
    ↕ cuida de toda a parte complicada da API
Ferramenta Externa (Obsidian, ClickUp, GitHub, etc.)

O servidor MCP fica entre sua IA e as ferramentas que ela precisa. Ele cuida da autenticação, chamadas de API, parsing de respostas — tudo. O LLM não precisa saber nada sobre endpoints REST ou tokens OAuth. Ele apenas vê uma lista de "ferramentas" disponíveis descritas em linguagem simples:

• create_note — Criar uma nova nota no cofre
• search_vault — Buscar conteúdo em todas as notas
• append_content — Adicionar conteúdo a uma nota existente

O LLM escolhe a ferramenta certa, passa os parâmetros e recebe resultados estruturados. É isso. Sem código personalizado. Sem luta com APIs.

Mas aqui está a parte que me fez prestar muita atenção — e isso conecta com algo muito maior.

De Chatbot a Agente: Os Três Níveis

Enquanto configurava servidores MCP, encontrei a explicação do Jeff Su sobre agentes de IA — um vídeo que já atingiu quase 4 milhões de visualizações — e ela cristalizou algo que eu vinha sentindo mas não conseguia articular.

Jeff divide a IA em três níveis, e uma vez que você os vê, não consegue mais deixar de ver:

Nível 1: LLM Básico. Você dá entrada, obtém saída. Pedir ao ChatGPT para redigir um email? Ótimo. Perguntar quando é sua próxima reunião? Falha. Ele não sabe. Não tem acesso. Apenas gera texto baseado em dados de treinamento.

Nível 2: Fluxo de Trabalho de IA. Você adiciona caminhos predefinidos. "Quando o usuário perguntar sobre eventos do calendário, primeiro consulte o Google Calendar, depois responda." Isso funciona — até o usuário perguntar algo que você não antecipou. "Como está o clima no dia da minha reunião?" Seu fluxo só conhece Google Calendar, não APIs de clima. Cada nova capacidade exige que um humano adicione manualmente outro caminho.

Aqui está o insight chave da análise do Jeff: não importa quantos passos você adicione — centenas, milhares — se um humano é quem decide qual caminho seguir, ainda é apenas um fluxo de trabalho. Não um agente.

Nível 3: Agente de IA. O LLM em si decide o que fazer. Ele raciocina ("Preciso de dados do calendário E dados do clima"), seleciona ferramentas ("Vou usar a API do Google Calendar primeiro, depois um serviço de clima"), executa, avalia o resultado e itera se necessário.

O framework por trás disso se chama ReAct — Reason and Act (Raciocinar e Agir). O agente pensa no que precisa, age usando ferramentas, observa o resultado e decide se continua ou retorna uma resposta final.

E é aqui que o MCP se torna a peça que faltava. Porque um agente de IA precisa de ferramentas para agir. Sem ferramentas, ele está apenas pensando em voz alta. O MCP lhe dá mãos.

Configurando MCP com Docker (A Parte Prática)

Aprendi isso da maneira difícil: não tente instalar servidores MCP manualmente na primeira tentativa. Use Docker. Ele cuida do isolamento, dependências e limpeza automaticamente.

Aqui está meu processo exato de configuração:

Passo 1: Instalar o Docker Desktop

Baixe do site oficial para seu sistema operacional. No Mac:

# Baixe e instale o Docker Desktop de docker.com/desktop
# Ou via Homebrew:
brew install --cask docker

# Verificar instalação
docker --version
# Docker version 28.x.x

# Habilitar MCP Toolkit no Docker Desktop:
# Settings → Beta Features → Docker MCP Toolkit → Enable

No Windows, você precisará do WSL 2 ou Hyper-V como backend primeiro. Linux é direto — apenas instale o Docker Engine e Desktop.

Passo 2: Explorar o Catálogo MCP

O Docker Desktop agora vem com um catálogo MCP — uma lista curada de servidores MCP oficiais. Abra o Docker Desktop, vá à seção MCP Toolkit e explore o catálogo. Fiquei genuinamente surpreso com o que está disponível:

• Obsidian — Acesso completo ao cofre (ler, escrever, buscar)
• Brave Search — Busca web com privacidade
• Fetch — Obter conteúdo de qualquer URL
• YouTube Transcripts — Extrair transcrições de qualquer vídeo
• DuckDuckGo — Buscar sem chaves de API
• Airbnb — Buscar acomodações (sim, de verdade)

Adicionar um servidor é um único clique. Alguns precisam de chaves de API (Brave, por exemplo), mas muitos funcionam direto.

Passo 3: Conectar Seu Cliente LLM

O Docker MCP Toolkit suporta múltiplos clientes:

• Claude Desktop (o plano gratuito funciona)
• Cursor (para trabalho focado em código)
• LM Studio (para modelos locais como Llama)

Clique em "Connect" ao lado do seu cliente. O Docker atualiza automaticamente o arquivo de configuração MCP que seu cliente lê. Para o Claude Desktop, esse arquivo fica em ~/Library/Application Support/Claude/claude_desktop_config.json no Mac.

Veja como a configuração fica por baixo dos panos:

{
  "mcpServers": {
    "obsidian": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "OBSIDIAN_API_KEY=your-key-here",
        "mcp/obsidian"
      ]
    },
    "fetch": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "mcp/fetch"]
    },
    "youtube-transcript": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "mcp/youtube-transcript"]
    }
  }
}

Cada servidor roda como um contêiner Docker isolado. Quando o Claude precisa usar uma ferramenta, ele sobe o contêiner, faz a chamada e o contêiner se encerra. Limpo. Isolado. Sem conflitos de dependências.

Passo 4: Testar

Reinicie o Claude Desktop. Clique no ícone de configurações — você deve ver "MCP Docker" listado. Clique para verificar que suas ferramentas estão carregadas.

Então simplesmente pergunte: "Busque no meu cofre do Obsidian notas sobre planejamento de projetos."

O Claude reconhecerá que tem a ferramenta search_vault, pedirá permissão para usá-la (apenas na primeira vez se você escolher) e retornará resultados do seu cofre real.

A primeira vez que vi isso funcionar, literalmente disse "Tá de brincadeira?" em voz alta. Numa sala vazia. Às 2 da manhã.

Construindo um Servidor MCP Personalizado

O catálogo é ótimo para ferramentas comuns. Mas o verdadeiro poder se desbloqueia quando você constrói servidores personalizados para suas necessidades específicas.

O vídeo do NetworkChuck mostrou algo insano: ele construiu um servidor MCP que encapsula ferramentas do Kali Linux. Sua IA podia rodar scans nmap, usar Metasploit e enumerar alvos — tudo através de linguagem natural.

Eu construí algo menos dramático mas mais prático para meu trabalho diário: um servidor MCP que encapsula a API do CMS do meu blog. Aqui está o esqueleto:

#!/usr/bin/env python3
"""Servidor MCP personalizado para o CMS do blog mejba.me."""

import json
import httpx
from mcp.server import Server
from mcp.types import Tool, TextContent

app = Server("blog-cms")

BASE_URL = "https://mejba.me/api"
API_TOKEN = "your-api-token"

@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="create_draft",
            description="Create a new blog post draft with title, content, and tags",
            inputSchema={
                "type": "object",
                "properties": {
                    "title": {"type": "string", "description": "Post title"},
                    "content": {"type": "string", "description": "Markdown content"},
                    "tags": {"type": "array", "items": {"type": "string"}}
                },
                "required": ["title", "content"]
            }
        ),
        Tool(
            name="list_recent_posts",
            description="List the most recent blog posts with their status",
            inputSchema={
                "type": "object",
                "properties": {
                    "limit": {"type": "integer", "default": 10}
                }
            }
        ),
        Tool(
            name="get_post_analytics",
            description="Get view count and engagement metrics for a post",
            inputSchema={
                "type": "object",
                "properties": {
                    "slug": {"type": "string", "description": "Post slug"}
                },
                "required": ["slug"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict):
    headers = {"Authorization": f"Bearer {API_TOKEN}"}

    if name == "create_draft":
        response = httpx.post(
            f"{BASE_URL}/posts",
            headers=headers,
            json={
                "title": arguments["title"],
                "content": arguments["content"],
                "tags": arguments.get("tags", []),
                "status": "draft"
            }
        )
        data = response.json()
        return [TextContent(
            type="text",
            text=f"Draft created: {data['slug']} (ID: {data['id']})"
        )]

    elif name == "list_recent_posts":
        limit = arguments.get("limit", 10)
        response = httpx.get(
            f"{BASE_URL}/posts?limit={limit}", headers=headers
        )
        posts = response.json()
        result = "\n".join(
            f"- [{p['title']}] ({p['status']}) - {p['views']} views"
            for p in posts
        )
        return [TextContent(type="text", text=result)]

    elif name == "get_post_analytics":
        response = httpx.get(
            f"{BASE_URL}/posts/{arguments['slug']}/analytics",
            headers=headers
        )
        data = response.json()
        return [TextContent(
            type="text",
            text=json.dumps(data, indent=2)
        )]

if __name__ == "__main__":
    import asyncio
    from mcp.server.stdio import stdio_server
    asyncio.run(stdio_server(app))

Encapsule isso em um Dockerfile, e qualquer cliente compatível com MCP pode usar o CMS do seu blog através de linguagem natural. "Ei Claude, crie um rascunho de post sobre MCP com essas tags." Pronto.

O padrão funciona para qualquer coisa com uma API: dashboards internos, bancos de dados, dispositivos IoT, pipelines de CI/CD. Se tem uma API, você pode encapsulá-lo em um servidor MCP em menos de uma hora.

Os Erros Honestos que Cometi

Quero ser transparente sobre o que me fez tropeçar, porque acho que são erros que a maioria das pessoas vai cometer.

Erro 1: Tratar agentes MCP como automação tradicional. Meu primeiro instinto foi construir fluxos rígidos — "Quando eu disser X, faça Y." Mas o ponto central do paradigma de agentes é que o LLM decide quais ferramentas usar e quando. Eu ficava restringindo demais. Os melhores resultados vieram quando dei ao Claude um objetivo e deixei ele descobrir a sequência de ferramentas.

Erro 2: Ignorar o modelo de permissões. Servidores MCP podem acessar seus arquivos, suas APIs, sua rede. O Claude Desktop pede permissão antes de cada uso de ferramenta (a menos que você permita permanentemente). Desativei os prompts de confirmação por conveniência e depois esqueci que tinha um servidor MCP conectado ao meu email. O Claude gentilmente "organizou" minha caixa de entrada baseado em um comentário casual que fiz. Lição aprendida: mantenha as permissões restritas até confiar no fluxo de trabalho.

Erro 3: Esperar perfeição dos modelos locais. Tentei rodar agentes conectados a MCP pelo LM Studio com Llama 3.1. A seleção de ferramentas foi notavelmente pior que com o Claude. Modelos locais funcionam, mas precisam de prompts mais explícitos sobre quando e como usar ferramentas. Claude e GPT-4 são significativamente melhores na seleção autônoma de ferramentas — por enquanto.

Aqui vai uma opinião controversa: acho que a maioria dos produtos de "agentes de IA" sendo vendidos agora são na verdade fluxos de trabalho de Nível 2 vestindo fantasia de agente. Seguem caminhos predefinidos com um pouco de tomada de decisão de LLM salpicada. Verdadeiros agentes de Nível 3 — onde o LLM genuinamente raciocina sobre seleção de ferramentas, ordem de execução e itera autonomamente — são raros fora de demos de pesquisa e um punhado de implementações reais.

Dito isso, o MCP é a camada de infraestrutura que torna agentes reais possíveis. O protocolo existe. As ferramentas existem. O que está evoluindo é a capacidade de raciocínio dos próprios modelos.

Como Isso Se Parece na Prática

Depois de três semanas construindo fluxos de trabalho baseados em MCP, aqui está meu antes/depois concreto:

Pesquisa para o blog — Antes: 2-3 horas assistindo vídeos do YouTube manualmente, fazendo anotações, cruzando referências com documentação. Depois: 25 minutos. O Claude puxa transcrições do YouTube via MCP, busca no meu cofre de pesquisa do Obsidian notas relacionadas e redige um esboço estruturado. Eu edito a partir dali.

Configuração de projetos de clientes — Antes: 45 minutos criando repos, configurando CI/CD, adicionando ao rastreador de projetos. Depois: 8 minutos. O Claude cria o repo no GitHub, inicializa a estrutura do projeto, adiciona ao ClickUp com marcos e envia uma notificação pelo Slack para a equipe. Tudo através de ferramentas conectadas por MCP.

Preparação do standup diário — Antes: 15 minutos verificando ClickUp, PRs do GitHub e canais do Slack. Depois: 2 minutos. "No que eu trabalhei ontem e o que está pendente para hoje?" O Claude verifica os três e me dá um resumo.

As economias de tempo são reais. Não teóricas. Não "até X%." Esses são meus números reais das últimas três semanas.

Mas — e isso importa — a configuração inicial me tomou um fim de semana inteiro. Instalar Docker, configurar servidores, testar conexões, debugar quando as coisas não funcionavam. Uma vez rodando, é mágico. Chegar lá requer paciência.

Para Onde Isso Vai

O NetworkChuck mencionou algo no final do seu vídeo que acho que a maioria dos espectadores passou batido: o Docker MCP Gateway. Isso torna seus servidores MCP locais acessíveis remotamente — o que significa que ferramentas como n8n, Make.com ou qualquer plataforma de automação externa podem se conectar aos seus servidores MCP pela rede.

Pense no que isso significa. Seu agente de IA não está mais limitado à sua máquina local. Você poderia ter um fluxo de trabalho no n8n que aciona um agente Claude que usa seus servidores MCP personalizados rodando em um VPS. O agente raciocina sobre o que fazer, usa ferramentas através do MCP e retorna resultados — tudo sem intervenção humana.

Ainda não chegamos lá para a maioria dos casos de uso em produção. Mas a distância entre "demo" e "produção" está diminuindo mais rápido do que eu esperava.

Se você levar uma coisa deste post: não espere até que os agentes de IA estejam "prontos." A infraestrutura — MCP, contêineres Docker, LLMs com chamada de ferramentas — está aqui agora. Os desenvolvedores que aprenderem essa stack hoje terão uma vantagem enorme quando as capacidades de raciocínio se equipararem.

Estou apostando meu fluxo de trabalho nisso. E honestamente? Três semanas depois, já está dando resultado.

Vamos Trabalhar Juntos

Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (builds e integrações personalizadas): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io