Antes do MCP, cada ferramenta de IA que precisava acessar um sistema externo — um banco de dados, o Google Drive, o GitHub, uma API interna da sua empresa — precisava de uma integração feita sob medida. Um conector pro Slack não servia pro Notion. Um conector pro Postgres não servia pro GitHub. Toda combinação de "IA + ferramenta" virava um projeto de integração próprio.

O "USB-C" das ferramentas de IA

O Model Context Protocol (MCP) é um protocolo aberto, criado pela Anthropic e liberado como padrão público, que resolve isso de um jeito parecido com o que o USB-C fez pra cabos: em vez de cada fabricante ter seu próprio conector, existe um padrão único que qualquer lado pode implementar. Um servidor MCP escrito pra expor "acesso a um banco de dados Postgres" funciona com qualquer cliente de IA compatível com MCP — não só com a Claude.

Isso separa dois papéis bem definidos:

  • Servidor MCP — expõe uma capacidade específica (ex.: ler e escrever num banco, buscar arquivos num repositório, consultar uma API). Quem mantém o sistema escreve o servidor uma única vez.
  • Cliente MCP — é a aplicação de IA (Claude Desktop, Claude Code, ou qualquer outra compatível) que se conecta a um ou mais servidores MCP e usa as capacidades que eles expõem.

Como funciona por baixo dos panos

Um servidor MCP roda como um processo separado — localmente na sua máquina (mais comum) ou remotamente — e conversa com o cliente por um protocolo baseado em JSON-RPC. Na prática, ele anuncia um conjunto de tools (ações que podem ser chamadas, como "buscar_registro" ou "criar_arquivo"), resources (dados que podem ser lidos, como o conteúdo de um arquivo ou uma linha de banco) e às vezes prompts prontos. O cliente lê essa lista e decide, durante a conversa, quando faz sentido chamar cada uma.

Configurar um servidor MCP normalmente é só apontar pra ele num arquivo de configuração. Um exemplo típico (formato usado pelo Claude Desktop e por outros clientes compatíveis):

{
  "mcpServers": {
    "sistema-de-arquivos": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/caminho/da/pasta"]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://usuario:senha@host/banco"]
    }
  }
}

Depois de configurado e a aplicação reiniciada, a IA passa a "enxergar" essas ferramentas na conversa — sem precisar de nenhum código de integração escrito à mão pra cada caso.

O que dá pra conectar

Como é um padrão aberto, existe um ecossistema crescente de servidores MCP prontos — de bancos de dados e sistemas de arquivo a ferramentas de produtividade, controle de versão e serviços de nuvem — além da opção óbvia de escrever um servidor próprio pra expor um sistema interno específico da sua empresa. O repositório oficial de servidores de referência é um bom ponto de partida pra ver a variedade:

MCP não substitui Skills — as duas coisas se completam

Vale reforçar a diferença: MCP dá acesso (a IA consegue de fato ler aquele banco, escrever naquele arquivo), enquanto uma Skill dá conhecimento de processo (como e quando usar esse acesso do jeito certo pro seu contexto). Um exemplo comum: um servidor MCP conecta a Claude ao seu repositório no GitHub, e uma Skill descreve exatamente o padrão de commit e o checklist que sua equipe espera antes de abrir um PR. Sem o MCP, a Skill não teria como agir de verdade; sem a Skill, o acesso existiria mas sem o critério certo por trás.

Se você ainda não leu o módulo anterior desta seção, ele explica Skills com mais calma. E se quiser o passo a passo prático de configurar seu primeiro servidor MCP do zero — incluindo como lidar com credenciais com segurança e os erros mais comuns na primeira tentativa —, isso está no módulo "MCP na prática", disponível pra assinantes.