O que é MCP e como usar ferramentas MCP no seu assistente de IA

Guia prático do Model Context Protocol: host, cliente e servidor, ferramentas, recursos e prompts, como conectar ao Claude e usar ferramentas MCP com segurança.

Avatar de Danrley Pereira
Danrley Pereira
O que é MCP e como usar ferramentas MCP no seu assistente de IA

Todo assistente de IA esbarra no mesmo limite: ele sabe muito, mas não enxerga os seus sistemas. Não lê o seu repositório, não consulta o seu banco, não abre um chamado na sua ferramenta de suporte. Durante muito tempo, cada produto resolveu isso do seu jeito, com plugins e integrações que só funcionavam ali.

O Model Context Protocol (MCP) é a resposta padronizada para esse problema. É um protocolo aberto que define como um assistente de IA descobre e usa ferramentas e dados externos. Você escreve a integração uma vez, como um servidor MCP, e ela funciona em qualquer cliente compatível: Claude, IDEs, agentes próprios.

Este guia explica como o MCP funciona e, principalmente, como usar ferramentas MCP no dia a dia com segurança. Se você quiser criar o seu próprio servidor, o artigo irmão Como criar um servidor MCP em Python com FastMCP mostra o passo a passo.

As três peças: host, cliente e servidor

O MCP separa responsabilidades em três papéis:

  • Host: a aplicação que você usa, como o Claude, uma IDE ou um agente. Ele contém o modelo e decide o que mostrar a você.
  • Cliente MCP: o componente dentro do host que fala o protocolo. Cada cliente mantém uma conexão com um servidor.
  • Servidor MCP: o programa que expõe um sistema. Pode ser um servidor do GitHub, do seu banco de dados ou da API da sua empresa.

Um mesmo host conecta vários servidores ao mesmo tempo. É isso que deixa um assistente consultar o repositório, olhar um painel de métricas e atualizar um chamado na mesma conversa.

A conversa entre cliente e servidor usa JSON-RPC sobre um de dois transportes: stdio, quando o servidor roda como processo local na sua máquina, e HTTP (Streamable HTTP), quando o servidor é um serviço remoto.

O que um servidor oferece

Um servidor MCP pode publicar três tipos de coisa, e cada uma tem um "dono" diferente:

Peça Quem decide usar Exemplo
Ferramentas (tools) o modelo buscar_livros, criar_issue, rodar_consulta
Recursos (resources) a aplicação o README do projeto, um registro, um arquivo de configuração
Prompts o usuário um comando pronto como "revisar este PR"

As ferramentas são a parte que mais muda a experiência: é com elas que o assistente deixa de só responder e passa a agir.

Como uma chamada de ferramenta acontece

Diagrama de sequência: usuário, LLM, cliente MCP e servidor MCP trocando tools/list, a chamada da ferramenta e o resultado
Diagrama de sequência: usuário, LLM, cliente MCP e servidor MCP trocando tools/list, a chamada da ferramenta e o resultado

Quando você faz uma pergunta, o fluxo é este:

  1. O cliente pede ao servidor a lista de ferramentas (tools/list). Cada uma vem com nome, descrição e um JSON Schema dos argumentos.
  2. O host entrega a sua pergunta ao modelo junto com essa lista.
  3. O modelo decide se alguma ferramenta ajuda e monta os argumentos seguindo o schema.
  4. O cliente executa a chamada no servidor (tools/call) e devolve o resultado ao modelo.
  5. O modelo lê o resultado e responde, ou chama outra ferramenta.

O ponto importante: o modelo escolhe a ferramenta lendo a descrição. Uma ferramenta mal descrita é ignorada ou usada na hora errada. E quando a chamada falha, o servidor devolve um resultado marcado como erro com uma mensagem que o modelo lê e pode usar para corrigir a próxima tentativa.

Conectando um servidor MCP ao Claude

No Claude Code, um comando adiciona um servidor:

# servidor remoto, por HTTP
claude mcp add --transport http github https://api.githubcopilot.com/mcp/

# servidor local, por stdio (o Claude inicia o processo)
claude mcp add biblioteca -- python /caminho/para/server.py

Depois, claude mcp list mostra os servidores e o estado de cada conexão, e o comando /mcp dentro da sessão permite autenticar ou reconectar. No app do Claude, o caminho equivalente é adicionar um conector nas configurações. Em todos os casos, a regra é a mesma: o host passa a conhecer as ferramentas daquele servidor.

Usando ferramentas MCP no dia a dia

Com o servidor conectado, você não chama ferramentas pelo nome: você descreve o que quer. Alguns hábitos fazem diferença:

  • Peça o resultado, não o passo. "Liste as issues abertas com a etiqueta bug e resuma as três mais antigas" funciona melhor do que "chame list_issues".
  • Dê o contexto que a ferramenta não tem. Nome do repositório, ambiente, período. O modelo preenche os argumentos com o que você disser.
  • Leia o pedido de confirmação. Ferramentas que escrevem dados costumam pedir aprovação. Veja os argumentos antes de aprovar, principalmente em produção.
  • Use os prompts do servidor. Quando um servidor oferece prompts, eles já sabem combinar as ferramentas certas para tarefas comuns.
  • Prefira poucos servidores bem escolhidos. Cada ferramenta conectada ocupa espaço no contexto do modelo e é mais uma opção para ele errar.

Segurança: o que observar antes de conectar

Um servidor MCP age em seu nome. Trate a conexão como você trataria dar uma chave de acesso a um sistema:

  • Confie na origem. Instale servidores de fontes conhecidas e revise o que um servidor local executa na sua máquina.
  • Menor privilégio. Dê ao token do servidor só o acesso que a tarefa exige. Um servidor que só lê não precisa de permissão de escrita.
  • Cuidado com conteúdo externo. Uma página, um e-mail ou um documento lido por uma ferramenta pode conter instruções escondidas. O modelo não deve tratá-las como ordens suas, e você deve desconfiar quando o assistente propõe uma ação que você não pediu.
  • Separe leitura de escrita. Deixe ferramentas de escrita sempre com confirmação e revise o que elas fizeram.
  • Registre e revise. Em ambiente de equipe, prefira servidores que registram as chamadas, para saber quem fez o quê.

MCP, APIs e plugins: qual a diferença

O MCP não substitui a sua API. Ele é uma camada fina em cima dela, pensada para modelos: descreve cada operação de um jeito que o modelo entende, padroniza erros e descoberta, e deixa o mesmo servidor funcionar em qualquer host. Uma API REST continua sendo o contrato entre sistemas; o servidor MCP é o contrato entre o seu sistema e um assistente.

Por onde começar

Conecte um servidor que resolve uma dor real da sua rotina, como o do seu repositório ou do seu sistema de chamados, use por uma semana com as práticas acima e observe onde o assistente acerta e onde precisa de mais contexto. Quando a sua empresa tiver um sistema que ainda não tem servidor, o próximo passo é criar o seu: com FastMCP, em Python, isso leva uma tarde.

Gostou do artigo?

Compartilhe com seus amigos e ajude a espalhar conhecimento!