![Imagem de capa de [MCP·Skill #1] O que é um servidor MCP? Dos métodos de conexão aos cuidados de segurança](/assets/images/posts/45e71f91-f21d-492e-a6da-e0ffc8d4af18/1.jpg)
Ao usar ChatGPT ou Claude, chega um momento em que sentimos falta de algo. O modelo é inteligente, mas não consegue acessar meu banco de dados nem ler a wiki interna da empresa.
Por isso, todos começaram a conectar as APIs diretamente. O problema é que cada modelo e ferramenta tem uma forma diferente de integração, e o código cresce exponencialmente conforme aumentam as combinações.
MCP (Model Context Protocol) é um padrão criado para resolver esse problema. Em uma frase, é uma especificação comum para conectar ferramentas e dados externos aos modelos de IA. Costuma ser chamado de “USB-C da IA”.
Neste artigo, vamos explicar exatamente o que o MCP resolve, como o trabalho de integração muda antes e depois da adoção, sua estrutura interna e a diferença em relação ao function calling, além de alguns servidores importantes que você já pode conectar.
Vamos começar pelo resumo dos pontos principais.
- MCP é um protocolo padrão aberto que conecta IA a ferramentas externas (publicado pela Anthropic em novembro de 2024).
- Um trabalho que exigiria centenas de linhas em uma integração direta termina com algumas linhas de configuração quando existe um servidor MCP.
- Ele não substitui o function calling; é uma camada que padroniza e permite reutilizar ferramentas sobre ele.
- Com a adoção por OpenAI e Google, tornou-se na prática um padrão do setor, e seu ecossistema de servidores cresce rapidamente.
O problema que o MCP resolve: o inferno de integração M×N
Vamos primeiro entender como era antes do MCP.
Se existem M aplicativos de IA e N ferramentas para conectar, são necessárias M×N integrações. Era preciso criar separadamente a integração do GitHub para Claude, ChatGPT e Cursor.
O MCP insere uma especificação padrão entre os dois lados. O lado das ferramentas cria um servidor MCP uma vez, e o lado dos aplicativos implementa um cliente MCP uma vez. M×N vira M+N.
Pense na época anterior ao USB-C, quando era preciso carregar cabos diferentes para cada dispositivo. O MCP padroniza exatamente essa especificação de cabos.
Mas fórmulas como M+N não tornam a diferença muito concreta. Quando construímos a mesma funcionalidade das duas formas, o contraste fica evidente.
A mesma funcionalidade: comparação antes e depois da adoção
Vamos supor que estamos criando “uma IA que consulta issues do GitHub e responde às perguntas”.
Antes do MCP, todo este trabalho ficava por sua conta.
- Definir o schema da ferramenta: escrever diretamente como JSON Schema “list_issues recebe owner, repo e state”.
- Escrever o código de chamada: cliente da API REST do GitHub, gerenciamento de tokens e paginação.
- Implementar o loop de execução: código de ida e volta que recebe o resultado e o devolve ao modelo quando ele chama uma ferramenta.
- Repetir tudo para cada aplicativo: uma integração para Claude e outra para o chatbot interno.
Uma simples consulta de issue chega a centenas de linhas com o boilerplate, e o processo se repete de 1 a 3 vezes sempre que uma ferramenta é adicionada.
Com MCP, termina assim.
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"]
}
}
}O schema, as chamadas de API, a autenticação e o tratamento de erros já estão dentro do servidor. Basta registrar o servidor e dizer: “Resuma as issues de bugs mais recentes deste repositório”.
| Item | Integração direta | Uso de servidor MCP |
|---|---|---|
| Código escrito | Centenas de linhas de schema, chamadas e loops | 5 linhas de configuração |
| Autenticação e tratamento de erros | Implementados manualmente | Integrados ao servidor |
| Adicionar outro aplicativo de IA | Recomeçar do zero | Reutilizar o mesmo servidor |
| Adicionar uma ferramenta | Alterar e redistribuir o código | Apenas atualizar o servidor |
A última linha é especialmente importante. Mesmo que uma funcionalidade seja adicionada ao servidor, seu código não muda nem uma linha. Esse é o poder da padronização.
Estrutura interna: host, cliente e servidor
O MCP tem três participantes.
| Componente | Função | Exemplo |
|---|---|---|
| Host | O aplicativo de IA usado pelo usuário | Claude Desktop, Cursor |
| Cliente | Comunicação um para um com o servidor dentro do host | Integrado ao host |
| Servidor | Programa que expõe ferramentas e dados | Servidor do GitHub, servidor de banco de dados |
Um host inicia vários clientes, e cada cliente se conecta a um servidor. O protocolo de comunicação é JSON-RPC 2.0; processos locais usam stdio, e conexões remotas usam HTTP streaming.
As funções expostas pelo servidor se dividem em três tipos.
- Ferramentas (tools): funções chamadas pelo modelo, como “criar issue” e “executar consulta”.
- Recursos (resources): dados lidos pelo modelo, como conteúdo de arquivos e schemas de bancos de dados.
- Prompts (prompts): templates de prompt preparados previamente pelo servidor.
O ponto central é consultar a lista de ferramentas em tempo de execução. Quando o cliente se conecta ao servidor, pergunta “o que você consegue fazer?”, e o servidor devolve a lista e os schemas. É por isso que seu código permanece igual mesmo quando o servidor é atualizado.
Qual é a diferença em relação ao function calling?
Ao chegar aqui, surge a dúvida: “Isso já não era possível com function calling?”
Eles estão em camadas diferentes. function calling é um protocolo para conversar com o modelo: “Modelo, estas funções estão disponíveis; quando necessário, responda no formato de chamada”. Como implementá-las e de onde obtê-las é responsabilidade do desenvolvedor.
MCP é um protocolo para distribuir e reutilizar essas funções. Ele reúne implementação, autenticação e documentação das ferramentas em um pacote de servidor que qualquer aplicativo de IA pode usar.
Se function calling é a “sintaxe de chamada de funções”, MCP é um “ecossistema de bibliotecas que contém funções”. Na prática, clientes MCP usam function calling internamente. Não são alternativas, mas camadas superior e inferior.
Por isso, a pergunta “qual usar, function calling ou MCP?” não faz sentido por si só. Para algumas funções usadas em um único aplicativo, implementar function calling diretamente basta. Para reutilizar em vários aplicativos ou usar ferramentas criadas por terceiros, MCP é a escolha certa.
Servidores importantes para conectar agora
O ecossistema cresce rapidamente, e já existem servidores para a maioria das ferramentas comuns. Selecionamos cinco opções bem avaliadas.
| Servidor | O que pode fazer |
|---|---|
| Playwright | A IA controla o navegador diretamente: clica, digita e tira screenshots |
| Figma | Lê layouts de design e os converte em código frontend |
| Notion | Pesquisa e organiza documentos e atas de reunião, e cria páginas |
| GitHub | Consulta e cria issues e PRs, e pesquisa código |
| Supabase(Postgres) | Consulta bancos de dados em linguagem natural e entende o schema |
Se eu tivesse que escolher um, seria o Playwright. Conecte-o e diga: “Entre neste site, preencha o formulário de cadastro e tire um screenshot”. Ao ver a IA abrir o navegador, clicar e digitar de verdade, fica desnecessário explicar por que conectar ferramentas muda o jogo. Ele também pode ser usado imediatamente para automação de testes E2E e tarefas web repetitivas.
O Figma também faz muita diferença para desenvolvedores frontend. O trabalho de converter manualmente um design em markup passa a ser pedir a uma IA que lê o design diretamente: “Transforme este frame em um componente React”.
Cuidados e limitações
Não é uma solução universal. Vale conhecer os problemas práticos.
Primeiro, segurança. Um servidor MCP é um canal que concede permissões de execução ao modelo; conectar um servidor não confiável pode vazar dados por prompt injection. O mais seguro é usar apenas registros oficiais ou servidores verificados.
Também existe o custo de contexto. Quanto mais servidores você conecta, mais as definições de ferramentas consomem a janela de contexto, criando o paradoxo de reduzir o desempenho do modelo. Como mostra a tabela, é melhor conectar apenas o que você precisa no momento.
Conclusão
O MCP não torna o modelo “mais inteligente”; ele padroniza “o alcance ao qual o modelo consegue chegar”. Transformar centenas de linhas de integração direta em algumas linhas de configuração e criar um ecossistema no qual você conecta ferramentas feitas por outros: essa é a essência.
No próximo artigo, vou explicar as funções do Skill do Claude Code e dos subagentes, frequentemente comparados ao MCP.