Se você esteve perto de ferramentas de IA no ano passado, ouviu duas siglas e uma palavra espalhadas como se fossem intercambiáveis: MCP, agentes e agora “Habilidades”. Eles não são a mesma coisa, e misturá-los leva a decisões de arquitetura das quais você se arrependerá seis meses depois.
Vou começar com a versão curta. O MCP dá a um modelo de IA a capacidade de fazer coisas. Habilidades ensinam isso como fazê-los bem. Uma é sobre conectividade, a outra sobre know-how. A maior parte da confusão vem do fato de que ambos ampliam o que um modelo pode realizar, de modo que parecem respostas concorrentes para a mesma pergunta. Eles não são.
Vamos descompactar cada um deles da perspectiva de alguém que passou anos construindo e mantendo sistemas back-end sérios.
O que o MCP realmente é
O Model Context Protocol é um padrão aberto para conectar aplicativos de IA a sistemas externos: bancos de dados, APIs, sistemas de arquivos, ferramentas de tickets, serviços internos. Antes de existir, cada integração era feita sob medida. Se você quisesse que seu assistente consultasse o Postgres, você escreveria um código cola. Se você quisesse falar com Jira, você escreveu um código de cola diferente. Multiplique isso por cada cliente de IA e cada fonte de dados e você terá o clássico problema de integração N×M.
O MCP transforma isso em um contrato compartilhado. Um servidor expõe recursos, um cliente os descobre e os chama, e os dois comunicam JSON-RPC entre si. Se você se lembra do que o Language Server Protocol fez pelos editores, a ideia é a mesma: escrever a integração uma vez, usá-la de qualquer lugar que fale o protocolo.
Um servidor MCP pode expor três tipos principais de coisas:
-
Ferramentas: funções que o modelo pode invocar, como search_orders ou create_ticket.
-
Recursos: dados somente leitura que o modelo ou usuário pode inserir no contexto, como um arquivo ou registro de banco de dados.
-
Solicitações: modelos reutilizáveis que um usuário pode acionar explicitamente.
A comunicação acontece por stdio para servidores locais (o cliente inicia seu processo e se comunica por entrada e saída padrão) ou por HTTP para servidores remotos. Essa divisão no transporte é mais importante do que parece à primeira vista. Um servidor stdio é executado na máquina do desenvolvedor com as permissões desse desenvolvedor. Um servidor remoto é um serviço de rede real, com todas as questões de autenticação, autorização, limitação de taxa e observabilidade que você já sabe como lidar.
Quais são realmente as habilidades
As habilidades, conforme introduzidas pelo Anthropic, são muito mais humildes na construção e, de certa forma, mais interessantes. Uma habilidade é uma pasta. Dentro dele fica um HABILIDADE.md arquivo com um pequeno bloco de metadados (um nome e uma descrição) seguido por instruções simples de redução. A pasta também pode conter scripts, modelos, documentos de referência ou qualquer outra coisa que as instruções possam precisar.
É isso. Nenhum servidor. Nenhum aperto de mão de protocolo. Nenhum processo para se manter vivo.
A parte inteligente é como eles são carregados. O modelo não lê todas as habilidades antecipadamente. Na inicialização ele vê apenas o nome e a descrição de cada um, algumas dezenas de tokens cada. Quando surge uma tarefa que corresponde a uma descrição, o modelo extrai a informação completa HABILIDADE.md. Se esse arquivo apontar para outro documento ou script de referência, eles serão lidos somente quando necessário. Isso geralmente é chamado de divulgação progressiva e é o motivo pelo qual você pode instalar um grande número de habilidades sem afogar a janela de contexto.
Pense em uma habilidade como o documento de integração que você entregaria a um novo contratado: “Veja como escrevemos migrações de banco de dados. Aqui está nossa convenção de nomenclatura. Aqui está a lista de verificação que executamos antes de um lançamento. Aqui está um script que valida o formato do changelog.” Ele carrega conhecimento processual, não conectividade.
A diferença central
Aqui está o modelo mental que considero mais útil.
O MCP responde à pergunta: o que o modelo pode alcançar?
Habilidades respondem à pergunta: o que o modelo sabe sobre como trabalhamos?
Imagine que você contratou um empreiteiro. MCP é o cartão-chave, as credenciais da VPN e o login do seu rastreador de problemas. As habilidades são o wiki da equipe, os padrões de codificação e a conversa “é assim que fazemos as coisas por aqui”. Um empreiteiro com um cartão-chave e sem orientação ficará por aí fazendo mal as coisas tecnicamente permitidas. Um empreiteiro com excelente orientação e sem acesso só pode falar sobre o que faria.
Você precisa de ambos e, para a maioria dos fluxos de trabalho reais, eles aparecem juntos.
Onde eles diferem na prática
Custo no contexto. Um servidor MCP anuncia suas ferramentas, e essas definições de ferramentas normalmente ficam no contexto do modelo sempre que o servidor está conectado. Conecte vários servidores com dezenas de ferramentas cada e você gastará uma parte significativa do seu orçamento de contexto antes que o usuário digite qualquer coisa. As habilidades são projetadas para serem baratas até serem necessárias, já que apenas as descrições são carregadas inicialmente.
Determinismo. As ferramentas MCP são códigos. Uma ferramenta que chama seu serviço de precificação sempre faz a mesma coisa, com parâmetros digitados e saídas definidas. Habilidades são instruções interpretadas por um modelo, portanto orientam o comportamento em vez de garanti-lo. As habilidades podem agrupar scripts que são executados de forma determinística, mas a decisão de executá-los ainda passa pelo modelo.
Peso operacional. Um servidor MCP é um software que você cria, implanta, protege, cria versões e monitora. Uma habilidade é um diretório que você pode verificar no Git e revisar em uma solicitação pull. A lacuna no esforço é enorme, e é exatamente por isso que você não deve construir um servidor quando uma habilidade bastaria.
Superfície de segurança. Um servidor MCP, especialmente remoto, é uma nova superfície de ataque. Ele lida com credenciais, executa ações e retorna conteúdo que vai direto para o contexto do modelo. Vale a pena fazer uma pausa neste último ponto: a saída da ferramenta é uma entrada não confiável e a injeção imediata por meio dos resultados da ferramenta é uma preocupação real. As habilidades apresentam seus próprios riscos, porque as instruções e os scripts incluídos podem ser maliciosos, portanto, você deve tratar as habilidades de terceiros da mesma forma que trataria as dependências de terceiros. Leia-os antes de confiar neles.
O ângulo Java
Os desenvolvedores Java estão bem posicionados aqui. O MCP Java SDK oficial existe, e o Spring AI fornece iniciadores de cliente e servidor MCP, portanto, expor um serviço existente a um cliente de IA pode ser surpreendentemente pouco trabalhoso. Um esboço da aparência de uma ferramenta Spring AI:
Java
@Serviço
classe pública OrderTools {
pedidos finais privados do OrderRepository;
public OrderTools(pedidos do OrderRepository) {
this.orders = pedidos;
}
@Tool(description = “Encontrar pedidos recentes de um cliente por ID do cliente”)
Lista pública
retornar pedidos.findRecentByCustomer(customerId, Math.min(limite, 50));
}
}
As anotações exatas e os detalhes de registro variam de acordo com a versão do Spring AI, portanto, verifique a documentação atual em vez de copiá-la literalmente. A questão é o formato: você já tem serviços, repositórios e DTOs. Um servidor MCP é em grande parte uma fachada fina e bem descrita sobre eles.
Essa magreza também é onde a antiguidade é importante. Alguns hábitos que eu recomendaria:
-
Limite e valide tudo. Observe o Math.min acima. Um modelo pedirá alegremente dez mil linhas se você permitir.
-
Retorne resumos, não entidades. Despejar entidades JPA completas no contexto de um modelo é um desperdício e pode vazar campos que você nunca quis expor.
-
Escreva descrições como documentação de API para um leitor que não sabe fazer perguntas. A descrição é o único guia do modelo sobre quando e como chamar sua ferramenta.
-
Aplique o mínimo de privilégios. Uma ferramenta que pode ler pedidos não deve compartilhar uma credencial com outra que possa reembolsá-los.
-
Chamadas de ferramentas de registro e auditoria. Você vai querer saber o que o modelo fez e por quê, especialmente quando estiver agindo sobre dados reais.
Enquanto isso, as habilidades se adequam às equipes Java por um motivo diferente: temos muitas convenções. Estrutura do pacote, política de tratamento de exceções, como escrever um teste de integração baseado em Testcontainers, qual padrão de registro é aceitável, como estruturar uma migração Flyway. Todo esse conhecimento tribal pode viver em uma habilidade. Uma habilidade de “convenções de serviço java” pode dizer ao modelo para preferir injeção de construtor, usar registros para DTOs quando apropriado, evitar injeção de campo e seguir o estilo de nomenclatura de teste de sua equipe, sem repeti-lo em cada prompt.
Um exemplo prático
Digamos que você queira um assistente que ajude na triagem de incidentes de produção.
Você construiria um Servidor MCP que expõe ferramentas para consultar seu agregador de log, buscar implantações recentes e procurar a rotação de plantão de um serviço. Isso é conectividade e precisa de código real, credenciais reais e controles de acesso reais.
Então você escreveria um habilidade chamado de algo como triagem de incidentes. Suas instruções podem dizer: comece verificando a implantação mais recente, compare as taxas de erro antes e depois, observe a integridade da dependência antes de culpar o serviço em si e sempre resuma as descobertas no modelo de incidente da sua equipe. Ele pode agrupar um script que formate o resumo ou um arquivo de referência listando padrões de falha conhecidos para seus serviços críticos.
Sem o servidor MCP, o assistente tem bons instintos e nenhum dado. Sem a habilidade, ele possui dados e julgamento medíocre e provavelmente se fixará na primeira mensagem de erro que encontrar. Juntos, você consegue algo que se comporta como um colega competente.
Quando escolher o quê
Uma regra rápida que uso: se o modelo precisar de acesso, procure o MCP. Se precisar de julgamento, procure uma habilidade.
Procure o MCP quando precisar tocar em um sistema ativo, quando os dados mudam constantemente, quando a ação tem efeitos colaterais que precisam de validação digitada e trilhas de auditoria ou quando vários clientes de IA diferentes devem compartilhar a mesma integração.
Alcance uma habilidade ao codificar um procedimento, um padrão, uma lista de verificação ou um estilo interno, quando o conhecimento é principalmente texto e quando você deseja algo revisável em uma solicitação pull em vez de implantado como um serviço.
Há também uma zona cinzenta. Uma habilidade pode chamar uma ferramenta MCP como uma etapa de um procedimento. Uma habilidade pode agrupar um script que faz o que uma pequena ferramenta MCP poderia ter feito, evitando a necessidade de um servidor. Se o recurso for local, simples e não precisar de infraestrutura compartilhada, um script dentro de uma habilidade costuma ser a resposta mais leve. Se precisar de acesso à rede para um serviço compartilhado com autenticação adequada, esse é o território do servidor.
Erros Comuns
Construindo um servidor MCP para conhecimento estático. Se a “ferramenta” retornar apenas um documento fixo, deveria ser uma habilidade ou um recurso.
Escrever uma habilidade que finge ser uma garantia. Se for absolutamente necessário que uma etapa aconteça, como uma validação que bloqueie uma implantação, não confie em um parágrafo de redução. Torne-o uma ferramenta determinística ou um script e aplique-o fora do modelo.
Expondo muitas ferramentas. Cinquenta ferramentas com nomes vagos confundem o modelo e consomem o contexto. Um conjunto menor de ferramentas bem projetadas e descritas supera consistentemente um conjunto extenso.
Ignorando o limite de confiança. Tudo o que retorna de uma ferramenta ou dos arquivos referenciados de uma habilidade entra no contexto do modelo. Trate-o adequadamente.
A conclusão
MCP e Skills resolvem diferentes metades do mesmo problema. MCP é infraestrutura: um protocolo para alcançar sistemas de forma segura e consistente. Habilidades são conhecimento: uma maneira leve de empacotar como sua equipe faz as coisas para que um modelo possa aprendê-las sob demanda.
Para um desenvolvedor Java sênior, o caminho prático é simples. Envolva seus serviços existentes no MCP onde o acesso ao vivo é realmente necessário, mantendo a mesma disciplina que você aplicaria a qualquer API pública. Em seguida, capture seus padrões de engenharia e fluxos de trabalho como habilidades, versionados junto com seu código. Faça isso e você parará de tratar o modelo como um preenchimento automático inteligente e começará a tratá-lo como um companheiro de equipe que tem acesso e contexto para ser útil.
