Playwright MCP: guida pratica ai test nel browser

Il server Playwright MCP di Microsoft collega agenti come Claude Code, Codex, Cursor e l'agente Copilot di VS Code a Playwright, il framework per l'automazione del browser. Il mio consiglio è usarlo per le verifiche esplorative e per indagare sui malfunzionamenti, trasformando poi le scoperte importanti in test ripetibili e sottoposti a revisione.

Che cosa fa davvero Playwright MCP?

L'agente riceve i comandi per controllare il browser e una descrizione strutturata della pagina. MCP, acronimo di Model Context Protocol, è il collegamento che gli consente di richiamare questi strumenti. Il server esegue le azioni nel browser; l'agente decide quale richiedere di volta in volta.

Pensa a uno snapshot di accessibilità come alla segnaletica di un edificio: identifica stanze e porte in base al nome e alla funzione. Allo stesso modo, lo snapshot di una pagina descrive pulsanti, link, campi di testo e i relativi nomi accessibili. L'agente può individuare l'elemento su cui agire in questa struttura, senza dover dedurre da un'immagine dove fare clic. Il flusso predefinito non richiede un modello con capacità visive. Panoramica di Microsoft

Prima dell'installazione c'è una scelta da fare. Microsoft propone ora agli utenti degli agenti di programmazione anche Playwright CLI con le skill, indicando MCP come soluzione utile quando servono uno stato del browser persistente e ispezioni ripetute della struttura della pagina. Scegli MCP se questa interazione continuativa è adatta al tuo modo di lavorare; valuta anche la CLI se il tuo agente opera già agevolmente tramite comandi di shell. Nessuna delle due scelte dimostra, da sola, che un percorso cliente abbia superato la verifica. Confronto di Microsoft tra MCP e CLI

Per una panoramica degli altri strumenti, leggi la nostra selezione dei migliori server MCP per il 2026.

Come configurarlo in Claude Code, Codex, Cursor o VS Code

Servono Node.js 18 o successivo e un client che supporti MCP. I comandi e le configurazioni riportati qui riproducono gli esempi del README di Microsoft. Segui le istruzioni del tuo client: sono modalità di installazione alternative, non una sequenza da eseguire in tutti gli editor. Requisiti e configurazione

Claude Code

Esegui esattamente questo comando:

claude mcp add playwright npx @playwright/mcp@latest

Codex

Esegui esattamente questo comando:

codex mcp add playwright npx "@playwright/mcp@latest"

In alternativa, aggiungi questa configurazione a ~/.codex/config.toml:

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

Cursor

Segui la procedura manuale del README: Cursor Settings -> MCP -> Add new MCP Server. Scegli un nome, seleziona il tipo command e inserisci:

npx @playwright/mcp@latest

Usa Edit per controllare la configurazione o aggiungere argomenti. Il README offre anche un pulsante per l'installazione in Cursor.

VS Code

Esegui il comando della CLI di VS Code esattamente come riportato:

code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'

Il server diventa disponibile per l'agente GitHub Copilot in VS Code. Il README di Microsoft contiene anche i link ai pulsanti di installazione e alla guida di configurazione di MCP per VS Code.

La configurazione JSON comune ai client

Per i client che usano la configurazione JSON standard del README, l'esempio esatto è questo:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

Per sapere dove inserirla, segui le istruzioni del client indicate sopra. La configurazione alternativa di Codex usa TOML, non questo JSON. Per scegliere l'agente da affiancare al browser, consulta la guida agli agenti AI per la programmazione con test nel browser.

Scegliere il browser e il modo in cui l'agente lo interpreta

Per iniziare, usa un browser con finestra visibile, un profilo isolato e gli snapshot. Aggiungi le opzioni all'elenco degli argomenti del server dopo @playwright/mcp@latest. Quelle riportate qui provengono dalla documentazione di configurazione di Microsoft.

La scelta tra snapshot e visione riguarda il metodo di interazione. Nel flusso predefinito, usa browser_snapshot per individuare gli elementi su cui agire. browser_take_screenshot acquisisce una prova visiva, ma scattare uno screenshot non abilita di per sé i clic tramite coordinate. Con --caps=vision, il README elenca browser_mouse_click_xy, browser_mouse_down, browser_mouse_drag_xy, browser_mouse_move_xy, browser_mouse_up e browser_mouse_wheel. Per ragionare sul contenuto visivo, il client e il modello devono saper utilizzare le immagini restituite. Documentazione degli strumenti

Per moduli comuni e navigazione, io parto dagli snapshot. Ricorro all'ispezione visiva quando conta l'aspetto della pagina o quando la sua struttura non descrive adeguatamente il controllo. Uno snapshot di accessibilità fornisce informazioni utili sulla struttura; non può stabilire se la pagina si presenta correttamente.

Gli strumenti utili durante una verifica nel browser

Gli strumenti di base coprono navigazione, interazione e raccolta delle prove. La tabella raggruppa gli strumenti principali di automazione e gestione delle schede del README in base al compito affidato all'agente. Elenco degli strumenti di Microsoft

Le azioni basate sugli snapshot usano il riferimento a un elemento ricavato dallo snapshot della pagina oppure un selettore univoco. Un selettore serve a identificare un elemento della pagina. Dopo una modifica significativa della pagina, aggiorna lo snapshot: non dare per scontato che un riferimento precedente sia ancora valido.

Le funzionalità aggiuntive vanno abilitate esplicitamente. La tabella delle opzioni elenca vision, pdf e devtools; le sezioni dedicate agli strumenti documentano inoltre in modo esplicito config, network, storage e testing:

• PDF: --caps=pdf aggiunge browser_pdf_save.
• Prove per il debugging: --caps=devtools comprende tracciamento, video, registrazione delle azioni, annotazioni, evidenziazione e ripresa dell'esecuzione in pausa. Per esempio, browser_start_tracing e browser_stop_tracing delimitano una traccia.
• Asserzioni: --caps=testing aggiunge browser_generate_locator, browser_verify_element_visible, browser_verify_list_visible, browser_verify_text_visible e browser_verify_value. Un'asserzione esprime una condizione che deve risultare vera.
• Simulazione della rete: --caps=network aggiunge browser_network_state_set, browser_route, browser_route_list e browser_unroute per simulare il funzionamento offline e le richieste di rete.
• Archiviazione nel browser: --caps=storage permette di ispezionare e modificare cookie, local storage e session storage, e aggiunge browser_storage_state e browser_set_storage_state.
• Impostazioni effettive: --caps=config aggiunge browser_get_config.

Questi sono i gruppi documentati nel README; non significa che ogni client renda immediatamente disponibile ogni strumento. Se ne manca uno, confronta l'elenco degli strumenti del pacchetto installato e le funzionalità abilitate con il README. Descrizione completa degli strumenti

Tre attività concrete da affidargli in azienda

Dai la precedenza ai percorsi in cui un errore impedisce una vendita o ostacola il contatto con un cliente. Quelli che seguono sono flussi di lavoro proposti, non promesse di risparmi misurati.

Verificare il percorso fino al checkout

Chi sviluppa un negozio online potrebbe chiedere all'agente di seguire il checkout come ospite in staging, verificare che l'articolo scelto rimanga nel carrello, compilare i dati di spedizione con informazioni fittizie e fermarsi prima di qualsiasi pagamento reale. Il vantaggio è individuare un errore che impedisce l'acquisto prima che lo incontri un cliente.

Un'altra attività utile per lo stesso team è una verifica del recupero dagli errori: inviare dati di spedizione incompleti, controllare che il messaggio di errore sia comprensibile, correggere i dati e verificare che il cliente possa proseguire. Provare soltanto il percorso senza intoppi non copre il caso di chi sbaglia a compilare un campo.

Controllare il sito dopo un deploy

Chi pubblica una modifica alla landing page della propria attività potrebbe far aprire all'agente la versione appena distribuita, fargli seguire la call to action principale e verificare che porti alla pagina di registrazione o di contatto prevista. Chiedi prove tratte dalla pagina e gli eventuali messaggi pertinenti della console o delle richieste non riuscite.

Uno sviluppatore di un'agenzia potrebbe poi provare un viewport più stretto e ripetere la navigazione. Potrebbero così emergere un menu nascosto o un pulsante irraggiungibile. Lo screenshot va esaminato: non certifica automaticamente la qualità visiva della pagina.

Mettere alla prova i moduli con dati di test

Chi sviluppa un SaaS potrebbe verificare i campi obbligatori, i messaggi di validazione e la possibilità di correggere gli errori in un modulo di registrazione accessibile senza autenticazione, in locale o in staging. Occorre fermarsi prima di creare un account reale, oppure usare una destinazione predisposta esclusivamente per gli invii di prova.

Chi sviluppa strumenti per le attività operative potrebbe compilare un lungo modulo di staging con dati sintetici, controllando menu a tendina, campi condizionali e il caricamento di un file di prova prima dell'invio a un endpoint simulato. Questo aiuta a individuare gli errori di mappatura dei campi senza inviare dati dei clienti né avviare un flusso di lavoro reale.

Un test end to end d'esempio: il checkout ospite si blocca prima del pagamento

Assegna all'agente un compito con confini precisi e chiedi che ogni conclusione sia sostenuta da prove. Quello che segue è un esempio illustrativo di test end to end, costruito attorno a un difetto ipotizzato appositamente. Non è il resoconto di un test su un negozio reale.

L'applicazione dell'esempio comprende un carrello per gli ospiti, un modulo di spedizione e una pagina di pagamento. Per errore, il modulo di spedizione invia il campo del codice postale come postal, mentre il backend si aspetta postalCode. Usa un ambiente di prova locale o di staging accessibile senza autenticazione, con dati fittizi e senza collegamenti a sistemi di pagamento reali.

Assegna all'agente queste istruzioni, sostituendo l'URL tra parentesi quadre con quello del tuo ambiente di prova:

L'isolamento va impostato nella configurazione del server con --isolated; chiederlo soltanto nel prompt non configura il server.

In questo esempio, il corpo della richiesta contiene postal e la risposta segnala l'assenza di postalCode. Questi elementi sostengono l'ipotesi di un errore di mappatura. Prima di dichiarare risolta la causa del problema, lo sviluppatore deve comunque controllare la serializzazione del modulo e il contratto del backend.

Esempio di rapporto dell'agente:

Il passo successivo è correggere la mappatura e ripetere sia il percorso con dati non validi sia quello con dati validi. Una volta confermato il comportamento, fai preparare all'agente una bozza di test di regressione Playwright, controllane le asserzioni e aggiungilo al test runner già in uso. Quest'ultimo passaggio appartiene al tuo processo di sviluppo: la sola conversazione MCP non costituisce una suite di regressione.

Dove incontra i suoi limiti e a cosa può accedere l'agente

Le verifiche meno affidabili sono quelle con obiettivi vaghi o svolte in un ambiente non sicuro. «Controlla il checkout» lascia all'agente il compito di inventare i criteri di successo. «Verifica che i dati di spedizione validi permettano di raggiungere la pagina di pagamento, senza inviare il pagamento» definisce invece un risultato valutabile.

Questi sono i limiti pratici da aspettarsi:

• Struttura della pagina ambigua: Controlli senza nome e interfacce che fanno largo uso di canvas rendono meno utile la descrizione strutturale. Consiglio di correggere le etichette accessibili nelle applicazioni su cui hai controllo e di ricorrere alle prove visive dove la struttura non basta.
• Stato che cambia: Un nuovo rendering, un popup o una transizione ritardata possono rendere infondata l'ipotesi su cui si basa l'azione successiva dell'agente. Esamina lo stato risultante e attendi il testo o la transizione previsti prima di continuare.
• Conflitti tra profili: Un profilo persistente può essere usato da una sola istanza del browser alla volta. Microsoft consiglia sessioni isolate o valori distinti di --user-data-dir per i client che operano contemporaneamente nello stesso spazio di lavoro.
• Differenze tra ambienti: L'implementazione Docker descritta nel README supporta soltanto Chromium in modalità headless. Non dare per scontato che nel container funzionino tutti i browser elencati nella tabella generale della CLI.
• Copertura incompleta: Raggiungere una pagina non dimostra che funzionino tutte le validazioni, tutti i browser e i dispositivi o tutti i possibili esiti del backend. Uno screenshot, inoltre, non può provare che un ordine sia stato salvato correttamente. Sono limiti del metodo di verifica proposto.

Le restrizioni sui profili e su Docker sono documentate nel README di Microsoft.

Considera l'accesso al browser un accesso reale. Microsoft dichiara esplicitamente che Playwright MCP non costituisce una barriera di sicurezza. Il profilo predefinito conserva lo stato del browser; l'estensione facoltativa per Chrome/Edge può collegarsi alle schede esistenti e alle sessioni autenticate. Per le attività descritte qui, usa una sessione isolata, senza importare cookie né collegarti al browser che usi abitualmente. Comportamento dei profili e dell'estensione

L'agente può richiedere pagine raggiungibili dall'ambiente del browser. A seconda della rete, queste possono includere server di sviluppo o servizi interni oltre ai siti pubblici. Le regole sulle origini non sostituiscono l'isolamento della rete: --allowed-origins e --blocked-origins non limitano i reindirizzamenti e, per esplicita indicazione, non costituiscono una barriera di sicurezza. --allowed-hosts riguarda i controlli sugli host delle richieste in ingresso al server MCP, non un elenco di siti che il browser può visitare. Configurazione e sicurezza

L'accesso ai file richiede la stessa attenzione. Il comportamento predefinito documentato limita i file alle cartelle radice dello spazio di lavoro e blocca la navigazione file://, mentre --allow-unrestricted-file-access allenta queste regole. Microsoft descrive i controlli sui file come misure di protezione, non come un isolamento sicuro. Ancora più delicato è browser_run_code_unsafe, che esegue JavaScript nel processo del server, con le possibilità di accesso di quel processo. Controlla l'uso dello strumento tramite le autorizzazioni del client e limita l'ambiente in cui gira il server. Schema di configurazione e strumenti

Screenshot, testo delle pagine, output della console e corpi delle richieste possono esporre dati all'agente. Usa dati fittizi ed endpoint riservati ai test. Fermati prima di un addebito reale, dell'invio di un messaggio, della creazione di un account o di qualsiasi altro invio con effetti concreti, a meno che quella specifica azione non sia stata autorizzata espressamente.

Meglio Playwright MCP, Chrome DevTools MCP o Browserbase?

La scelta dipende dal compito da svolgere e da dove deve girare il browser. Le funzioni di questi prodotti si sovrappongono in parte, ma i ruoli che svolgono non sono intercambiabili.

Microsoft mette a disposizione anche --cdp-endpoint per collegarsi a un endpoint del browser. Per questo l'interfaccia usata dall'agente e il luogo in cui gira il browser sono due decisioni distinte. Browserbase non è un altro nome per il server di Microsoft. La nostra guida ai migliori browser per agenti AI approfondisce questa scelta più ampia.

Quanto costa e due servizi che vale la pena sviluppare

Il confronto economico utile è tra il processo di verifica attuale e l'intero flusso automatizzato. Il repository di Playwright MCP è distribuito con licenza Apache; installarlo non fornisce il modello dell'agente, le risorse di calcolo, gli ambienti e i dati di prova o la revisione umana.

Fai i conti con i tuoi dati:

• Prima: ore di verifica manuale × costo orario complessivo, più eventuali abbonamenti a strumenti di test già in uso.
• Dopo: utilizzo dell'agente + infrastruttura del browser + revisione umana + manutenzione degli ambienti di prova e dei test.

Per un riferimento concreto sui costi di hosting, Browserbase indica per il piano Developer $20/mese con 100 ore di browser, poi $0.12 per ora di browser. Sono costi dell'infrastruttura del browser, non il prezzo completo di un test del checkout svolto da un agente. Prezzi di Browserbase

L'opportunità più solida: un servizio di collaudo dei rilasci

Una piccola agenzia potrebbe offrire la verifica di percorsi cliente concordati dopo ogni deploy. La versione minima utile riceve un URL di staging e una checklist di accettazione, esegue i percorsi senza autenticazione autorizzati e produce un rapporto sottoposto a revisione, con prove e lacune di copertura esplicite. Il cliente paga perché qualcuno si assuma la responsabilità del controllo del rilascio.

Il segnale di domanda è modesto: le stime delle parole chiave in inglese per gli Stati Uniti fornite da DataForSEO, recuperate a ottobre 2026, indicano 110 ricerche mensili per “automated browser testing” e 10 per “checkout testing”. Misurano ricerche, non acquirenti. Suggeriscono di sperimentare un servizio mirato con i clienti esistenti prima di investire in un prodotto software di portata più ampia.

La difficoltà è la manutenzione: percorsi che cambiano, asserzioni ambigue e falsi allarmi possono assorbire il lavoro che si sperava di risparmiare. Il valore difendibile sta in una checklist di accettazione utile e in una valutazione affidabile dei problemi, non nell'installazione dello stesso server MCP pubblico che chiunque può installare.

La seconda opportunità: uno strumento per verificare i moduli in staging

Un'agenzia web potrebbe sviluppare uno strumento che compila i moduli con valori sintetici, provoca gli errori dei campi obbligatori e verifica che un invio corretto raggiunga una destinazione simulata. Il punto di partenza sono i moduli dei siti che l'agenzia già gestisce e un rapporto che permetta a uno sviluppatore di riprodurre la verifica.

Lo stesso insieme di dati DataForSEO per le ricerche in inglese negli Stati Uniti stima 10 ricerche mensili per “website form testing”. È un segnale debole per acquisire clienti con un'offerta autonoma. Il mio consiglio è vendere questa funzione come integrazione della manutenzione del sito, verificando poi che esista una domanda ricorrente prima di costruire un prodotto a sé.

La difficoltà sta nel sistema destinatario. Una pagina che sembra confermare l'esito positivo non dimostra che il contatto sia arrivato a destinazione. Oltre alle prove raccolte nel browser, l'MVP richiede un endpoint di test o un altro metodo autorizzato per verificare la ricezione.

Le domande più comuni durante la configurazione

Da fare lunedì: scegli il percorso ospite più vicino a una vendita, scrivi il risultato atteso e il punto in cui fermarsi, poi chiedi all'agente di programmazione che usi già di verificarlo in staging. Prima di ampliare l'ambito della verifica, esamina le prove con lo sviluppatore responsabile di quel percorso.

Se cerchi un flusso di verifica nel browser costruito attorno al tuo processo di rilascio, sviluppiamo agenti AI per i processi aziendali.