Il Model Context Protocol (MCP) è diventato il modo standard per gli agenti IA di utilizzare strumenti esterni. Ma c'è una tensione al suo interno: gli agenti hanno bisogno di molti strumenti per svolgere un lavoro utile, ma ogni strumento aggiunto riempie la finestra di contesto del modello, lasciando meno spazio per il compito effettivo.
Code Mode è una tecnica che abbiamo introdotto per la prima volta per ridurre l'utilizzo della finestra di contesto durante l'uso dello strumento agente. Invece di descrivere ogni operazione come uno strumento separato, lascia che il modello scriva codice su un SDK tipizzato ed esegua il codice in modo sicuro in un Dynamic Worker Loader. Il codice funge da piano compatto. Il modello può esplorare le operazioni degli strumenti, comporre più chiamate e restituire solo i dati di cui ha bisogno. Anthropic ha esplorato in modo indipendente lo stesso modello nel suo post Esecuzione del codice con MCP.
Oggi presentiamo un nuovo server MCP per l'intera API Cloudflare, da DNS e Zero Trust a Workers e R2, che utilizza Code Mode. Con solo due strumenti, search() ed execute(), il server è in grado di fornire l'accesso all'intera API di Cloudflare su MCP, consumando solo circa 1.000 token. L'impronta rimane fissa, indipendentemente dal numero di endpoint API esistenti.
Per un'API di grandi dimensioni come l'API Cloudflare, Code Mode riduce il numero di token di input utilizzati del 99,9%. Un server MCP equivalente senza Code Mode consumerebbe 1,17 milioni di token: più dell'intera finestra di contesto dei modelli di base più avanzati.
Risparmi di Code Mode rispetto a MCP nativo, misurati con tiktoken
Puoi iniziare a utilizzare questo nuovo server Cloudflare MCP oggi stesso. E stiamo anche rendendo open source un nuovo SDK Code Mode nell'SDK di agenti Cloudflare, in modo che tu possa utilizzare lo stesso approccio sia con i server MCP che con gli agenti IA.
Questo nuovo server MCP applica Code Mode lato server. Invece di migliaia di strumenti, il server ne esporta solo due: search() ed execute(). Entrambi sono basati su Code Mode. Ecco l'intera superficie utensile che viene caricata nel contesto del modello:
[
{
"name": "search",
"description": "Search the Cloudflare OpenAPI spec. All $refs are pre-resolved inline.",
"inputSchema": {
"type": "object",
"properties": {
"code": {
"type": "string",
"description": "JavaScript async arrow function to search the OpenAPI spec"
}
},
"required": ["code"]
}
},
{
"name": "execute",
"description": "Execute JavaScript code against the Cloudflare API.",
"inputSchema": {
"type": "object",
"properties": {
"code": {
"type": "string",
"description": "JavaScript async arrow function to execute"
}
},
"required": ["code"]
}
}
]
Per scoprire cosa può fare, l'agente chiama search(). Scrive JavaScript su una rappresentazione tipizzata delle specifiche OpenAPI. L'agente può filtrare gli endpoint in base al prodotto, al percorso, ai tag o a qualsiasi altro metadato e limitare migliaia di endpoint al numero minimo necessario. La specifica OpenAPI completa non entra mai nel contesto del modello. L'agente interagisce con esso solo tramite il codice.
Quando l'agente è pronto ad agire, chiama execute(). L'agente scrive codice che può effettuare chiamate API Cloudflare, gestire l'impaginazione, controllare le risposte e concatenare le operazioni in un'unica esecuzione.
Entrambi gli strumenti eseguono il codice generato all'interno di un Dynamic Worker isolato, una sandbox V8 leggera senza file system, senza variabili d'ambiente che possano essere esposte tramite iniezione di prompt e con richieste esterne disabilitate per impostazione predefinita. Le richieste in uscita possono essere controllate in modo esplicito con i gestori di recupero in uscita quando necessario.
Esempio: Protezione di un'origine dagli attacchi DDoS
Supponiamo che un utente dica al proprio agente: "proteggi la mia origine dagli attacchi DDoS". Il primo passo dell’agente è consultare la documentazione. Potrebbe chiamare il server MCP di Cloudflare Docs, utilizzare una skill Cloudflare o eseguire ricerche direttamente sul Web. Dalla documentazione apprende: metti le regole di Cloudflare WAF e di protezione da attacchi DDoS davanti all'origine.
Fase 1: Ricerca degli endpoint giusti
Lo strumento di ricerca fornisce al modello un oggetto spec: la specifica OpenAPI di Cloudflare completa con tutti i $refs prerisolti. Il modello scrive JavaScript su di esso. Qui l'agente cerca gli endpoint WAF e set di regole su una zona:
async () => {
const results = [];
for (const [path, methods] of Object.entries(spec.paths)) {
if (path.includes('/zones/') &&
(path.includes('firewall/waf') || path.includes('rulesets'))) {
for (const [method, op] of Object.entries(methods)) {
results.push({ method: method.toUpperCase(), path, summary: op.summary });
}
}
}
return results;
}
Il server esegue questo codice in un Workers isolato e restituisce:
[
{ "method": "GET", "path": "/zones/{zone_id}/firewall/waf/packages", "summary": "List WAF packages" },
{ "method": "PATCH", "path": "/zones/{zone_id}/firewall/waf/packages/{package_id}", "summary": "Update a WAF package" },
{ "method": "GET", "path": "/zones/{zone_id}/firewall/waf/packages/{package_id}/rules", "summary": "List WAF rules" },
{ "method": "PATCH", "path": "/zones/{zone_id}/firewall/waf/packages/{package_id}/rules/{rule_id}", "summary": "Update a WAF rule" },
{ "method": "GET", "path": "/zones/{zone_id}/rulesets", "summary": "List zone rulesets" },
{ "method": "POST", "path": "/zones/{zone_id}/rulesets", "summary": "Create a zone ruleset" },
{ "method": "GET", "path": "/zones/{zone_id}/rulesets/phases/{ruleset_phase}/entrypoint", "summary": "Get a zone entry point ruleset" },
{ "method": "PUT", "path": "/zones/{zone_id}/rulesets/phases/{ruleset_phase}/entrypoint", "summary": "Update a zone entry point ruleset" },
{ "method": "POST", "path": "/zones/{zone_id}/rulesets/{ruleset_id}/rules", "summary": "Create a zone ruleset rule" },
{ "method": "PATCH", "path": "/zones/{zone_id}/rulesets/{ruleset_id}/rules/{rule_id}", "summary": "Update a zone ruleset rule" }
]
La specifica completa dell’API Cloudflare ha oltre 2.500 endpoint. Il modello ha ristretto il campo agli endpoint WAF e al set di regole di cui ha bisogno, senza che nessuna delle specifiche entrasse nella finestra di contesto.
Il modello può anche approfondire lo schema di un endpoint specifico prima di chiamarlo. Qui esamina quali fasi sono disponibili sui set di regole di zona:
async () => {
const op = spec.paths['/zones/{zone_id}/rulesets']?.get;
const items = op?.responses?.['200']?.content?.['application/json']?.schema;
// Walk the schema to find the phase enum
const props = items?.allOf?.[1]?.properties?.result?.items?.allOf?.[1]?.properties;
return { phases: props?.phase?.enum };
}
{
"phases": [
"ddos_l4", "ddos_l7",
"http_request_firewall_custom", "http_request_firewall_managed",
"http_response_firewall_managed", "http_ratelimit",
"http_request_redirect", "http_request_transform",
"magic_transit", "magic_transit_managed"
]
}
L'agente ora conosce le fasi esatte di cui ha bisogno: ddos_l7 per la protezione da attacchi DDoS e http_request_firewall_managed per WAF.
Fase 2: Agire sull'API
L'agente passa all'utilizzo di execute. La sandbox ottiene un client cloudflare.request() in grado di effettuare chiamate autenticate all'API Cloudflare. Per prima cosa l'agente controlla quali set di regole esistono già nella zona:
async () => {
const response = await cloudflare.request({
method: "GET",
path: `/zones/${zoneId}/rulesets`
});
return response.result.map(rs => ({
name: rs.name, phase: rs.phase, kind: rs.kind
}));
}
[
{ "name": "DDoS L7", "phase": "ddos_l7", "kind": "managed" },
{ "name": "Cloudflare Managed","phase": "http_request_firewall_managed", "kind": "managed" },
{ "name": "Custom rules", "phase": "http_request_firewall_custom", "kind": "zone" }
]
L’agente vede che i set di regole DDoS e WAF gestiti esistono già. Ora può concatenare le chiamate per ispezionare le loro regole e aggiornare i livelli di sensibilità in un'unica esecuzione:
async () => {
// Get the current DDoS L7 entrypoint ruleset
const ddos = await cloudflare.request({
method: "GET",
path: `/zones/${zoneId}/rulesets/phases/ddos_l7/entrypoint`
});
// Get the WAF managed ruleset
const waf = await cloudflare.request({
method: "GET",
path: `/zones/${zoneId}/rulesets/phases/http_request_firewall_managed/entrypoint`
});
}
L'intera operazione, dalla ricerca delle specifiche e dall'ispezione di uno schema all'elenco dei set di regole e al recupero delle configurazioni DDoS e WAF, ha richiesto quattro chiamate di strumenti.
Abbiamo iniziato con i server MCP per i singoli prodotti. Vuoi un agente che gestisca il DNS? Aggiungi il server MCP DNS. Vuoi i log Workers? Aggiungi il server MCP Workers Observability. Ogni server ha esportato un set fisso di strumenti mappati alle operazioni API. Funzionava quando il set di strumenti era piccolo, ma l'API di Cloudflare ha oltre 2.500 endpoint. Nessun insieme di server gestiti manualmente potrebbe tenere il passo.
Il server Cloudflare MCP semplifica questa operazione. Due strumenti, circa 1.000 token e la copertura di ogni endpoint nell'API. Quando aggiungiamo nuovi prodotti, gli stessi percorsi di codice search() ed execute() li rilevano e li chiamano, senza nuove definizioni di strumenti, né nuovi server MCP. Ha persino il supporto per l'API GraphQL Analytics.
Il nostro server MCP è basato sulle ultime specifiche MCP. È compatibile con OAuth 2.1 e utilizza Workers OAuth Provider per limitare l'ambito del token alle autorizzazioni selezionate approvate dall'utente al momento della connessione. L’agente ottiene solo le funzionalità concesse esplicitamente dall’utente.
Per gli sviluppatori, questo significa che è possibile utilizzare un semplice ciclo di agenti e comunque consentire al proprio agente di accedere all'API completa di Cloudflare con funzionalità di rilevamento progressivo integrate.
Confronto degli approcci alla riduzione del contesto
Sono emersi diversi approcci per ridurre il numero di token consumati dagli strumenti MCP:
Code Mode lato client è stato il nostro primo esperimento. Il modello scrive TypeScript su SDK tipizzati e lo esegue in un Dynamic Worker Loader sul client. Il compromesso è che richiede che l'agente venga distribuito con un accesso sandbox sicuro. Code Mode è implementata in Goose e Anthropics Claude SDK come Programmatic Tool Calling.
Le interfacce della riga di comando (CLI) sono un altro percorso. Le CLI sono auto-documentanti e rivelano le funzionalità man mano che l'agente esplora. Strumenti come OpenClaw e Moltworker convertono i server MCP in CLI utilizzando MCPorter per fornire agli agenti una divulgazione progressiva. Il limite è ovvio: l'agente necessita di una shell, che non tutti gli ambienti forniscono e che introduce una superficie d'attacco molto più ampia rispetto a un isolato sandbox.
La ricerca dinamica degli strumenti, come quella utilizzata da Anthropic in Claude Code, evidenzia un set più piccolo di strumenti, auspicabilmente pertinenti all'attività corrente. Riduce l'uso del contesto ma ora richiede una funzione di ricerca che deve essere gestita e valutata, e ogni strumento corrispondente continua a utilizzare i token.
Ogni approccio risolve un problema reale. Ma specificamente per i server MCP, la modalità codice lato server combina i suoi punti di forza: costo fisso del token indipendentemente dalle dimensioni dell'API, nessuna modifica necessaria sul lato agente, rilevamento progressivo integrato ed esecuzione sicura all'interno di un ambiente isolato sandbox. L'agente richiama semplicemente due strumenti tramite codice. Tutto il resto avviene sul server.
Il server Cloudflare MCP è ora disponibile. Indirizza il tuo client MCP all'URL del server e verrai reindirizzato a Cloudflare per autorizzare e selezionare i permessi da concedere al tuo agente. Aggiungi questa configurazione al tuo client MCP:
{
"mcpServers": {
"cloudflare-api": {
"url": "https://mcp.cloudflare.com/mcp"
}
}
}
Per CI/CD, automazione o se preferisci gestire tu stesso i token, crea un token API Cloudflare con le autorizzazioni di cui hai bisogno. Sono supportati sia i token utente che quelli account e possono essere passati come token portatore nell'intestazione Authorization.
Ulteriori informazioni sulle diverse configurazioni di installazione MCP sono disponibili nel repository Cloudflare MCP.
Code Mode risolve i costi di contesto per una singola API. Ma gli agenti raramente parlano con un solo servizio. L'agente di uno sviluppatore potrebbe aver bisogno dell'API Cloudflare insieme a GitHub, un database e un server di documentazione interno. Ogni server MCP aggiuntivo comporta la stessa pressione della finestra di contesto con cui abbiamo iniziato.
I portali server MCP di Cloudflare ti consentono di comporre più server MCP dietro un unico gateway con autenticazione unificata e controllo degli accessi. Stiamo sviluppando un'integrazione Code Mode di prima classe per tutti i tuoi server MCP e li stiamo esponendo ad agenti con rilevamento progressivo integrato e la stessa impronta di token fisso, indipendentemente dal numero di servizi presenti dietro il gateway.