Ainda prefiro MCP a Skills

• MCP é uma interface padronizada baseada em abstração de API que permite que LLMs solicitem tarefas sem conhecer a estrutura interna das ferramentas, com suporte a uso remoto e atualizações automáticas
• Com uma arquitetura Zero-Install, autenticação OAuth e segurança por sandbox, reduz a carga de instalação e os problemas de permissão, oferecendo o mesmo ambiente em qualquer plataforma
• Já Skills geram mais atrito em ambientes reais de execução por dependerem de instalação via CLI, além da complexidade de autenticação e distribuição e de problemas de compatibilidade entre plataformas
• Skills devem ser tratadas como a camada de conhecimento, enquanto MCP é a camada de conexão; ao interagir com sistemas externos, o ideal é usar MCP, e para transmitir conhecimento procedural, Skills
• Com serviços de tunelamento em nuvem como o MCP Nest, servidores MCP locais podem ser acessados remotamente, sendo vistos como peça central para construir um ambiente padronizado de integração com IA

---

Vantagens do MCP

• O Model Context Protocol (MCP) se baseia em uma estrutura de abstração de API na qual o LLM pode executar tarefas apenas fazendo requisições, sem precisar entender o funcionamento interno da ferramenta
  • Exemplo: quando um LLM interage com o DEVONthink, basta chamar devonthink.do_x() e o servidor MCP cuida de todo o processamento
• O uso remoto Zero-Install é possível: o cliente só precisa apontar para a URL do servidor MCP para funcionar imediatamente, sem instalação adicional
• Há suporte a atualizações automáticas: quando um servidor MCP remoto é atualizado com novas ferramentas ou recursos, todos os clientes passam a usar a versão mais recente na hora
• A autenticação baseada em OAuth reforça a segurança e elimina a necessidade de o usuário gerenciar tokens manualmente
• A portabilidade é alta, permitindo acesso ao mesmo servidor MCP em Mac, celular, web e outros ambientes
• A arquitetura em sandbox restringe permissões de execução direta no ambiente local e expõe apenas interfaces controladas
• Com busca inteligente e atualização automática, apenas as ferramentas necessárias são carregadas e, mesmo em instalações locais, a atualização pode ocorrer automaticamente na execução

Limites e atritos das Skills

• Skills são úteis para ensinar conhecimentos específicos ou formas de uso a LLMs, mas a dependência de CLI se torna um problema na hora de executar ações reais
• A maioria das Skills exige a instalação de uma CLI separada, mas versões web como ChatGPT, Perplexity e Claude não conseguem executar CLI
• Isso gera problemas como:
  • Complexidade de distribuição: é preciso distribuir e gerenciar a CLI como binário, NPM, uv etc.
  • Problemas de gestão de segredos: tokens de autenticação ficam salvos em texto puro em arquivos .env, ou a autenticação desaparece quando a sessão é reiniciada
  • Fragmentação do ecossistema: o modo de instalar e atualizar Skills varia por plataforma, causando incompatibilidades e erros de parsing de YAML
  • Desperdício de contexto: mesmo quando o LLM só precisa de uma chamada de função, é necessário carregar o SKILL.md inteiro
• Skills que incluem instruções do tipo “instale primeiro a CLI” adicionam complexidade desnecessária, e substituí-las por um MCP remoto é mais eficiente

Critérios para escolher a ferramenta certa

• Quando usar MCP: quando o LLM precisa se conectar a sistemas externos, como sites, serviços e aplicações, usando uma interface padronizada
  • Exemplo: o Google Calendar deveria ser tratado por um MCP remoto com OAuth para autenticação e execução, sem exigir instalação de CLI
  • O ideal é que Chrome, Hopper, Xcode, Notion e outros também ofereçam endpoints MCP embutidos para controlar suas respectivas funções
• Quando usar Skills: quando o foco é transmitir conhecimento puro e fornecer contexto
  • Ensinar como usar ferramentas já instaladas (curl, git, gh, gcloud)
  • Padronizar terminologia interna, fluxo de trabalho e estilo de escrita dentro de uma organização
  • Compartilhar conhecimento procedural, como processamento de PDF ou gestão de segredos (por exemplo, como usar fnox)
• Skills devem ser vistas como a camada de conhecimento, e MCP como a camada de conexão

Conectores e manuais

• Para separar com clareza os papéis de Skills e MCP, propõe-se chamar Skills de manual para LLM (LLM_MANUAL.md) e MCP de conector (Connector)
• Exemplos reais em operação:
  • mcp-server-devonthink: servidor MCP local que permite ao LLM controlar o DEVONthink diretamente
  • microfn: oferece MCP remoto em mcp.microfn.dev
  • Kikuyo: oferece MCP remoto em mcp.kikuyo.dev
  • MCP Nest: serviço que tunela servidores MCP locais para a nuvem e permite acesso remoto (mcp.mcpnest.dev/mcp)
• Alguns projetos também oferecem uma Skill para CLI, mas uma Skill que explica como usar o MCP é mais útil
  • A Skill funciona como uma camada de conhecimento que explica os recursos do MCP, a relação entre ferramentas e quando usá-las
  • O MCP fica responsável pela conexão e pela execução reais
• Essa combinação permite que o LLM use o MCP com eficiência, sem repetição de tentativa e erro

Uso combinado de MCP e Skill

• Padrões pouco intuitivos descobertos durante o uso de MCP, como erros de formato de data ou limites de busca, podem ser organizados em uma Skill para reutilização
• A Skill criada dessa forma funciona como uma cola do MCP, ajudando o LLM a operar com precisão sem desperdiçar tokens desnecessariamente
• A pasta .claude/skills pode ser usada para manter instruções de comportamento de IA por projeto, enquanto procedimentos frequentes podem ser gerenciados em formato de dotfiles
• O futuro da integração com IA depende de interfaces padronizadas (MCP), enquanto abordagens fragmentadas baseadas em CLI devem ser evitadas
• Espera-se que grandes serviços como Skyscanner, Booking.com, Trip.com e Agoda.com passem a oferecer MCP oficial

Introdução ao MCP Nest

• MCP Nest é um serviço que torna acessíveis remotamente servidores MCP locais restritos à máquina local, como Fastmail e Gmail, por meio de tunelamento em nuvem
• Pode ser usado da mesma forma em clientes com suporte a MCP, como Claude, ChatGPT e Perplexity
• Sem expor diretamente a máquina local, é possível manter o mesmo ambiente MCP em todos os dispositivos

[jujumilk3]

São simplesmente duas coisas totalmente diferentes, então por que esse tipo de discussão continua aparecendo?

[xguru]

É porque eu preciso promover o MCP Nest no fim do texto... rsrsrs. Parece que muitas alegações comparativas estão ganhando força.

[jjw9512151]

Skills são a esgrima, e o MCP é a espada.. o uso é diferente, e ambos são necessários.

[ide127]

Skills e MCP têm papéis diferentes, mas acho que esse tipo de texto continua gerando confusão.

[ide127]

Ainda por cima, esta indústria de IA em plena tempestade já está infestada de pseudoevangelistas

[GN⁺]

Comentários no Hacker News

• O ponto que eu quero enfatizar é que, mais do que a preferência individual, devemos focar no design de ferramentas necessário para o LLM trabalhar da melhor forma
  O MCP, na verdade, adiciona mais atrito. Por exemplo, se você lida com sistemas embarcados, basta criar uma interface de monitoramento baseada em CLI para que o LLM possa depurar, resetar, executar emuladores etc. diretamente, e documentar como usá-la em um arquivo de skill
  Para tarefas simples, MCP é desnecessário. Por exemplo, coisas como git ou cálculo de custos da AWS o LLM já lida bem. Só vale a pena criar e documentar ferramentas próprias para sistemas complexos

  • A discussão sobre MCP parece misturar conceitos demais. O ponto central é a persistência de sessão
    Se for algo pontual, CLI ou API já basta, mas se for necessário acesso persistente, um servidor MCP é útil
    Um MCP bem estruturado ensina o agente a usar sem desperdiçar prompt. Tentar imitar acesso persistente com arquivo de skill é ineficiente. MCP é a forma mais eficaz de integrar ferramentas externas à sessão do agente
  • MCP e skill são complementares. Enxergar os dois como opostos é um mal-entendido
  • A cadeia de ferramentas atual para LLMs ainda parece uma fase de transição sem padronização. Em vez de espalhar informações em vários lugares como .md ou skill, é preciso um padrão que organize isso no local ideal por meio de loops automatizados de autorreflexão
  • Eu também sigo uma abordagem parecida. A maior parte das ferramentas CLI foi criada pelo próprio Claude, e eu quase não uso IDE
    Até os recursos de refatoração do JetBrains foram substituídos por scripts, reduzindo o tempo de sessão de 5 minutos para 10 segundos
    Ainda não uso MCP de jeito nenhum. A combinação REST + Swagger + codegen + Claude + skill já é suficiente
  • A vantagem do MCP é o controle de permissões. Por exemplo, se você não quer que a IA tenha permissão de escrita no git, pode limitar a exposição via MCP. Só um READ_ONLY_SKILL não basta

• No fim, esse debate é sobre desenvolvedor individual vs colaboração em escala organizacional
  Se você trabalha sozinho e quer um loop de feedback rápido, CLI é melhor; se precisa de controle e consistência em nível organizacional, MCP faz mais sentido
  Hoje o MCP consome muito contexto, mas isso deve melhorar com divulgação gradual

  • Nas organizações, há o problema de que o controle de acesso via MCP é difícil. Uma pessoa pode apagar duas coisas por engano, mas um agente pode deletar milhares em um instante. A CLI é mais segura porque permite limitar o escopo de acesso
  • O desperdício de contexto é um problema de implementação do cliente. Carregamento gradual é possível mesmo sem mudar a especificação
  • MCP e CLI são ferramentas com objetivos diferentes, e ficam mais poderosas quando usadas juntas

• Eu quero um agente que use diretamente as ferramentas CLI existentes, não APIs
  Se eu já uso CLI localmente, não há motivo para acrescentar MCP. Também não quero modelos remotos
  Se for preciso chamar APIs, skill já basta

  • Eu também coloco comandos curl diretamente em skills para chamar APIs customizadas. O LLM lida bem com isso
  • Mas, para gerenciamento de chaves secretas, MCP é mais seguro. Se o servidor MCP for iniciado antes, as chaves não ficam expostas ao ambiente do agente
  • MCP funciona como uma camada de fronteira de segurança entre o agente e o mundo externo. Nem sempre é necessário, mas é útil
  • Em alguns ambientes, o LLM pode não ter permissão de acesso à CLI. Nesse caso, chamadas de CLI baseadas em skill não servem para nada
  • Também há as questões de autenticação (authn) e autorização (authz). O MCP pode controlar isso como middleware

• MCP e Skill não são uma relação de soma zero
  MCP cuida da interface padronizada da camada de infraestrutura, enquanto Skill cuida do contexto de comportamento específico de cada projeto
  Combinando os dois, você ganha estabilidade e flexibilidade

  • No fim, o MCP é só uma forma de empacotar CLI. Na verdade, o MCP tem ainda mais sobrecarga de contexto
  • Alguns MCPs pagos realmente têm valor. Por exemplo, um MCP para busca na web é mais prático do que rodar um crawler por conta própria
  • Em agentes hospedados na nuvem, a combinação Skill + MCP é a estrutura central. Facilita autenticação e gerenciamento de dependências
  • O autor do texto também apoia essa combinação. O MCP tem alta portabilidade, podendo ser usado do mesmo jeito no ChatGPT, Claude, Perplexity etc.
  • Skill pode ser ignorado pelo LLM, mas as políticas do MCP têm força de imposição no lado do servidor

• A maior parte da discussão gira em torno de pessoas que rodam agentes de programação localmente
  Nesse ambiente, Skill é mais conveniente, mas usuários em geral usam soluções em nuvem como ChatGPT
  Nesse caso, o MCP vira a opção padrão. Seus pontos fortes são autenticação e acesso remoto

  • Mas há quem veja o MCP como apenas um wrapper barulhento de API
    É preciso subir um servidor, e para o LLM isso acaba sendo mais um fardo. Skill é mais simples porque codifica a documentação da API de forma amigável ao LLM
  • Também houve quem rebateu que a afirmação de que “a maioria dos usuários não usa agentes locais” precisa de evidências
  • Houve até uma piada corrigindo o erro de digitação ‘agronomic’ para ‘ergonomic’

• Eu prefiro Skill, porque ele permite reaproveitar exatamente as ferramentas CLI que humanos usam
  Skill é uma documentação legível e editável por humanos, então LLM e pessoas compartilham as mesmas ferramentas
  Já com MCP, é preciso criar uma nova API específica para LLM e manter documentação separada
  Skill só é carregado quando necessário, mantendo o contexto limpo

• Quem defende “só Skill” costuma ser não técnico, e quem defende “só CLI” costuma ser desenvolvedor individual
  MCP é adequado para ambientes corporativos. Ele padroniza autenticação e interface

  • Muita gente tem uma visão negativa do MCP por causa da instabilidade do JIRA MCP. Um Skill baseado em acli era mais estável
  • Eu mesmo construí um MCP interno para a empresa. Adicionei autenticação do Google Workspace e fiz o Claude consultar dados internos ou publicar apps com segurança
    O MCP é fácil de atualizar e implantar, então tem alta acessibilidade até para não técnicos
  • Também há quem diga que, como as empresas já têm esquemas internos de autenticação, CLI seria melhor
    No fim, o MCP não passa de um subconjunto estruturado de APIs
  • MCP pode ser colocado no ar rapidamente. Uma configuração Codex → LiteLLM → VLLM → MCP fica pronta em minutos
  • Eu vejo os sistemas SaaS existentes como legado. Um banco SQL local é mais eficiente do que APIs difíceis para acessar dados
    MCP é só mais um protocolo RPC, e o problema de autenticação ainda continua sem solução

• Eu acho que o MCP é necessário por causa da irracionalidade humana
  Muitas organizações ainda não oferecem APIs nem CLI. O MCP preenche essa desconexão digital
  Estruturas de reporte e política interna nas empresas impedem a automação, e o MCP pode contornar isso

  • Eu também concordo. Se os agentes dos colegas pudessem colaborar entre si, a digitalização organizacional seria muito mais fácil. O MCP é bom porque esconde essa complexidade de cabeamento

• Skill tem o problema de inchaço de contexto porque é preciso colocar a documentação inteira no contexto
  O MCP sofre de algo parecido, mas com descoberta de ferramentas dá para fazer carregamento gradual
  Um problema maior é que a saída do MCP entra direto no contexto do agente. Se você chamar serviços MCP via CLI, dá para filtrar ou fazer cache

  • Houve também a reação: “se é assim, por que não usar simplesmente requisições HTTP?”
  • O autor explicou que o MCP mais recente já resolveu isso com lazy loading baseado em descoberta de ferramentas. O Claude Code usa subagentes para evitar explosão de logs
  • Eu resolvi isso envolvendo meu MCP local com cache em memória. Dou um ID para a saída de cada ferramenta e depois chamo outras ferramentas usando esse ID. Isso economiza tokens e melhora a velocidade

• Skill é bom para guardar conhecimento intuitivo, enquanto MCP é mais adequado para automação repetível
  Se o LLM estiver escrevendo o mesmo script várias vezes, é mais eficiente fixar isso como ferramenta

  • A maior parte dos processos pode ser pré-processada com scripts, deixando o LLM envolvido só em planejamento e validação
    Ou seja, o essencial é pré-processar com scripts o máximo possível
  • Também dá para incluir o script diretamente dentro de um skill. Skill também pode conter código
  • O autor original esclareceu que o texto foi escrito por uma pessoa real durante um voo, não por IA
  • Alguém disse que também usa skill para tarefas repetitivas, e a partir daí seguiu uma explicação sob a perspectiva de contrato de API do MCP
    Se for um script pequeno, basta colocá-lo no contexto e dizer “use isto”