Competenze degli agenti vs server MCP: framework decisionale

Le competenze degli agenti e i server MCP vengono spesso presentati come modi alternativi per estendere un agente AI. Questa inquadratura è errata: una competenza insegna all’agente come lavorare, mentre un server MCP gli fornisce accesso governato a funzionalità live.

La domanda utile non è “Quale standard vince?” È “Dove dovrebbe risiedere questa responsabilità?” Questa guida risponde a questa domanda per assistenti ospitati come Hermes Agent e OpenClaw, dove la dimensione del contesto, le connessioni a lungo termine, le credenziali e la sicurezza operativa contano più di una demo ordinata.

Non si tratta di un confronto accademico. È un framework decisionale pratico costruito dall’esperienza reale di deployment con entrambi i meccanismi, inclusi i compromessi sui costi di contesto che diventano visibili solo quando un agente è in esecuzione in produzione. Se stai costruendo sistemi multi-agente, potresti anche voler leggere il nostro confronto protocolli A2A contro MCP, che copre un asse diverso dello stesso spazio di problemi.

Competenze Agenti contro Server MCP in una Tabella

Usa una competenza per procedure, giudizi e conoscenze operative riutilizzabili. Usa un server MCP per stato autorevole, operazioni protette e un contratto stabile di funzionalità.

Il mio approccio di default è deliberatamente conservatore: inizia con una competenza quando il lavoro è locale, prevalentemente in lettura e procedurale. Aggiungi un server MCP quando l’agente attraversa un confine di fiducia, tocca stato esterno mutevole o ha bisogno di un’operazione che dovrebbe rimanere corretta anche quando il modello è confuso.

La Distinzione Fondamentale: Procedura contro Funzionalità

Una Competenza Agente è una directory centrata su SKILL.md, con script, riferimenti e asset opzionali. La specifica delle competenze degli agenti definisce metadati obbligatori e un modello di disclosure progressiva: l’host può scoprire prima un nome e una descrizione piccoli, caricare le istruzioni complete quando rilevanti e recuperare i file di supporto solo quando necessario.

Questo rende la competenza una casa forte per una rubrica incidenti, una checklist di rilascio, un metodo di ricerca o istruzioni per l’uso di un strumento command-line esistente. Il suo valore centrale è la procedura codificata: sequenza, giudizio, vincoli, esempi e la definizione di un buon risultato. Per dettagli specifici su Hermes sull’autore delle competenze inclusa la struttura del frontmatter e l’attivazione condizionale, vedi Autore Competenze Hermes Agent.

MCP risolve un problema diverso. La specifica del protocollo Model Context fornisce a client e server un contratto basato su JSON-RPC per funzionalità incluse strumenti, risorse e prompt, con trasporti standard e comportamento di discovery. Guide pratiche per l’implementazione di server MCP in Python e server MCP in Go mostrano quanto sia semplice il livello di integrazione una volta che il protocollo gestisce il lavoro pesante.

Un server MCP è quindi un buon confine attorno a un sistema ticket, piano di controllo cloud, database di verità o servizio di ricerca interno. Possiede la meccanica per raggiungere quel sistema e può eseguire validazione, autorizzazione, timeout, limiti di velocità e comportamento di audit al di fuori delle istruzioni in prosa del modello.

Una Regola Più Precisa

Chiediti se una responsabilità deve rimanere corretta senza che il modello ricordi un’istruzione. Se la risposta è sì, appartiene a codice deterministico o politica server, non solo a SKILL.md.

Ad esempio, “raccolti tre segnali di supporto prima di escalare” è un’istruzione di competenza utile. “Rifiuta un cambiamento di stato a meno che il chiamante non abbia lo scope incident-manager” deve essere eseguito dal servizio o dal server MCP, anche se la competenza ripete la regola.

Questo è il confine che conta:

• Una competenza può dire all’agente quando un’azione è appropriata.
• Uno strumento MCP può rendere l’azione disponibile attraverso un’interfaccia tipizzata.
• Il servizio di supporto deve decidere se l’azione è effettivamente consentita.

I server MCP possono anche esporre prompt, quindi gli standard si sovrappongono ai margini. Tuttavia, mettere un’intera procedura operativa in una descrizione di strumento enorme produce solitamente un catalogo di funzionalità fragile, mentre mettere un client API privilegiato in uno script shell nascosto dentro una competenza produce solitamente un problema di sicurezza evitabile.

Quando un SKILL.md è Abbastanza

Una competenza è sufficiente quando l’agente ha già accesso sicuro a tutto ciò che serve e l’ingrediente mancante è il know-how. Questo è comune per analisi repository, trasformazione documenti, generazione report o un workflow locale costruito su comandi CLI maturi.

I Dati sono Locali o Forniti dall’Utente

Supponiamo che un agente debba ispezionare un repository checked-out, eseguire linter read-only, confrontare file di configurazione e produrre un report di migrazione. I file sono già nell’ambiente di lavoro e l’host espone già strumenti filesystem e processo, quindi un altro servizio di rete aggiunge poco valore.

La competenza può descrivere quali file ispezionare, l’ordine dei comandi, la gestione degli errori e le prove richieste. Uno script incluso può normalizzare l’output, ma il sandbox esistente dell’host e i permessi di comando rimangono il confine di esecuzione effettivo.

Il Workflow Dipende dal Giudizio

Le competenze sono particolarmente utili quando esistono diverse azioni tecnicamente valide ma l’organizzazione preferisce un metodo operativo specifico. Una competenza code-review può spiegare quali rischi meritano commenti bloccanti, quando richiedere una riproduzione e come separare le questioni di correttezza da quelle di gusto.

Quelle regole cambiano man mano che i team imparano. Tenerle come prosa versionata e piccoli riferimenti è spesso più chiaro che ricompilare o ridistribuire un server per ogni aggiustamento editoriale.

La Portabilità Conta Più del Controllo Centrale

Il formato aperto delle competenze degli agenti è progettato come una cartella portatile piuttosto che un runtime remoto. Una competenza ben definita può spostarsi tra host compatibili con le sue istruzioni, esempi e asset di supporto intatti, anche se i nomi degli strumenti e il comportamento del sandbox richiedono ancora test specifici per l’host.

Questa portabilità è utile per workflow Hermes Agent e OpenClaw che condividono un metodo ma non necessariamente lo stesso deployment. Tieni le note specifiche per l’host in riferimenti brevi invece di forcare la procedura principale alla prima differenza. La guida all’ecosistema competenze OpenClaw copre quali competenze vale la pena installare e come limitarle in modo sicuro per ruolo agente.

Una CLI Esistente Fornisce Già la Funzionalità

Non costruire un server solo per avvolgere un comando locale affidabile. Se un assistente single-user può chiamare una CLI ristretta che già gestisce autenticazione, output strutturato ed errori, una competenza può essere la soluzione più piccola e mantenibile.

La cautela è importante: una CLI non è automaticamente sicura perché è locale. Evita l’interpolazione shell ampia, preferisci l’output strutturato, limita i target scrivibili e non trattare la lista di strumenti suggerita dalla competenza come un sistema di autorizzazione completo.

Quando Hai Bisogno di un Server MCP

Scegli MCP quando il problema non è solo ricordare cosa fare. Un server MCP diventa prezioso quando l’agente ha bisogno di un ponte duraturo, tipizzato e governabile verso un sistema mutevole.

Lo Stato è Live e Autorevole

Ticket clienti, stato deployment, inventario, record fatturazione e metriche di produzione possono cambiare tra due turni del modello. Copiare quello stato in una competenza lo rende obsoleto per costruzione, mentre chiedere al modello di scrapare un’interfaccia produce un contratto instabile.

Una risorsa o strumento MCP può recuperare il record corrente al momento dell’esecuzione. Il server può normalizzare le peculiarità upstream e restituire un risultato compatto invece di esporre un’intera risposta vendor al modello.

Sono Coinvolte Credenziali o Identità Utente

Le credenziali non dovrebbero vivere in SKILL.md, esempi o script helper inclusi. Per deployment HTTP remoti, la specifica di autorizzazione MCP definisce un modello basato su OAuth; per server stdio locali, le credenziali possono essere fornite attraverso l’ambiente del processo o un altro meccanismo controllato dall’host. Vedi la guida ufficiale all’autorizzazione MCP.

La ragione più profonda per usare un server non è solo lo storage dei segreti. Un server può mappare l’identità agli scope, limitare i tenant, redigere campi e registrare chi ha richiesto una mutazione, mentre un’istruzione in prosa può solo chiedere al modello di comportarsi bene.

Le Scritte Hanno Bisogno di Garanzie Transazionali

Creare una fattura, cambiare lo stato di un ticket o avviare un deployment richiede più di un oggetto JSON plausibile. L’operazione può avere bisogno di chiavi di idempotenza, concorrenza ottimistica, validazione server-side e un trail di audit duraturo.

Queste proprietà appartengono sotto il modello. La competenza può definire la politica di approvazione, ma il server MCP dovrebbe rifiutare una transizione invalida e rendere sicuro un richiesta ritentata.

Multipli Agenti Hanno Bisogno della Stessa Funzionalità

Un server MCP condiviso può presentare un contratto unico a diversi host agenti, linguaggi e provider modello. Questo dà ai team piattaforma un posto centrale per migliorare schemi, patchare il comportamento upstream API e applicare controlli di accesso senza copiare la logica di integrazione in ogni competenza.

La centralizzazione non è gratuita. Il server diventa una dipendenza operata con versioning, osservabilità, disponibilità e obblighi di risposta incidenti, quindi dovrebbe meritare la sua esistenza con un confine reale piuttosto che entusiasmo architetturale.

La Domanda sui Costi di Contesto

Il costo del contesto è frequentemente ridotto allo slogan “le competenze sono progressive, gli strumenti sono sempre caricati”. Gli host reali sono più sfumati e la differenza dovrebbe essere misurata in input modello serializzato piuttosto che assunta dal formato di estensione.

La documentazione delle competenze degli agenti descrive approssimativamente 100 token di metadati di discovery per competenza, raccomanda di mantenere le istruzioni attivate sotto 5.000 token e permette ai riferimenti di caricarsi on demand. Una stima semplice di pianificazione è:

C_skill = metadati discovery + istruzioni attivate + riferimenti selezionati

I client MCP scoprono definizioni strumento dai server, ma il protocollo non richiede che ogni schema scoperto appaia in ogni chiamata modello. Gli host possono filtrare, differire, cacheare o instradare strumenti, quindi la stima pratica è:

C_mcp = schemi strumenti esposti a questo turno + risultati strumenti trattenuti nel contesto

La specifica degli strumenti MCP nota anche che un ordinamento stabile degli strumenti può migliorare il comportamento della cache prompt. La cache può ridurre il costo di elaborazione ripetuta, ma non rende un catalogo eccessivo più facile per un modello da cui scegliere.

Un Budget Token Illustrativo

Considera un assistente ospitato con 20 competenze installate. Al costo di discovery approssimativo della documentazione delle competenze degli agenti, l’indice compatto delle competenze è intorno a 2.000 token; attivare una competenza triage focalizzata potrebbe aggiungere altri 1.200 token e un riferimento da 600 token.

Ora confronta due design MCP. Un server ticket sottile con quattro schemi concisi potrebbe serializzarsi in 500-800 token, mentre un server enterprise ampio con 35 strumenti verbosi potrebbe consumare diversi migliaia di token prima che arrivi qualsiasi risultato.

Questi sono numeri di pianificazione illustrativi, non garanzie di protocollo o benchmark. Misura il prompt esatto generato dal tuo host perché verbosità schema, descrizioni, instradamento, ritenzione risultati e scelta tokenizer possono spostare il totale sostanzialmente.

La conclusione pratica non è “le competenze sono economiche” o “MCP è costoso”. È che disclosure progressiva e selezione funzionalità sono caratteristiche architettoniche: mantieni i metadati delle competenze discriminativi, attiva solo istruzioni rilevanti, esponi il set più piccolo di strumenti utile e restituisci proiezioni invece di payload upstream grezzi.

Il Pattern Thin-Server: MCP Sotto, Competenza Sopra

Il design più duraturo spesso combina entrambi i meccanismi. Metti un piccolo confine di funzionalità in MCP, poi metti il metodo operativo in una competenza che lo chiama.

Considera un workflow incidenti supporto usato da Hermes Agent o OpenClaw. L’agente deve leggere un ticket, raccogliere prove, classificare la severità, abbozzare una nota operatore e cambiare stato solo dopo l’approvazione richiesta.

Cosa Possiede il Server MCP

Mantieni l’interfaccia del server stretta e letterale:

Il server non dovrebbe contenere uno strumento chiamato triage_everything con una descrizione di un paragrafo e una dozzina di flag non correlati. Quattro operazioni limitate sono più facili da autorizzare, testare, osservare e riutilizzare.

Cosa Possiede la Competenza

La competenza possiede la sequenza e il giudizio. Un SKILL.md compatto potrebbe apparire così:

---
name: incident-triage
description: Triage support incidents using ticket evidence and the severity rubric.
---

1. Read the ticket and its current version.
2. Collect at least two independent signals before assigning severity.
3. Separate observed facts from hypotheses in the note.
4. Ask for operator approval before any customer-visible note or status change.
5. Re-read the ticket before a write; stop if its version changed.
6. End with severity, evidence, uncertainty, and recommended next action.

Quel file è leggibile, revisionabile e facile da rivedere quando la politica triage cambia. Un riferimento collegato può contenere la rubrica severità, mentre le istruzioni principali rimangono abbastanza corte da attivare senza trascinare un manuale operativo in ogni turno.

Come Funziona in Hermes Agent

La documentazione MCP nativa di Hermes Agent descrive discovery all’avvio, connessioni persistenti, trasporti stdio e Streamable HTTP e strumenti MCP namespaced. La sua configurazione attuale filtra anche l’ambiente per server stdio e passa variabili configurate esplicitamente, il che è una difesa utile contro eredità accidentale di segreti.

In questo design, Hermes scopre i quattro strumenti ticket, mentre la competenza incidenti si attiva solo per richieste rilevanti. Il modello segue la competenza, il server MCP esegue operazioni limitate e il servizio ticket rimane l’autorità finale.

Come Funziona in OpenClaw

La documentazione competenze di OpenClaw segue la struttura delle competenze degli agenti e costruisce una lista compatta di competenze eleggibili per il modello. La stessa cartella incidenti può trasportare la procedura principale, con un breve riferimento specifico per l’host che spiega i nomi degli strumenti ticket disponibili.

Non mettere il token ticket nella competenza condivisa. OpenClaw tratta esplicitamente le competenze condivise come input piuttosto che storage di segreti, e le competenze di terze parti dovrebbero essere revisionate come codice non fidato prima che siano abilitate.

Perché la Separazione Sopravvive al Cambiamento

Se il team supporto rivede la sua rubrica severità, aggiorna la competenza. Se il vendor ticket cambia autenticazione o paginazione, aggiorna il server MCP senza riscrivere la politica operativa.

Se arriva un secondo host agente, può riutilizzare lo stesso contratto MCP e adattare il piccolo layer specifico per l’host della competenza. Questa separazione riduce la logica di integrazione duplicata senza trasformare ogni modifica procedurale in un deployment servizio.

Un Framework Decisionale in Cinque Passi

La seguente sequenza è più affidabile che scegliere prima il tipo di estensione alla moda.

1. Identifica la Fonte di Verità

Scrivi ogni input e output che il workflow tocca. Guida statica, file repository e documenti forniti dall’utente spingono verso una competenza; record remoti mutevoli e sistemi autorevoli spingono verso MCP.

Non tutto lo stato giustifica un server. Un artefatto di build locale è stato, ma una CLI sandboxata esistente può già fornire un confine sufficiente.

2. Localizza il Confine di Fiducia

Segna dove appaiono credenziali, identità tenant, dati privilegiati o azioni irreversibili. Se l’agente attraversa quella linea, introduci un punto di enforcement deterministico, tipicamente un server MCP supportato da autorizzazione servizio.

Tratta il modello e la competenza come pianificatori di richieste, non motori di politica. Possono proporre un’azione consentita, ma non dovrebbero essere in grado di ridefinire il permesso cambiando le loro stesse istruzioni.

3. Separa Funzionalità da Politica

Nomina funzionalità come verbi stretti con input tipizzati: ottieni un ticket, aggiungi una nota o cambia stato. Metti le condizioni per scegliere quei verbi, lo standard di prove e la sequenza preferita nella competenza.

Alcuna politica deve esistere in entrambi i layer per ragioni diverse. “Chiedi all’utente prima di distribuire” appartiene alla competenza per qualità interazione, mentre “rifiuta deployment senza un token approvazione” appartiene al codice per enforcement.

4. Stima Costo Contesto e Operativo

Cattura un trace prompt reale e conta i metadati competenza, istruzioni attivate, definizioni strumenti e dati restituiti. Poi aggiungi il costo non-token di un servizio MCP: deployment, autenticazione, monitoraggio, versioning e ownership on-call.

Se un catalogo da 30 strumenti supporta un workflow, esponi un sottoinsieme specifico per il task o dividi il server per dominio di funzionalità coerente. Se una competenza carica ripetutamente un riferimento da 200 pagine, crea un passo di retrieval o riferimenti più piccoli invece di congratularti per la disclosure progressiva.

5. Testa il Confine, Poi il Comportamento

Testa il server MCP come software e la competenza come comportamento agente. Falliscono in modo diverso e un singolo transcript chat happy-path nasconde entrambe le classi di difetti.

Per la sicurezza degli strumenti, la specifica MCP raccomanda validazione input, controlli accesso, limiti velocità, sanitizzazione output, timeout, conferme per operazioni sensibili e logging audit. Le annotazioni strumento sono suggerimenti, non prova fidata che un’operazione è read-only o innocua. La guida alla sicurezza agenti A2A e MCP copre il modello di minaccia più ampio inclusa iniezione prompt e avvelenamento strumenti.

Regole di Sicurezza che Non Stanno in uno Slogan

Le competenze riducono la necessità di alcuni server, ma non rimuovono il rischio. Una competenza può includere script e può persuadere un agente a chiamare potenti strumenti host, quindi revisiona le sue istruzioni e file eseguibili come codice, fissa versioni fidate e limita gli strumenti host disponibili alla sessione.

MCP aggiunge un altro confine: un subprocess locale o servizio remoto con le proprie dipendenze, input, output e credenziali. Applica il privilegio minimo, valida l’audience della risorsa per autorizzazione remota, usa HTTPS, sanizza contenuto non fidato e mantieni l’approvazione visibile per scritture consequenziali.

Più importante di tutto, non confondere la discoverability con l’autorità. Uno strumento che appare nel catalogo del modello non significa che l’utente corrente dovrebbe essere permesso di eseguire ogni operazione che descrive.

Anti-Pattern Comuni

Nascondere un Client API Remoto in una Competenza

Uno script shell che legge un token bearer statico e chiama un’API di produzione può funzionare in una demo. Mescola anche procedura, credenziali, comportamento di rete e autorizzazione in un pacchetto progettato per essere copiato e letto da host agenti.

Sposta l’integrazione protetta dietro un server stretto o una CLI approvata esistente. Tieni solo il workflow e la guida di chiamata nella competenza.

Codificare il Workflow nelle Descrizioni Strumento

Le descrizioni strumento dovrebbero aiutare il modello a selezionare una funzionalità e riempire il suo schema. Sono un sostituto povero per una procedura operativa multi-step con esempi, eccezioni, regole escalation e convenzioni output.

Descrizioni lunghe gonfiano ogni turno in cui lo strumento è esposto e rendono il contratto servizio più difficile da riutilizzare. Metti la procedura in una competenza e mantieni la semantica degli strumenti precisa.

Costruire uno Strumento execute_anything

Una shell generica, SQL o proxy HTTP collassa molti permessi in una funzionalità difficile da auditare. Sposta la validazione al modello e rende il privilegio minimo principalmente fittizio.

Espone operazioni allineate ad azioni aziendali reali. Se operatori esperti hanno davvero bisogno di un’uscita di emergenza, separala, limitala e richiedi approvazione e logging più forti.

Pubblicare un Server MCP Kitchen-Sink

Un server con decine di strumenti non correlati appesantisce la selezione, il contesto schema, i permessi e la manutenzione. Dividi per dominio coerente o lascia che l’host esponga un sottoinsieme rilevante per il task corrente.

La guida FastMCP di Hermes Agent fa una raccomandazione iniziale sensata: inizia con uno a tre endpoint ad alto valore e preferisci un server sottile con nomi e schemi chiari. Vedi la documentazione ufficiale della competenza FastMCP.

Trattare Suggerimenti Strumento come Politica di Sicurezza

Un campo sperimentale allowed-tools o un’annotazione read-only di uno strumento possono migliorare il comportamento dell’host, ma nessuno dei due sostituisce sandboxing e autorizzazione server-side. I metadati possono essere obsoleti, configurati male o forniti da un componente non fidato.

Usa suggerimenti per migliorare l’interfaccia. Usa codice e infrastrutture per eseguire il confine.

Usare MCP per Conoscenza Statica

Se una procedura o riferimento cambia solo con il repository, un round trip remoto aggiunge costi di deployment e disponibilità senza rendere l’informazione più autorevole. Pacchettizza materiale conciso con la competenza e versionalo con il workflow.

Introduci un servizio retrieval solo quando il corpus è grande, access-controlled, aggiornato indipendentemente o ha davvero bisogno di ricerca. L’architettura dovrebbe seguire il ciclo di vita dei dati, non l’acronimo.

Decisione Finale: Competenza, Server MCP o Entrambi?

Scegli una Competenza Agente quando la parte difficile è sapere cosa fare. Scegli un server MCP quando la parte difficile è raggiungere in sicurezza qualcosa che cambia, appartiene a un altro dominio di fiducia o deve eseguire un contratto.

Scegli entrambi quando un workflow reale ha bisogno di giudizio sopra una funzionalità protetta. Non è duplicazione: la competenza rende l’agente utile, il server rende l’integrazione governabile e il sistema di supporto rende la decisione finale autorevole.

Per la maggior parte degli assistenti ospitati, la prima architettura migliore è modesta: una competenza focalizzata, una superficie MCP piccola solo dove l’accesso live lo richiede e un trace prompt catturato per verificare il costo del contesto. Aggiungi complessità dopo che il confine è chiaro, non prima.

Riferimenti

• Specifiche competenze degli agenti
• Specifiche protocollo Model Context
• Guida autorizzazione MCP
• Documentazione MCP nativa Hermes Agent
• Documentazione competenze OpenClaw
• Documentazione competenza FastMCP