Voc\u00ea j\u00e1 deve ter vivido essa cena: o agente de IA est\u00e1 no meio de uma tarefa, precisa checar o status de um ticket no Jira, olhar um log no Datadog ou consultar uma tabela no banco de produ\u00e7\u00e3o \u2014 e voc\u00ea, sentado ali, vira o intermedi\u00e1rio. Copia o resultado de uma consulta, cola no chat, espera a IA processar, copia a resposta de volta, aplica manualmente em outro sistema. O modelo \u00e9 brilhante para raciocinar sobre o problema, mas est\u00e1 isolado atr\u00e1s de uma caixa de texto, dependente de voc\u00ea para ser as m\u00e3os e os olhos dele no mundo real.<\/p>\n
Esse gargalo tem nome t\u00e9cnico: falta de tool calling<\/em> padronizado. Cada ferramenta de IA que voc\u00ea usa \u2014 Claude Desktop, Cursor, um agente customizado em Python \u2014 historicamente exigia sua pr\u00f3pria integra\u00e7\u00e3o propriet\u00e1ria para acessar arquivos, APIs ou bancos de dados. Resultado: voc\u00ea reescreve a mesma “cola” de integra\u00e7\u00e3o N vezes, uma para cada par (modelo, ferramenta). \u00c9 exatamente o problema que o MCP (Model Context Protocol) se prop\u00f5e a resolver, e \u00e9 sobre isso \u2014 a arquitetura, o protocolo em si e como implementar na pr\u00e1tica \u2014 que vamos tratar aqui.<\/p>\n O Model Context Protocol \u00e9 um padr\u00e3o aberto, criado pela Anthropic e hoje adotado por diversos players do ecossistema, que define como aplica\u00e7\u00f5es de IA se conectam a fontes de dados e ferramentas externas. A ideia central \u00e9 simples de enunciar e poderosa na pr\u00e1tica: em vez de cada integra\u00e7\u00e3o ser um adaptador propriet\u00e1rio e \u00fanico, o MCP define um protocolo comum \u2014 baseado em JSON-RPC \u2014 para que qualquer cliente compat\u00edvel converse com qualquer servidor compat\u00edvel.<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> O Google Cloud resume bem o valor arquitetural do protocolo: ele cria uma “conex\u00e3o padronizada e bidirecional” entre aplica\u00e7\u00f5es de IA e fontes de dados, permitindo que LLMs se conectem facilmente a ferramentas diversas sem reinventar a integra\u00e7\u00e3o a cada vez. Vale a leitura completa em cloud.google.com\/discover\/what-is-model-context-protocol<\/a>.<\/p><\/blockquote>\n A analogia mais precisa \u2014 e a que o pr\u00f3prio ecossistema usa \u2014 \u00e9 a de uma porta USB-C para IA. Antes do USB-C, cada dispositivo tinha seu pr\u00f3prio conector: um para carregar, outro para transferir dados, outro para v\u00eddeo. O USB-C unificou isso em uma interface f\u00edsica comum. O MCP faz o equivalente no plano de software: unifica a interface entre “c\u00e9rebro” (o modelo) e “m\u00e3os” (as ferramentas e dados), independente de quem fabricou cada lado.<\/p>\n Para implementar ou depurar MCP com seguran\u00e7a, voc\u00ea precisa ter claro o papel de cada componente:<\/p>\n O ponto crucial, muitas vezes ignorado por quem come\u00e7a a mexer com isso, \u00e9 que o servidor MCP n\u00e3o decide sozinho quando ser\u00e1 chamado. Ele apenas anuncia suas capacidades. Quem decide invocar uma tool \u00e9 o modelo, com base na descri\u00e7\u00e3o que voc\u00ea escreveu para ela. Isso significa que a qualidade das suas descri\u00e7\u00f5es de tool \u00e9, na pr\u00e1tica, sua interface de programa\u00e7\u00e3o com o racioc\u00ednio do LLM \u2014 um ponto que volta a aparecer mais adiante, nas armadilhas.<\/p>\n Vamos a um exemplo com contexto real: uma equipe que quer que o agente de IA consulte o status de deploys em um sistema interno, sem que o desenvolvedor precise copiar e colar logs manualmente. Usando o SDK oficial em TypeScript (h\u00e1 tamb\u00e9m SDKs em Python, Java, Kotlin e C#, todos documentados em modelcontextprotocol.io<\/a>):<\/p>\n Repare em dois detalhes que fazem diferen\u00e7a em produ\u00e7\u00e3o: o Depois de constru\u00eddo, o servidor precisa ser registrado no host. No Claude Code, por exemplo, isso \u00e9 feito via configura\u00e7\u00e3o de projeto ou globalmente:<\/p>\n A partir desse ponto, qualquer prompt no Claude Code que envolva “verificar o status do checkout-api em produ\u00e7\u00e3o” pode disparar automaticamente a tool, sem que voc\u00ea precise sair do terminal para consultar um painel externo. O mesmo servidor, sem altera\u00e7\u00e3o de c\u00f3digo, pode ser plugado no Claude Desktop, no Cursor ou em qualquer outro host compat\u00edvel \u2014 esse \u00e9 o ganho real de padroniza\u00e7\u00e3o.<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> A Backslash Security tem uma explica\u00e7\u00e3o direta sobre por que isso importa em termos de arquitetura de software: o MCP resolve o problema de “M integra\u00e7\u00f5es vezes N ferramentas”, transformando uma explos\u00e3o combinat\u00f3ria de conectores customizados em uma \u00fanica interface compartilhada. Leia em backslash.security\/blog\/what-is-mcp-model-context-protocol<\/a>.<\/p><\/blockquote>\n Antes de escrever seu pr\u00f3prio servidor, vale checar o ecossistema de servidores de refer\u00eancia e comunit\u00e1rios mantidos em github.com\/modelcontextprotocol\/servers<\/a>. H\u00e1 implementa\u00e7\u00f5es prontas para Git, PostgreSQL, Google Drive, Slack, Puppeteer, entre outras. Para um cen\u00e1rio generalista \u2014 um time que usa Python no backend, TypeScript no front e precisa que o agente acesse o reposit\u00f3rio Git local \u2014 a configura\u00e7\u00e3o pode ser t\u00e3o simples quanto:<\/p>\n Com isso configurado, voc\u00ea pode pedir diretamente ao agente: “verifique se existe uma migration pendente que altera a tabela orders e me mostre o diff do \u00faltimo commit que tocou nela”. O modelo vai orquestrar chamadas \u00e0s duas tools \u2014 Git e Postgres \u2014 sem que voc\u00ea precise escrever nenhum c\u00f3digo de integra\u00e7\u00e3o.<\/p>\n Na teoria o fluxo \u00e9 elegante. Na pr\u00e1tica, alguns problemas aparecem com frequ\u00eancia quando times colocam MCP em produ\u00e7\u00e3o.<\/p>\n Se duas tools t\u00eam descri\u00e7\u00f5es parecidas \u2014 por exemplo, Cada tool registrada consome espa\u00e7o no contexto do modelo com sua descri\u00e7\u00e3o e schema. Conectar dez servidores MCP simultaneamente, cada um expondo dezenas de tools, pode inflar o prompt de sistema a ponto de degradar a qualidade do racioc\u00ednio ou estourar limites de contexto. A pr\u00e1tica recomendada \u00e9 modular: ative apenas os servidores relevantes para a sess\u00e3o de trabalho atual, e em ferramentas como o Claude Code, use escopos de configura\u00e7\u00e3o por projeto em vez de registrar tudo globalmente.<\/p>\n Servidores locais (transporte Ferramentas como o MCP Inspector<\/a> permitem testar chamadas de tool isoladamente, fora do fluxo do agente, isolando se o problema est\u00e1 no servidor ou na decis\u00e3o do modelo.<\/p>\n Um servidor MCP mal projetado que exp\u00f5e uma tool gen\u00e9rica como \ud83d\udca1 Dica do Mestre:<\/strong> Um artigo recente resume bem essa mudan\u00e7a de mentalidade no t\u00edtulo: pare de fazer hard-code das integra\u00e7\u00f5es de IA. A ideia \u00e9 tratar cada capacidade externa como uma tool desacoplada e reutiliz\u00e1vel, n\u00e3o como l\u00f3gica embutida no prompt. Vale conferir em medium.com\/@kapildevkhatik2<\/a>.<\/p><\/blockquote>\n O protocolo evolui, e diferentes hosts implementam vers\u00f5es distintas da especifica\u00e7\u00e3o em ritmos diferentes. Um servidor que usa recursos mais recentes \u2014 como sampling<\/em>, em que o servidor pode pedir ao modelo para gerar texto \u2014 pode n\u00e3o funcionar em um cliente mais antigo. Fixe a vers\u00e3o do SDK no seu Um ponto que costuma passar despercebido: o servidor MCP n\u00e3o precisa ser escrito na mesma linguagem do seu projeto principal. Times que trabalham com Delphi em sistemas legados, por exemplo, podem expor uma camada de integra\u00e7\u00e3o via um servidor MCP escrito em Python ou Node.js, que por sua vez conversa com a API REST ou com o banco de dados da aplica\u00e7\u00e3o Delphi \u2014 sem tocar uma linha do c\u00f3digo legado. O protocolo \u00e9 agn\u00f3stico de linguagem por design, exatamente porque a comunica\u00e7\u00e3o acontece via JSON-RPC sobre stdio ou HTTP, n\u00e3o por bibliotecas nativas compartilhadas.<\/p>\n Isso abre um padr\u00e3o de arquitetura interessante: um “hub” de servidores MCP mantidos centralmente pela equipe de plataforma, cada um especializado em um dom\u00ednio (billing, autentica\u00e7\u00e3o, observabilidade), consumidos por qualquer agente de IA que qualquer time decida usar \u2014 Claude Code, Cursor, ou um agente interno constru\u00eddo com o SDK. \u00c9 a mesma l\u00f3gica de microsservi\u00e7os aplicada \u00e0 camada de contexto de IA.<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> Para uma introdu\u00e7\u00e3o em portugu\u00eas sobre o motivo de o MCP estar ganhando tra\u00e7\u00e3o como padr\u00e3o de mercado, vale a leitura de Elisa Terumi: “O MCP visa criar um padr\u00e3o universal para conectar modelos de IA a diversas fontes de dados e ferramentas, de forma segura e eficiente.” Dispon\u00edvel em elisaterumi.substack.com<\/a>.<\/p><\/blockquote>\n MCP \u00e9 um daqueles temas em que a teoria explica 20% do trabalho e a pr\u00e1tica \u2014 depurar um servidor que falha silenciosamente, decidir onde colocar o limite entre tool granular e tool gen\u00e9rica, versionar SDKs entre projetos \u2014 resolve os outros 80%. Se voc\u00ea est\u00e1 implementando servidores MCP no seu fluxo de trabalho, ou avaliando se vale a pena migrar integra\u00e7\u00f5es propriet\u00e1rias para esse padr\u00e3o, vale trocar experi\u00eancias com quem j\u00e1 passou pelas mesmas decis\u00f5es.<\/p>\nO que o MCP resolve, tecnicamente<\/h2>\n
As tr\u00eas pe\u00e7as do protocolo<\/h3>\n
\n
Construindo um servidor MCP do zero<\/h2>\n
import { McpServer } from \"@modelcontextprotocol\/sdk\/server\/mcp.js\";\nimport { StdioServerTransport } from \"@modelcontextprotocol\/sdk\/server\/stdio.js\";\nimport { z } from \"zod\";\n\nconst server = new McpServer({\n name: \"deploy-status-server\",\n version: \"1.0.0\",\n});\n\nserver.registerTool(\n \"get_deploy_status\",\n {\n title: \"Consulta status de deploy\",\n description:\n \"Retorna o status atual de um deploy pelo ID do servi\u00e7o. \" +\n \"Use quando o usu\u00e1rio perguntar sobre o estado de uma implanta\u00e7\u00e3o \" +\n \"em produ\u00e7\u00e3o, staging ou homologa\u00e7\u00e3o.\",\n inputSchema: {\n serviceId: z.string().describe(\"Identificador do servi\u00e7o, ex: 'checkout-api'\"),\n environment: z.enum([\"production\", \"staging\", \"homolog\"]),\n },\n },\n async ({ serviceId, environment }) => {\n const status = await fetchDeployStatus(serviceId, environment);\n\n return {\n content: [\n {\n type: \"text\",\n text: `Servi\u00e7o ${serviceId} em ${environment}: ${status.state} ` +\n `(\u00faltima atualiza\u00e7\u00e3o: ${status.updatedAt})`,\n },\n ],\n };\n }\n);\n\nconst transport = new StdioServerTransport();\nawait server.connect(transport);\n<\/code><\/pre>\ndescription<\/code> da tool \u00e9 escrito como uma instru\u00e7\u00e3o para o modelo, n\u00e3o como um coment\u00e1rio para o pr\u00f3ximo desenvolvedor humano. E o inputSchema<\/code>, validado com Zod, funciona como contrato \u2014 o servidor rejeita chamadas malformadas antes de tocar em qualquer l\u00f3gica de neg\u00f3cio.<\/p>\nConectando o servidor a um cliente real<\/h3>\n
{\n \"mcpServers\": {\n \"deploy-status\": {\n \"command\": \"node\",\n \"args\": [\".\/mcp-servers\/deploy-status\/dist\/index.js\"]\n }\n }\n}\n<\/code><\/pre>\nServidores prontos: quando n\u00e3o reinventar a roda<\/h2>\n
{\n \"mcpServers\": {\n \"git\": {\n \"command\": \"uvx\",\n \"args\": [\"mcp-server-git\", \"--repository\", \"\/caminho\/do\/projeto\"]\n },\n \"postgres\": {\n \"command\": \"npx\",\n \"args\": [\"-y\", \"@modelcontextprotocol\/server-postgres\",\n \"postgresql:\/\/usuario:senha@localhost\/mydb\"]\n }\n }\n}\n<\/code><\/pre>\nArmadilhas comuns e como depurar<\/h2>\n
1. Descri\u00e7\u00f5es de tool amb\u00edguas geram chamadas erradas<\/h3>\n
search_users<\/code> e find_user<\/code> \u2014 o modelo pode escolher a errada, ou pior, chamar as duas em sequ\u00eancia desnecessariamente, gastando tokens e lat\u00eancia. O ajuste fino aqui \u00e9 editorial: descri\u00e7\u00f5es devem ser mutuamente exclusivas e explicitar quando usar cada tool. Trate isso como voc\u00ea trataria nomes de m\u00e9todos em uma API p\u00fablica \u2014 ambiguidade no nome \u00e9 d\u00edvida t\u00e9cnica.<\/p>\n2. Excesso de tools carregadas de uma vez<\/h3>\n
3. Falhas silenciosas de transporte<\/h3>\n
stdio<\/code>) falham de forma diferente de servidores remotos (transporte HTTP com Server-Sent Events). Um erro comum \u00e9 o processo do servidor morrer silenciosamente \u2014 por exemplo, uma exce\u00e7\u00e3o n\u00e3o tratada dentro do handler de uma tool \u2014 e o host simplesmente reportar “tool indispon\u00edvel” sem stack trace \u00fatil. Para depurar, rode o servidor manualmente fora do host primeiro:<\/p>\nnode .\/dist\/index.js\n# Envie uma requisi\u00e7\u00e3o JSON-RPC manual via stdin para validar\n# se o servidor responde antes de conectar ao cliente\n<\/code><\/pre>\n4. Seguran\u00e7a: tools com poder demais<\/h3>\n
execute_sql(query: string)<\/code> abre a porta para o modelo (ou para um prompt injection vindo de um dado externo) executar comandos destrutivos. O princ\u00edpio aqui \u00e9 o mesmo de qualquer API exposta: privil\u00e9gio m\u00ednimo. Prefira tools granulares (get_order_by_id<\/code>, list_pending_invoices<\/code>) a uma tool universal que aceita SQL arbitr\u00e1rio. Se seu servidor precisa de acesso de escrita, isole-o do de leitura e exija confirma\u00e7\u00e3o expl\u00edcita do usu\u00e1rio nos hosts que suportam esse fluxo, como o Claude Code faz ao pedir aprova\u00e7\u00e3o antes de executar certas a\u00e7\u00f5es.<\/p>\n5. Versionamento e compatibilidade entre clientes<\/h3>\n
package.json<\/code> ou requirements.txt<\/code>, e teste explicitamente contra os hosts que sua equipe realmente usa antes de considerar o servidor pronto para uso compartilhado.<\/p>\nMCP em contexto multi-linguagem<\/h2>\n
Aprofunde essa discuss\u00e3o na Comunidade Dev’s AI<\/h2>\n