Entenda MCP - O MCP não é só Tools · leonardord

Este é o segundo texto da trilha de 3 partes sobre MCP, e aqui quero aprofundar ainda mais o ponto que me fisgou desde o começo: por que o mercado insiste em enxergar o MCP quase exclusivamente como ferramenta de Tools?

Parte 1: TabNews - Newsletter

🧭 Esta é a edição #4 da minha newsletter Logbook for Devs, um logbook dev com relatos da jornada: onde exploro temas técnicos e reflexões com narrativas leves e diretas — sem fórmulas prontas - E muitas libs legais 😎

📓 Entrada no Logbook

Se você chegou até aqui, imagino que já esteja minimamente familiarizado com o MCP e com a ideia de que ele é bem mais do que uma simples forma de registrar funções para IA.

Tem sido curioso acompanhar o hype em torno do Model Context Protocol (MCP). O assunto está em alta, pipocando em blogs, plugins, projetos open source... mas tem algo que não sai da minha cabeça: por que todo mundo parece reduzir o MCP apenas às Tools?

É como se o protocolo fosse só um novo jeitinho de registrar funções pra IA chamar. E de tanto se repetir isso, a impressão que ficou é que "usar MCP" virou sinônimo de "implementei uma Tool". Sendo que, na real, o protocolo define cinco conceitos distintos. E o mais curioso: essa limitação de visão nem é por má fé, mas parece ter nascido da pressa.

MCP apareceu rápido no mercado, e vários clients quiseram ser os primeiros a dizer "temos suporte". Resultado: implementaram as Tools (porque era o mais fácil e imediato), colaram o selo de compatível e seguiram. Meio como quando começaram a surgir APIs REST e bastava ter um GET e um POST pra dizer que tava "dentro do padrão".

Mas a real é que o MCP é mais que feature. É um modelo de integração. E foi quando comecei a explorar os outros pilares dele que percebi: o papel do MCP é muito semelhante ao que o REST representou como camada de arquitetura.

Antes do REST, era comum que lógicas de negócio e acesso a dados ficassem acopladas diretamente ao frontend. Isso dificultava manutenção, escalabilidade e tornava qualquer mudança um inferno de deploy. Entra o REST e... boom: agora temos uma camada independente, reutilizável, que pode ser consumida por diferentes interfaces (web, mobile, CLI etc).

Com o MCP é a mesma pegada, mas aplicada ao ecossistema LLM:

Hoje, é comum que prompts, tools, contexto, decisões e integrações estejam todos hardcoded no client. Isso significa que qualquer alteração exige:

Novo deploy
Rebuilds
Multiplicação de lógicas se você tiver mais de um client (ex: VSCode + terminal + web)

O MCP entra justamente como essa "camada REST das LLMs". Ele centraliza e expõe:

🛠️ Tools
- Funções que a IA pode chamar (como se fossem endpoints ou comandos)
- Escapam do client, ficam versionadas no server
📂 Resources
- Contextos dinâmicos: arquivos, dados, logs
- Lidos sob demanda, escalonáveis, com controle de acesso
📝 Prompts
- Modelos reutilizáveis de interação
- Parametrizáveis, testáveis e versionáveis
🎯 Sampling
- Quando o próprio servidor precisa pedir ao modelo uma resposta
- "IA rodando na backend" com as credenciais/contexto do client
🌱 Roots
- Escopos de contexto que podem ser selecionados por client (como projetos diferentes)
- Não executam nada, mas orientam onde e como o server deve atuar

Entendendo os conceitos com calma

Durante meu processo de aprendizado com MCP, percebi que algumas coisas que pareciam simples à primeira vista, na verdade exigiam um certo tempo para serem digeridas. Principalmente quando você tenta sair do "modo Tools" e começa a olhar com atenção para os outros pilares.

Por exemplo, o Resource parece só uma forma diferente de injetar contexto. Mas aí você esbarra na pergunta: se a IA não puxa esse resource sozinha, qual a vantagem de usá-lo em vez de um simples fetch REST?

A dificuldade aqui é que o uso de Resource não está no que ele faz por conta própria (porque ele não faz nada sozinho), mas sim no que ele permite quando parte de um ecossistema bem integrado. Ele não entrega contexto por si, mas deixa o client (ou o fluxo) com a opção de puxar sob demanda, com granularidade, versão, mimeType, escopo. Algo que um endpoint REST também poderia fazer, mas que aqui já vem com regras e formato prontos pra IA consumir. (E sim, essa diferença vai ganhar um destaque especial na parte 3 da trilha... aguardem 👀)

No Sampling, o estranhamento foi maior. A ideia de que o servidor pudesse "falar com a IA" parecia abstrata demais no começo. Eu achava que era só mais uma forma de usar a IA no backend, algo como um fetch() com prompt incluído. Mas não é bem isso. O Sampling não é sobre "usar a IA", mas sim sobre o servidor ser capaz de gerar mensagens completas (com role, type, content) como se fossem parte do fluxo do client.

A diferença está em quem puxa a interação: em vez da IA reagir ao usuário, é o servidor que decide quando disparar algo, com que contexto, e com qual modelo ativo. Isso é especialmente útil em fluxos que precisam de checkpoints, validações ou microdecisões geradas dinamicamente, sem depender de interação humana direta.

Esses detalhes não ficam claros nas primeiras leituras. Foi só depois de testar um bocado, ajustar expectativas e observar eles que comecei a entender o real valor do MCP, mais do que a promessa isolada de cada parte, é sobre como tudo se conecta.

🧠 O que isso muda na prática?

Quer subir uma nova Tool? Não precisa tocar no client.
Quer mudar a forma como um Prompt se comporta? Edita no server, todo mundo recebe.
Quer servir diferentes clients com a mesma base de capacidades? Sem duplicar código, é só manter o server MCP rodando.

Isso permite um estilo de arquitetura onde:

O LLM é desacoplado da orquestração
O client fica responsável apenas por UI/UX e seleção de contexto
E tudo que é regra de negócio, workflow, integração e interpretação fica no server

Exatamente como o backend tradicional se tornou um orquestrador ao invés de apenas armazenador de dados.

🤔 E se os clients MCP ainda não suportam tudo?

Tudo bem. Assim como o REST também levou tempo até os frontends adotarem o padrão por completo, o MCP está numa fase parecida.
Hoje clients como o RooCode, Claude Plugin e alguns SDKs já suportam Tools nativamente e começam a abrir suporte para Prompts, Resources e Sampling.

Mesmo que o client ainda não consuma tudo, é vantajoso já estruturar a lógica como um MCP Server. Isso garante desacoplamento, organização e prepara seu ecossistema para o crescimento futuro (e possíveis integrações com outros clients).

Em resumo, se você pensa em construir algo sério com LLMs, o MCP é o que o REST foi pro frontend:

Uma separação de preocupações entre quem mostra e quem pensa.

E honestamente acho que esse é o tipo de arquitetura que vai se destacar nos próximos anos.

🌊 Marés da semana

Já vi robôs jogando bola, cozinhando... mas montaria? Pois é. A Kawasaki tá desenvolvendo um robô montável. Seria esse o início de uma nova era do RPG ao ar livre?
O Google expandiu o suporte do NotebookLM para mais de 50 idiomas!
Pra quem tava na caverna de Platão: é uma IA que absorve múltiplas fontes (arquivos, vídeos, imagens...) e depois responde perguntas sobre o conteúdo.
Mas o mais insano? Ela gera um podcast com duas IAs debatendo o assunto! Testa colocar seu currículo, TCC ou qualquer tema, é divertido e ótimo pra estudo.
Hoje estreia Thunderbolts* nos cinemas. Pelos reviews, vale acreditar, ainda mais pra quem acompanha desde a fase 1 do MCU. 🦸🏼

📦 Treasure - Good Stuff

Ainda no embalo do MCP, aqui vai um destaque da comunidade: Supermemory.
Uma forma poderosa de turbinar memória e contexto nos seus AI Clients.
GitHub de Prompts? Agora temos! (e bastante até), mas aqui vai um que curti bastante em termos de usabilidade: ShummerPrompt
Sabia que da pra desenvolver aplicações Windows com React Native? É inclusive usado no Xbox e oficial Microsoft! Tá tudo aqui → React-Native-Windows

⚓ Se chegou até aqui, já deu pra sentir o clima de bordo.

Essa é uma das entradas do meu Logbook for Devs — onde registro ideias, reflexões técnicas e ferramentas que cruzam meu caminho na jornada.

Toda terça e quinta tem uma nova anotação de rota, com marés atualizadas e tesouros recém-descobertos.

⛵ Quer seguir viagem comigo?

Embarque aqui.