Dacă ați rulat recent un audit Lighthouse sau ați testat pagina în PageSpeed Insights și ați dat peste un avertisment despre WebMCP form coverage, probabil vă întrebați dacă ați stricat ceva. Nu ați stricat nimic. Este o verificare nouă, din categoria WebMCP, care semnalează formularele fără adnotări declarative și vă sugerează cum să le faceți mai ușor de folosit de către agenții AI. În acest articol explicăm exact ce verifică Lighthouse, ce atribute există cu adevărat în specificație și cum rezolvați problema fără să introduceți alte riscuri.
Ce este verificarea WebMCP form coverage din Lighthouse
WebMCP form coverage este un audit din categoria WebMCP a Lighthouse, gândit să identifice formularele HTML dintr-o pagină care nu au adnotări declarative pentru agenți AI. Mesajul complet care apare în raport este: „Consider adding WebMCP annotations to the forms listed below. This helps AI agents identify and interact with these forms more reliably.”
Practic, Lighthouse parcurge toate elementele <form> din pagină și verifică dacă acestea au fost descrise în mod explicit, prin atribute dedicate, astfel încât un agent automat să înțeleagă rapid rolul formularului, fără să încerce să deducă din etichete, placeholdere sau context vizual ce anume face acel formular.
Unde apare exact acest avertisment
Verificarea apare atât în Lighthouse rulat direct din DevTools, în tab-ul Lighthouse, cât și în rapoartele generate de PageSpeed Insights, sub secțiunea dedicată WebMCP. Nu este ascunsă undeva la subcategorii obscure, apare vizibil, cu formularele listate individual, fiecare cu un link către elementul din DOM.
Este important de reținut că această categorie WebMCP este relativ nouă în ecosistemul Lighthouse și continuă să se extindă. Pe măsură ce specificația WebMCP se stabilizează, este posibil să vedeți verificări suplimentare adăugate în aceeași categorie, dar principiul de bază rămâne același: identificarea elementelor interactive care nu sunt descrise pentru agenți.
Ce înseamnă eticheta Unscored
Lângă titlul verificării veți vedea eticheta „Unscored”. Aceasta înseamnă că verificarea este una de diagnostic, nu una scorată. Nu influențează scorul general de performanță, accesibilitate sau SEO al paginii. Este pur și simplu o recomandare, similar cu alte audituri de diagnostic din Lighthouse care nu afectează cifra finală, dar oferă informație utilă.
Dacă ați văzut acest avertisment și v-ați speriat că scorul dumneavoastră a scăzut brusc, puteți fi liniștit: nu are legătură. Formularele care apar în listă nu sunt „greșite” din punct de vedere tehnic, ele funcționează perfect pentru utilizatorii umani. Verificarea semnalează doar o oportunitate de îmbunătățire pentru interacțiunea cu agenții AI, nu o eroare care trebuie corectată de urgență.
Ce verifică de fapt Lighthouse
Concret, auditul caută în fiecare formular din pagină prezența atributelor declarative WebMCP. Dacă un formular nu are niciunul dintre aceste atribute, este listat ca fiind fără acoperire. Nu se verifică validitatea semantică a formularului, nu se verifică accesibilitatea și nu se verifică dacă formularul trimite date corect, ci strict prezența adnotărilor pentru agenți.
Formularele mici, cu un singur câmp, sunt la fel de vizate ca formularele complexe, cu multe câmpuri și logică de validare. Un formular de căutare simplu, un formular de abonare la newsletter sau un formular de contact complet, toate apar în listă dacă nu au fost adnotate.
Atributele reale din specificația Chrome
Aici este partea unde apar cele mai multe confuzii, pentru că pe internet circulă articole care menționează atribute inexistente. Conform specificației actuale WebMCP din Chrome, atributele declarative reale sunt următoarele:
toolname, aplicat pe elementul<form>, care dă un nume scurt și clar tool-ului expus de formular.tooldescription, tot pe formular, care explică în limbaj natural ce face formularul respectiv.toolparamdescription, aplicat pe fiecare câmp din formular, care descrie ce reprezintă acel câmp și ce fel de valoare se așteaptă.toolautosubmit, opțional, care indică faptul că formularul poate fi trimis automat de agent, fără o acțiune suplimentară de confirmare.
Acestea sunt singurele atribute prevăzute în specificație pentru adnotarea declarativă. Nu există toolaction și nu există data-toolname, deși ambele apar, din păcate, în unele articole și chiar în unele verificatoare improvizate. Dacă folosiți aceste atribute inventate, ele vor fi pur și simplu ignorate de Lighthouse și de browserele care implementează WebMCP, pentru că nu fac parte din specificație.
Confuzia cu toolaction și data-toolname
Această confuzie apare de obicei din două surse. Prima este obiceiul, moștenit din alte tehnologii web, de a prefixa atributele personalizate cu data-. Acest tipar este corect pentru atribute custom generice din HTML, dar WebMCP nu urmează această convenție, atributele sale sunt nume simple, fără prefix.
A doua sursă este confuzia cu terminologia „acțiune”, care sună firesc lângă un formular, dar în specificația WebMCP nu există un atribut numit toolaction. Dacă vedeți acest atribut menționat undeva, tratați informația cu precauție și verificați direct în documentația oficială Chrome pentru WebMCP înainte de a-l implementa, pentru că timpul investit în el nu va produce niciun efect.
Adnotări declarative versus tool-uri imperative
Pe lângă atributele declarative de mai sus, specificația WebMCP permite și o abordare imperativă, prin care tool-urile sunt înregistrate direct din JavaScript, folosind registerTool prin obiectul modelContext. Este important să înțelegeți diferența dintre cele două abordări, pentru că au cerințe și limitări diferite.
Adnotările declarative sunt simple atribute HTML. Ele sunt prezente în marcaj chiar dacă JavaScript nu se execută deloc, ceea ce le face vizibile inclusiv unor agenți care doar parsează HTML-ul static al paginii, fără să ruleze un motor de randare complet. Tool-urile imperative, în schimb, au nevoie ca API-ul WebMCP să fie disponibil în browserul care rulează pagina și, în perioada actuală, de un token de origin trial valid, activat pentru domeniul dumneavoastră.
Recomandarea noastră, confirmată de proiectele pe care le-am implementat, este să aveți ambele abordări acolo unde este posibil: adnotările declarative acoperă cazul de bază, robust și simplu, iar tool-urile imperative permit logică suplimentară, cum ar fi validare dinamică sau completare condiționată a câmpurilor. Dacă doriți o evaluare a situației actuale, un audit de pregătire pentru agenți AI vă poate arăta exact unde se află paginile dumneavoastră față de ambele niveluri.
Cum se rezolvă: exemplu de formular adnotat
Rezolvarea practică pentru avertismentul WebMCP form coverage este simplă: adăugați atributele declarative direct pe formular și pe câmpurile sale. Mai jos aveți un exemplu concret, pentru un formular de căutare produse:
<form toolname="cautare-produse" tooldescription="Permite căutarea produselor din catalog după nume sau cod">
<label for="query">Termen de căutare</label>
<input type="text" name="query" toolparamdescription="Cuvântul cheie sau codul produsului căutat">
<label for="categorie">Categorie</label>
<select name="categorie" toolparamdescription="Categoria de produse în care se face căutarea">
<option value="">Toate categoriile</option>
<option value="electrocasnice">Electrocasnice</option>
</select>
<button type="submit">Caută</button>
</form>Observați că toolname și tooldescription se aplică o singură dată, pe elementul <form>, în timp ce toolparamdescription se repetă pentru fiecare câmp relevant. Nu este necesar să adnotați butonul de submit, agentul înțelege din context că acel buton declanșează trimiterea formularului descris deja.
De ce nu puneți toolautosubmit din reflex
Atributul toolautosubmit este tentant, pentru că promite o experiență mai fluidă pentru agent, care poate completa și trimite formularul într-un singur pas, fără intervenția utilizatorului. Totuși, acest atribut înseamnă exact ce spune: agentul poate trimite formularul fără confirmare din partea persoanei care a inițiat conversația.
Din acest motiv, nu recomandăm folosirea lui pe formulare care implică:
- plăți, comenzi sau orice acțiune care costă bani utilizatorului;
- consumul unor limite sau cote, cum ar fi solicitări către un API limitat sau rezervări cu disponibilitate redusă;
- trimiterea de mesaje către un operator uman, unde o eroare de interpretare poate produce un tichet greșit sau o cerere trimisă din greșeală.
Pentru un formular simplu de căutare, ca cel din exemplul de mai sus, riscul este minim, iar toolautosubmit poate avea sens. Pentru formulare de checkout, de contact sau de rezervare, tratați acest atribut cu precauție și lăsați confirmarea finală în mâna utilizatorului uman.
O capcană importantă: honeypot-ul anti-spam
Din experiența noastră cu implementări reale, aici apare o problemă subtilă, dar frecventă. Multe formulare de contact folosesc un câmp-capcană de tip honeypot, ascuns vizual prin CSS, menit să prindă boții de spam care completează automat toate câmpurile dintr-un formular. Un utilizator uman nu vede acest câmp și, evident, nu îl completează.
Problema apare când un agent AI, instruit să completeze conștiincios toate câmpurile pe care le găsește într-un formular, completează și câmpul honeypot, exact ca un bot de spam. Rezultatul este că serverul aruncă cererea în tăcere, considerând-o spam, iar utilizatorul care a folosit agentul rămâne fără niciun răspuns, fără să înțeleagă de ce.
Soluția este simplă și nu compromite protecția anti-spam: dați câmpului honeypot o descriere clară prin toolparamdescription, care spune explicit agentului să lase acel câmp gol. Un exemplu concret arată astfel:
<input type="text" name="website" toolparamdescription="Lăsați acest câmp complet gol, este un câmp de control tehnic, nu introduceți nicio valoare">Protecția rămâne funcțională pentru că boții de spam obișnuiți nu citesc atributul toolparamdescription, ei completează câmpurile pe baza numelui și a tipului de input, ignorând orice text descriptiv adăugat pentru agenți. Astfel, capcana continuă să prindă spam automatizat, în timp ce agenții AI legitimi, care respectă instrucțiunile din adnotări, lasă câmpul gol și cererea utilizatorului ajunge corect la destinație.
Cum verificați că ați rezolvat problema
După ce adăugați atributele declarative pe formularele relevante, cel mai simplu mod de a confirma rezolvarea este să reluați auditul Lighthouse, fie din DevTools, fie prin PageSpeed Insights. Verificarea WebMCP form coverage ar trebui să nu mai listeze formularele adnotate, sau să le listeze doar pe cele rămase fără atribute.
O alternativă mai rapidă, mai ales dacă testați des mai multe pagini, este să folosiți un validator care execută pagina într-un browser real, nu doar un simplu analizor de cod sursă static. Validatorul gratuit disponibil pe pagina principală a site-ului nostru face exact acest lucru, randează pagina, identifică formularele și verifică prezența și corectitudinea atributelor declarative, oferind un raport clar despre ce mai trebuie ajustat.
Dacă lucrați pe un site mai mare, cu zeci de formulare distribuite pe categorii diferite de pagini, merită să consultați și metodologia noastră de implementare WebMCP, care descrie ordinea recomandată de prioritizare, de la formularele critice pentru conversie până la cele secundare.
Concluzie
Verificarea WebMCP form coverage din Lighthouse nu este un motiv de îngrijorare, ci o recomandare de diagnostic, ușor de rezolvat prin adăugarea atributelor declarative reale: toolname, tooldescription, toolparamdescription și, cu prudență, toolautosubmit. Evitați atributele inventate precum toolaction sau data-toolname, aveți grijă la formularele care ating bani sau oameni și nu uitați de capcana honeypot-ului. Dacă doriți o implementare completă și verificată, echipa noastră vă poate ajuta prin serviciul de implementare WebMCP.
