Extensão, MCP ou skill: qual jeito de estender o Claude resolve o seu caso?

Skill, MCP, extensão, plugin: quatro nomes, quatro problemas diferentes, e quase ninguém explica qual resolve o quê

Fala aí, beleza? Se você já travou tentando decidir se o seu caso pede MCP ou skill, a culpa não é sua: os nomes andam juntos na documentação, aparecem nas mesmas telas e todo mundo repete que "estende o Claude", o que não ajuda em nada

Só que cada um nasceu pra resolver uma dor específica

E escolher errado não é neutro: você empilha camada que fica ligada o tempo todo, gasta contexto e não resolve o problema que te trouxe aqui

Esse post é de decisão, não de tutorial completo de cada um. A ideia é você terminar sabendo qual dos caminhos abrir antes de mexer em qualquer arquivo =)

Skill, MCP, extensão e plugin lado a lado

Antes de entrar em cada um, o mapa geral

Repara numa coisa que a tabela já entrega: extensão não briga com MCP, ela é uma forma de entregar MCP

Bora destrinchar cada linha

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Quando a resposta é skill

O teste é simples: o Claude consegue chegar no que precisa e mesmo assim entrega diferente do que você queria?

Então o buraco é de conhecimento, não de acesso

O caso clássico: os arquivos do projeto estão ali, ele lê tudo, mas escreve componente fora do seu padrão, monta commit fora do seu formato, esquece a checagem que o seu time sempre faz antes de subir

Nada de servidor vai consertar isso. O que conserta é escrever o procedimento uma vez

Uma skill é uma pasta com um arquivo SKILL.md: frontmatter YAML entre marcadores --- e o corpo em markdown com as instruções que o Claude segue. Se precisar, ela leva arquivos e scripts de apoio na mesma pasta

Os dois campos obrigatórios do frontmatter são name (máximo 64 caracteres, só letras minúsculas, números e hífens) e description, que diz o que a skill faz e quando usar

---
name: revisao-de-componente
description: Revisa um componente novo conforme o padrão do projeto, checando nomes, props e estados de erro. Use antes de abrir PR de componente.
---

# Revisão de componente

1. Confira se o nome do arquivo segue o padrão da pasta
2. Verifique os estados de carregando, vazio e erro
3. ...

E o description não é enfeite

O carregamento é progressivo: na inicialização só name e description entram no system prompt, e o SKILL.md completo é lido quando o Claude julga a skill relevante pra tarefa. Ou seja, aquele texto curto é o que decide se a skill vai ser chamada ou vai ficar dormindo pra sempre

É o mesmo motivo por trás de boa parte dos casos de skill que não é acionada no projeto: o corpo pode estar impecável e o gatilho, vago

Quem chama a skill?

Dos dois jeitos: o próprio modelo invoca quando faz sentido, e você também pode chamar na mão com /nome-da-skill

Isso muda o desenho. Se é algo que você quer disparar de propósito, escreva pensando no comando. Se é algo que deveria acontecer sempre naquele contexto, escreva o description pensando no gatilho

Três níveis e quem ganha na disputa

No Claude Code as skills vivem em três lugares: pessoais em ~/.claude/skills/, do projeto em .claude/skills/ e vindas de plugin, com namespace nome-do-plugin:nome-da-skill

Quando a mesma skill existe em mais de um nível, tem precedência: a pessoal prevalece sobre a do projeto, e uma skill sua sobrepõe uma skill nativa de mesmo nome (mas não os apelidos dela). A de plugin usa namespace e por isso não entra no conflito

Vale guardar essa ordem, porque ela explica quase todo caso de duas skills disputando o mesmo nome

E tem um detalhe que deixa a vida MUITO mais leve: alteração no SKILL.md vale na hora, sem reiniciar a sessão do Claude Code. Dá pra ajustar, testar, ajustar de novo no mesmo papo

Se quiser ponto de partida em vez de folha em branco, a Anthropic mantém um repositório público de Agent Skills, o anthropics/skills

Quando a resposta é MCP

Agora o outro lado do teste: você pode escrever o procedimento mais detalhado do mundo e ainda assim não resolve, porque a informação simplesmente não está ao alcance

Issue do GitHub, tabela do banco, sistema interno da empresa, ferramenta de terceiro

Aqui não falta instrução, falta acesso

E acesso é exatamente o que o MCP (Model Context Protocol) resolve: é o padrão aberto que conecta o Claude a ferramentas e fontes de dados externas, com clientes em várias plataformas de IA

No Claude Code: escolha o escopo antes do servidor

No Claude Code, servidor MCP entra pelo comando claude mcp add, informando transporte e nome. O exemplo da própria doc:

claude mcp add --transport http stripe --scope local https://mcp.stripe.com

A parte que mais gente erra não é o comando, é o escopo

São três:

• local: o padrão, vale só pra você e só naquele projeto
• --scope user: vale em todos os seus projetos
• --scope project: grava um .mcp.json versionável, ou seja, vale pro time todo

O erro comum aqui é configurar tudo no padrão local e depois ficar sem entender por que o colega não tem a mesma conexão. Se é conexão que o time inteiro precisa, é --scope project, senão cada um vai refazer na mão

No Claude web e desktop: Settings > Connectors

Na web e no desktop o caminho é outro: conectores MCP são gerenciados em Settings > Connectors

Dali você escolhe algo do diretório de conectores ou usa "Add custom connector" informando a URL do seu servidor MCP, com autenticação por OAuth

O protocolo saiu da casa da Anthropic

Esse ponto importa pra quem decide arquitetura e não quer casar com o fornecedor

Em 09/12/2025 o MCP foi doado à Agentic AI Foundation, um fundo dirigido da Linux Foundation, co-fundada por Anthropic, Block e OpenAI. O MCP entrou como projeto fundador ao lado do goose (Block) e do AGENTS.md (OpenAI), com os mantenedores seguindo com autonomia técnica sobre o protocolo

No anúncio da doação foram divulgados os números de adoção: mais de 97 milhões de downloads mensais dos SDKs e 10.000 servidores ativos. São dados daquele anúncio de dezembro de 2025, então trate como foto do momento, não como placar de hoje

Quando a resposta é extensão de desktop

Aqui mora a confusão mais boba dos quatro nomes

Extensão de desktop não é uma terceira tecnologia competindo com MCP. É o mesmo servidor MCP local, só que empacotado pra instalar em um clique, sem editar JSON nem sair resolvendo dependência na mão

Se você conhece instalador de programa, é a mesma ideia: alguém já resolveu o trabalho chato de empacotamento pra você

O formato é o .mcpb (MCP Bundle): um arquivo zip com o servidor MCP local dentro e um manifest.json descrevendo metadados, configuração e implementação do servidor

E isso deixou de ser coisa de um cliente só: em 20/11/2025 foi anunciada a adoção do MCPB pelo projeto Model Context Protocol, como formato de distribuição pra servidores MCP locais portáveis entre clientes compatíveis

O limite que você precisa saber antes

Extensão roda na SUA máquina

O que significa, na prática: está disponível no Claude Desktop e no Claude Code, e não está na web nem no mobile

Então se a sua rotina é abrir o Claude no celular ou no navegador e esperar aquela conexão funcionar, extensão de desktop não é o caminho. Nesse cenário o que atravessa todas as superfícies é MCP remoto

Quando a resposta é plugin

O teste aqui é diferente dos outros três: não falta conhecimento e nem falta acesso

Falta entregar várias coisas juntas, prontas, pra mais gente que só você

Plugin não é concorrente de nada disso, é empacotamento

Um plugin pode reunir skills, slash commands, subagents, hooks e servidores MCP (remotos e/ou locais) em um único diretório instalável

A estrutura no Claude Code é essa:

• .claude-plugin/plugin.json (manifesto)
• skills/
• commands/
• agents/
• hooks/
• .mcp.json

E o manifesto é opcional, porque o Claude Code autodescobre os componentes nos locais padrão

Instalar é processo de dois passos

Muita gente tenta instalar direto e não entende por que não acha o plugin. É que primeiro você registra o catálogo, depois instala de dentro dele

1. Registre o marketplace com /plugin marketplace add <url>, informando uma URL HTTPS ou git
2. Instale com /plugin install nome-do-plugin@nome-do-marketplace
3. Confira o que ficou ativo abrindo /plugin e olhando a aba Installed

O erro comum é pular o passo 1 e chamar o install direto: sem catálogo registrado, não tem de onde puxar

E existe um atalho: a Anthropic mantém o claude-plugins-official, diretório oficial que já vem configurado no Claude Code. Dali dá pra instalar direto com /plugin install {nome}@claude-plugins-official

Cuidado com o "funciona em todo lugar"

Instalou um plugin não quer dizer que tudo dentro dele vai rodar onde você está

Skills empacotadas em plugin funcionam na web, na aba Chat do Claude Desktop e no Claude Cowork. Hooks e subagents rodam apenas no Cowork e aparecem esmaecidos no chat. MCP remoto funciona em todo lugar, e MCP local funciona no Desktop e no Claude Code

Ou seja: antes de culpar o plugin, cheque se o componente que você quer existe naquela superfície

O que muda na prática quando você monta isso na mão

Teoria bonita é uma coisa, montar é outra

No vídeo abaixo eu monto um projeto do zero com um agente de IA, usando skills, e algumas coisas ficaram bem claras pra mim ali

A primeira: skill é arquivo markdown com instrução de tarefa do projeto, e as que eu mais uso são justamente as chatas e repetidas. Checagem de saúde do projeto, revisão de código, planejamento de deploy, verificação de segurança, verificação de performance, criação de componente, criação de página

Nada mágico, é procedimento escrito

A segunda foi mais engraçada: eu tinha skills instaladas numa pasta genérica da máquina e o agente foi acionando elas sozinho durante o projeto, sem eu pedir nada

Massa? Em parte

Porque isso mostra o outro lado: excesso de skill é prejudicial. O agente começa a usar quando não era pra usar, e isso pode aumentar o consumo. Se você não tem nada instalado, simplesmente não vai ver skill sendo acionada, e tudo bem

Uma coisa que eu gostei bastante foi a tela que lista as skills instaladas e ainda sugere novas. Em outras ferramentas nem sempre é tão claro enxergar o que está rodando, e ver isso muda o jogo na hora de podar o que sobra

Agora, a parte das configurações que eu mais mexo não é skill, é MCP

É ali que eu conecto os serviços que já uso no dia a dia, tipo GitHub e Supabase. Inclusive tem integração nativa com Git, e mesmo assim eu prefiro fazer pelo MCP do GitHub, o que é preferência pessoal minha, não regra

E isso ilustra bem a divisão do post: quando o problema é o agente não saber o meu jeito de fazer, eu escrevo a skill. Quando o problema é ele não alcançar o serviço, nenhum markdown resolve, tem que ter servidor no meio

Sobre atrito de instalação, uma observação honesta: na comparação que eu fiz entre ferramentas, o MCP de uma delas não travou num teto de ferramentas como acontece na outra, e ali bastou conectar pra funcionar. Depois de configurado, raramente eu volto naquela tela, só quando vou adicionar um MCP novo

Duas coisas que não são skill nem MCP, mas fazem diferença enorme no resultado: o arquivo de contexto na raiz do projeto, com regras, estrutura de banco e padrão de código (ele salva até você mesmo, quando volta no projeto depois de meses parado), e começar projeto novo em modo planejamento. Demora mais, sim, mas o resultado sai mais robusto

Foi assim que eu criei a landing page do zero em HTML, CSS e JS no vídeo, depois pedindo ajuste fino conforme eu testava a tela

Ah, e rodar vários agentes em paralelo: dá pra fazer, mas eu não recomendo pelo risco de choque de edição nos mesmos arquivos. Só se as tarefas forem bem diferentes entre si

Como escolher sem empilhar camada desnecessária

A regra de decisão cabe numa pergunta só

Falta conhecimento ou falta acesso?

• Falta conhecimento (ele alcança tudo, mas faz do jeito errado): skill
• Falta acesso (a informação ou a ferramenta vive fora): MCP
• Falta acesso E instalar na mão é dor: extensão de desktop, que é o mesmo MCP local empacotado em .mcpb
• Falta distribuir várias coisas juntas pro time: plugin

E tem o alerta de custo, que quase ninguém fala

O Claude Code separa o custo de contexto de um plugin em dois tipos de token: always-on tokens, que é o texto de listagem (descrições de skills e agents, nomes de comandos) presente em toda sessão, e on-invoke tokens, que é o custo do componente quando ele é acionado

Traduzindo: cada camada ligada tem preço fixo, mesmo nas conversas em que você nem chega perto dela

Por isso a ordem que eu sigo é sempre do menor pro maior. Começa pela skill, que é uma pasta com um markdown e some do caminho quando não é relevante, e só sobe pra MCP, extensão ou plugin quando o problema for de verdade de acesso ou de distribuição

Camada empilhada por precaução não te protege de nada, só cobra contexto todo dia

Conclusão

Skill, MCP, extensão e plugin parecem quatro respostas pro mesmo problema, mas não são

Skill resolve procedimento. MCP resolve acesso. Extensão de desktop é MCP local empacotado pra instalar sem sofrimento. E plugin é o envelope que leva tudo isso junto

O próximo passo é bem pequeno e vale mais que ler mais dez comparativos: escolhe a tarefa mais repetitiva da sua rotina, cria a pasta, escreve um SKILL.md com name e description bem descritos (lembra que é o description que decide se ela vai ser chamada) e testa na próxima sessão

Se depois disso ainda faltar alguma informação que o Claude não consegue enxergar, aí sim você vai atrás de um servidor MCP, sabendo exatamente por quê 🙂

até o próximo post!