Un assistente AI in casa sa ragionare ma non sa cosa è successo cinque minuti fa.
Se hai già messo in piedi un ChatGPT privato con Ollama + Open WebUI, conosci il limite: il modello è bravissimo a sintetizzare, scrivere codice, rispondere a domande. Ma vive in una bolla. Non legge una pagina web, non controlla una documentazione aggiornata, non sa nulla che non fosse nel suo training. Gli manca un agente AI di scraping locale: occhi per leggere internet in tempo reale senza uscire da casa. È un cervello senza occhi.
La soluzione ovvia sarebbe collegarlo a un servizio cloud di scraping — ScraperAPI, Firecrawl, ScrapingBee. E qui crolla tutto. Il senso di un'AI self-hosted è che i tuoi prompt e i dati che legge non escono da casa. Appoggiarsi a un'API esterna per leggere il web significa rispedire metà del traffico a un terzo, pagandolo. La promessa zero-cloud si rompe al primo fetch.
Scrapling risolve esattamente questo. È un framework Python di scraping adattivo (BSD-3, quasi 58k stelle su GitHub, ultima release v0.4.8 dell'11 maggio 2026) con un dettaglio che cambia le carte: ha un MCP server integrato. Lo avvii con un comando e diventa un set di tool che il tuo LLM locale può chiamare per leggere il web reale, restando interamente dentro la tua rete.
Cosa serve per un agente AI di scraping locale
Questo tutorial parte dallo stack che abbiamo già documentato: Ollama + Open WebUI in Docker. Se non ce l'hai, parti da lì — il setup è descritto nel post sul ChatGPT privato in casa. Qui aggiungiamo solo un tassello: un MCP tool server. I prerequisiti operativi sono pochi e tutti self-hosted.
Ollama + Open WebUI già funzionanti (vedi prerequisito sopra)
Un modello Ollama che supporta il tool calling — questo è il punto critico, ci torniamo sotto
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Intelligenza Artificiale
MoneyPrinterTurbo: footage a tema in automatico con una patch al prompt (Parte 2.5)
Il footage di MoneyPrinterTurbo non c'entra col tema? Non è il tool, è il prompt. Una patch di poche righe e il sistema genera footage a tema in automatico, tech o lifestyle. Parte 2.5.
Python 3.10 o superiore (requisito minimo di Scrapling)
Spazio su disco: scrapling install scarica le dipendenze browser, parliamo di centinaia di MB
Installa Scrapling e avvia l'MCP server
Il cuore del setup è Scrapling stesso: una volta installato, espone i suoi tool di scraping via MCP con un singolo comando. L'installazione richiede due passaggi distinti — il pip install non basta da solo, perché le funzioni stealth hanno bisogno delle dipendenze browser scaricate a parte. Saltare il secondo comando è l'errore più comune e fa fallire silenziosamente i fetch.
Fatto questo, hai due modi di avviare l'MCP server. La modalità default (stdio) serve quando un proxy lo lancia come sottoprocesso; la modalità HTTP serve quando vuoi parlarci via rete. Sempre dalla doc ufficiale:
bash
# stdio (default) — il server resta in attesa su stdin/stdout
scrapling mcp
# Streamable HTTP — espone il server in rete
scrapling mcp --http
# HTTP vincolato a localhost (consigliato in homelab)
scrapling mcp --http --host '127.0.0.1' --port 8000
Il server espone 10 tool: get, bulk_get, fetch, bulk_fetch, stealthy_fetch, bulk_stealthy_fetch, screenshot più tre per la gestione sessioni (open_session, close_session, list_sessions). Quello interessante è stealthy_fetch: usa il browser stealth di Scrapling per bypassare il Cloudflare Turnstile e le pagine interstiziali — la capacità anti-bot che di solito paghi a un servizio cloud, qui gira gratis e on-prem.
Collegarlo a Open WebUI: due strade
Open WebUI può consumare lo Scrapling MCP server in due modi, e la scelta cambia quanti componenti devi gestire. La via storica e tuttora raccomandata passa dal proxy mcpo, che traduce MCP in OpenAPI; la via nativa, disponibile dalla v0.6.31, salta il proxy ma accetta solo il transport Streamable HTTP. Vediamole entrambe, perché servono a profili diversi.
Via A — mcpo (OpenAPI), la raccomandata
mcpo (open-webui/mcpo, MIT) è descritto dai suoi autori come "a dead-simple proxy that takes an MCP server command and makes it accessible via standard RESTful OpenAPI". In pratica fa girare scrapling mcp in stdio e ne pubblica i tool come normale API REST documentata. Si installa e si avvia così:
bash
pip install mcpo
# mcpo davanti allo Scrapling MCP server (stdio)
mcpo --port 8000 --api-key "top-secret" -- scrapling mcp
mcpo genera in automatico lo schema OpenAPI e una Swagger UI navigabile su http://localhost:8000/docs; ogni tool è raggiungibile su http://localhost:8000/<tool-name>. Apri quella pagina prima di toccare Open WebUI: se vedi i 10 tool elencati, il ponte funziona.
A questo punto registri il tool server in Open WebUI: Settings → Tools → Manage Tool Servers → Add Connection (per uso personale) oppure da Admin Settings per renderlo globale. Inserisci l'endpoint OpenAPI e l'API key che hai impostato. Da quel momento il modello vede i tool e può chiamarli.
Via B — MCP nativo per l'agente AI di scraping locale (Streamable HTTP)
Dalla v0.6.31 Open WebUI consuma MCP nativamente, ma con un vincolo netto: solo Streamable HTTP. Niente stdio, niente SSE — perché Open WebUI è un ambiente web multi-tenant, non un processo desktop locale. Significa che lanci lo Scrapling MCP server in modalità HTTP e lo colleghi direttamente, senza mcpo in mezzo.
bash
# Scrapling in Streamable HTTP, vincolato a localhost
scrapling mcp --http --host '127.0.0.1' --port 8000
Poi in Open WebUI: Admin Settings → External Tools → + (Add Server) → Type: MCP (Streamable HTTP). Un layer in meno da mantenere. Ma attenzione: secondo la documentazione ufficiale di Open WebUI, "for most deployments, OpenAPI remains the preferred integration path" — per maturità (SSO, gateway, audit), resilienza (verbi HTTP, idempotenza, caching) e osservabilità.
CriterioDisponibilità
Via A — mcpo / OpenAPISempre
Via B — MCP nativoSolo Open WebUI v0.6.31+
CriterioTransport
Via A — mcpo / OpenAPIOpenAPI REST
Via B — MCP nativoSolo Streamable HTTP
CriterioComponenti da gestire
Via A — mcpo / OpenAPIOpen WebUI + mcpo + Scrapling
Via B — MCP nativoOpen WebUI + Scrapling
CriterioPosizione doc ufficiale
Via A — mcpo / OpenAPIVia preferita per la maggior parte dei deploy
Via B — MCP nativoSupportata, meno matura
CriterioQuando sceglierla
Via A — mcpo / OpenAPISetup stabile, audit/caching, default sicuro
Via B — MCP nativoVuoi meno layer e sei aggiornato
Criterio
Via A — mcpo / OpenAPI
Via B — MCP nativo
Disponibilità
Sempre
Solo Open WebUI v0.6.31+
Transport
OpenAPI REST
Solo Streamable HTTP
Componenti da gestire
Open WebUI + mcpo + Scrapling
Open WebUI + Scrapling
Posizione doc ufficiale
Via preferita per la maggior parte dei deploy
Supportata, meno matura
Quando sceglierla
Setup stabile, audit/caching, default sicuro
Vuoi meno layer e sei aggiornato
In pratica: se parti oggi e vuoi qualcosa di stabile, vai di mcpo. Se ti dà fastidio avere un proxy in più e sei già sulla v0.6.31, la via nativa funziona — sapendo che è la strada meno collaudata delle due.
Verifica che l'agente legga davvero il web
L'unica prova che conta è far chiamare il tool al modello da una chat. Apri una conversazione in Open WebUI, assicurati di aver selezionato un modello con il tool calling attivo, e chiedi qualcosa che richieda per forza il web in tempo reale — non una nozione che il modello potrebbe sapere a memoria. Per esempio: chiedigli di leggere una pagina specifica e riassumerne il contenuto.
Il modello deve mostrare la chiamata al tool (fetch o stealthy_fetch) prima di rispondere — in Open WebUI vedi l'indicazione dell'uso del tool
La risposta deve contenere informazioni che il modello non poteva sapere dal training: una data recente, un numero appena pubblicato, testo letterale della pagina
Se vuoi testare l'anti-bot, punta stealthy_fetch su un sito protetto da Cloudflare e verifica che torni il contenuto invece di una pagina di challenge
Se invece vuoi capire fin dove si spinge il function calling locale prima di costruirci sopra, abbiamo mostrato un setup di tool calling self-hosted da cinque minuti che chiarisce bene la dinamica modello → tool_calls → risposta.
Perché questo conta, in un homelab
Il risultato finale è l'agente AI di scraping locale che volevamo: un assistente che cerca e legge il web reale restando al 100% in casa tua, con accesso a internet senza che una sola richiesta esca dalla rete. Tutta la catena è self-hosted: Scrapling MCP server, mcpo (se scegli la via A), Open WebUI, Ollama. Nessuna chiamata a OpenAI, ScraperAPI o ScrapingBee. I prompt che scrivi e le pagine che l'agente legge non lasciano la tua rete.
È esattamente il tipo di confine che separa un'AI "privata" da una che lo è solo a metà — un tema che avevamo aperto parlando di cosa espone davvero un LLM locale. Aggiungere lo scraping via cloud avrebbe vanificato metà del lavoro fatto per tenere tutto in casa. Scrapling chiude il cerchio: capacità anti-bot di livello commerciale, sanitizzazione anti-prompt-injection inclusa, zero API esterne.
Un cervello senza occhi, dicevamo all'inizio. Adesso gli occhi ce li ha — e guardano solo dove glielo dici tu, da dentro casa. Un agente AI di scraping locale, finalmente completo.
