Ferramentas (Tools) e MCP Servers: O que Dá Poder aos Agentes

Um agente de codificação sem ferramentas é como um mecânico trancado fora da oficina — ele sabe o que fazer, mas não consegue tocar em nada. O que transforma um modelo de linguagem em um agente de verdade é justamente a capacidade de agir: ler arquivos, executar comandos, consultar APIs, criar pull requests. Essas capacidades se chamam ferramentas (tools), e o protocolo que padronizou como conectá-las se chama MCP — Model Context Protocol.

Neste artigo, você vai entender o que são tools, como o MCP funciona, e por que esse protocolo aberto se tornou o padrão universal para dar superpoderes aos agentes de codificação.

O que São Ferramentas (Tools)

Ferramentas são capacidades invocáveis que um agente pode usar durante sua execução. Quando você pede ao Claude Code para “criar um arquivo de teste para essa função”, ele não apenas gera o texto — ele chama uma ferramenta de escrita de arquivo para salvar o conteúdo no disco. Quando pede ao Cursor para “rodar os testes e corrigir o que falhar”, ele invoca ferramentas de terminal e edição de código.

Pense em tools como as mãos do agente. O modelo de linguagem é o cérebro — ele raciocina, planeja, decide. Mas sem tools, ele só consegue falar. Com tools, ele consegue fazer.

Exemplos concretos de tools

Cada agente de codificação vem com um conjunto de tools built-in — ferramentas nativas que já estão disponíveis sem configuração. O Claude Code, por exemplo, inclui leitura/escrita de arquivos, terminal, busca web e navegador como tools padrão. O Cursor oferece edição de código, terminal e busca no projeto. O Kiro CLI traz ferramentas de arquivo, terminal, busca e integração com AWS.

Mas o verdadeiro salto acontece quando você pode adicionar ferramentas externas — e é aí que entra o MCP.

Como Funciona: O Protocolo MCP

O problema antes do MCP

Antes do MCP, cada integração entre um agente e um serviço externo era um caso especial. Quer que o Claude leia seu Google Drive? Precisa de um wrapper OAuth customizado, um adaptador para a API do Docs, lógica para formatar os dados. Quer que o Cursor acesse seu Notion? Outro wrapper, outro padrão, outra integração.

Cada ferramenta de IA construía seus próprios conectores. Era como se cada fabricante de eletrônicos inventasse seu próprio tipo de cabo — um mundo de adaptadores incompatíveis.

A analogia do USB-C

O MCP é o USB-C dos agentes de IA. Assim como o USB-C padronizou a conexão entre dispositivos eletrônicos e periféricos, o MCP padroniza a conexão entre agentes de IA e serviços externos. Uma interface universal, um protocolo, múltiplas possibilidades.

[IMAGEM: Diagrama mostrando a analogia USB-C — antes (múltiplos cabos diferentes) vs depois (um padrão universal MCP conectando agentes a serviços)]

O que é o MCP

O Model Context Protocol é um padrão aberto criado pela Anthropic no final de 2024 que define como aplicações de IA se conectam a sistemas externos. É um protocolo de comunicação que permite que qualquer agente (cliente MCP) se conecte a qualquer serviço (servidor MCP) de forma padronizada.

Em termos técnicos, o MCP usa JSON-RPC como base — o mesmo padrão de design do LSP (Language Server Protocol) que você já usa no VS Code para autocompletar código. Se você já trabalhou com extensões de linguagem no VS Code, o MCP vai parecer familiar.

Arquitetura: Clientes e Servidores

A arquitetura do MCP é simples:

1. Cliente MCP — o agente de codificação (Claude Code, Cursor, Kiro CLI, GitHub Copilot)
2. Servidor MCP — um programa que expõe ferramentas, recursos e prompts
3. Protocolo — a linguagem padronizada de comunicação entre eles

Quando um cliente MCP se conecta a um servidor, acontece um handshake:

1. O cliente pergunta: “Quais ferramentas você oferece?”
2. O servidor responde com uma lista de tools, cada uma com nome, descrição e schema de parâmetros
3. O cliente registra essas tools como disponíveis para o modelo
4. Quando o modelo decide usar uma tool, o cliente envia a chamada ao servidor
5. O servidor executa a ação e retorna o resultado

É como um cardápio de restaurante: o servidor apresenta o que tem disponível, e o agente escolhe o que precisa conforme a situação.

O que um MCP Server expõe

Um servidor MCP pode expor três tipos de capacidade:

Transportes: stdio vs HTTP

MCP servers se comunicam com clientes por dois mecanismos:

stdio (local) — O cliente inicia o servidor como um subprocesso e se comunica via stdin/stdout. Zero rede, zero autenticação externa. O servidor roda na sua máquina e só sua máquina o acessa. É o padrão para desenvolvimento local.

Streamable HTTP (remoto) — O servidor roda como um serviço HTTP, e o cliente se conecta pela rede. Usado para servidores hospedados, ambientes enterprise, ou quando múltiplos clientes precisam acessar o mesmo servidor.

Para a maioria dos desenvolvedores, stdio é o caminho. Você instala o servidor localmente, configura no seu agente, e pronto.

Tools Built-in vs MCP Servers

Existe uma distinção importante entre as ferramentas que já vêm com o agente e as que você adiciona via MCP:

As tools built-in cobrem o essencial para codificação: manipular arquivos, rodar comandos, navegar na web. Os MCP servers expandem o agente para qualquer coisa que tenha uma API — bancos de dados, serviços cloud, ferramentas de projeto, plataformas de deploy.

MCP na Prática: Instalação e Configuração

Configurando um MCP Server no Claude Code

Para adicionar um MCP server ao Claude Code, você cria um arquivo .mcp.json no seu projeto:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_seu_token_aqui"
      }
    }
  }
}

Reinicie o Claude Code e o servidor GitHub estará disponível. O agente agora pode criar issues, abrir PRs, listar branches — tudo via linguagem natural.

Configurando no Cursor

No Cursor, a configuração fica em ~/.cursor/mcp.json ou nas settings do projeto:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/caminho/do/projeto"]
    }
  }
}

Configurando no Kiro CLI

O Kiro CLI suporta MCP servers nativamente. A configuração fica em .kiro/settings/mcp.json:

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

A AWS mantém um ecossistema completo de MCP servers para seus serviços — desde documentação até gerenciamento de infraestrutura, passando por bancos de dados e containers.

GitHub Copilot e MCP

O GitHub Copilot também suporta MCP servers no agent mode. No VS Code, você configura via .vscode/mcp.json:

{
  "servers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${input:github-token}"
      }
    }
  }
}

O suporte a MCP no Copilot permite que o agent mode acesse ferramentas externas além das capacidades nativas, expandindo significativamente o que ele pode fazer de forma autônoma.

Exemplos de MCP Servers Úteis

O ecossistema MCP cresceu explosivamente. Em março de 2026, a Anthropic reportou mais de 97 milhões de instalações do protocolo, com mais de 10.000 servidores disponíveis publicamente. Aqui estão os mais relevantes para desenvolvedores:

Infraestrutura e Código

Bancos de Dados

Cloud e DevOps

Produtividade e Documentação

Criando seu próprio MCP Server

Você pode criar um MCP server em menos de uma hora. Com o SDK oficial em Python:

from mcp.server import Server
from mcp.types import Tool, TextContent

app = Server("meu-servidor")

@app.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="consultar_status",
            description="Consulta o status do deploy atual",
            inputSchema={
                "type": "object",
                "properties": {
                    "ambiente": {"type": "string", "enum": ["staging", "production"]}
                },
                "required": ["ambiente"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    if name == "consultar_status":
        # Sua lógica aqui — chamar API interna, consultar banco, etc.
        return [TextContent(type="text", text=f"Deploy em {arguments['ambiente']}: ✅ healthy")]
    raise ValueError(f"Tool desconhecida: {name}")

O SDK está disponível em Python e TypeScript, e a comunidade mantém implementações em Go, Rust e outras linguagens.

Por que Importa: Mais Tools = Agente Mais Capaz

A equação é direta: quanto mais ferramentas um agente tem acesso, mais problemas ele resolve sem sua intervenção.

Um agente com apenas leitura/escrita de arquivo pode gerar código. Adicione terminal, e ele pode rodar testes. Adicione GitHub, e ele pode abrir PRs. Adicione banco de dados, e ele pode debugar queries de produção. Adicione documentação, e ele para de alucinar sobre APIs.

Cada tool adicionada é um grau de autonomia a mais. É a diferença entre um agente que escreve código e um agente que entrega funcionalidades completas — do código ao teste, do commit ao deploy.

O impacto prático

Considere um cenário real: você pede ao agente “corrija o bug de timeout no endpoint /users e abra um PR com a correção”.

Sem MCP servers:

1. O agente lê o código (tool built-in)
2. Edita o arquivo (tool built-in)
3. Para aqui — você precisa rodar testes, commitar e abrir o PR manualmente

Com MCP servers (GitHub + terminal):

1. O agente lê o código
2. Edita o arquivo
3. Roda os testes (terminal)
4. Cria um branch (git)
5. Commita a correção (git)
6. Abre o PR com descrição detalhada (GitHub MCP)
7. Entrega pronto para review

A diferença é entre um assistente que ajuda e um agente que resolve.

Segurança: Permissões e Sandboxing

MCP servers rodam com as permissões que você concede. Um servidor de filesystem apontado para seu diretório home pode ler tudo ali. Um servidor GitHub com escopo de admin pode modificar qualquer repositório da sua organização.

Isso não é um bug — é uma decisão de design. O MCP é um protocolo, não um sandbox. A segurança é responsabilidade de quem configura.

Boas práticas de segurança

1. Escopo mínimo — Dê ao filesystem server apenas o diretório do projeto, não sua home inteira. Dê ao GitHub server escopo de repo específico, não admin da org.

2. Comece local — Use servidores stdio (locais) antes de expor qualquer coisa via HTTP. Sem rede = sem superfície de ataque remota.

3. Audite as tools visíveis — No Claude Code, use /mcp para ver quais servidores estão ativos e quais tools expõem. Se algo parece perigoso, desabilite.

4. Confie em servidores oficiais primeiro — Os servidores mantidos pela Anthropic, GitHub, Google e AWS são auditados. Repositórios aleatórios no GitHub não são.

5. Tokens com escopo limitado — Use tokens de API com as permissões mínimas necessárias. Um token read-only para consultas, write apenas quando necessário.

6. Revise antes de aprovar — Quando o agente pede para executar uma ação via MCP (especialmente destrutiva), revise o que ele pretende fazer antes de confirmar.

O modelo de confiança

O fluxo de segurança funciona em camadas:

• Camada 1: O agente decide chamar uma tool
• Camada 2: O cliente MCP pode pedir confirmação do usuário (dependendo da configuração)
• Camada 3: O servidor MCP executa com as permissões do token/credencial configurado
• Camada 4: O resultado volta ao agente

Ferramentas como Claude Code e Kiro CLI implementam modos de permissão — você pode configurar quais tools rodam automaticamente e quais pedem aprovação antes de executar.

Próximos Passos

Agora que você entende o que são tools e como o MCP conecta agentes a serviços externos, aqui está o que fazer:

1. Experimente um MCP server — Instale o servidor de filesystem ou GitHub no seu agente preferido. Leva 5 minutos e o impacto é imediato.

2. Explore o ecossistema — O repositório modelcontextprotocol/servers no GitHub tem dezenas de servidores oficiais. O diretório awesome-mcp-servers lista milhares da comunidade.

3. Leia os guias das ferramentas — Cada agente tem sua forma de configurar MCP. Consulte os guias específicos:

   • [LINK_INTERNO: guia-claude-code]
   • [LINK_INTERNO: guia-cursor]
   • [LINK_INTERNO: guia-kiro-cli]
   • [LINK_INTERNO: guia-github-copilot]

4. Considere criar o seu — Se sua equipe tem APIs internas, um MCP server customizado pode transformar o agente em um especialista do seu domínio.

Se você quer implementar MCP servers customizados para o contexto da sua empresa — conectando agentes às suas APIs internas, bancos de dados proprietários e workflows específicos — a ft.ia.br oferece consultoria especializada em configuração e especialização de agentes de codificação para times de desenvolvimento.