webmcp: das ende des oberflaechlichen internets

tl;drWebMCP ist eine neue browser-api (chrome 146), mit der websites strukturierte tools fuer ai-agents bereitstellen koennen. statt screen-scraping rufen agents funktionen direkt auf. das verschiebt die interaktion von oberflaechen zu schnittstellen, und ist der beginn eines fundamentalen wandels: die ai wird zum browser, die website wird zur funktion.

in chrome 146 schlummert eine api, die kaum jemand bemerkt hat. sie ist der beginn eines fundamentalen wandels des internets.

»zeig mir meine teuersten abos.«

kein bildschirm, kein browser, kein scrollen durch eine liste. dein ai-agent oeffnet snout.pink, ruft list_subscriptions auf, bekommt strukturiertes json zurueck und sagt: »deine berufsunfaehigkeitsversicherung kostet 145 euro im monat. willst du kuendigen oder vergleichen?«

das ist keine vision fuer 2030. das funktioniert heute, in chrome 146 canary, hinter einem feature flag. ich habe es gebaut und getestet.

die technologie heisst WebMCP, und sie ist der anfang vom ende des internets wie wir es kennen.

was webmcp ist: websites lernen sprechen

heute interagieren ai-agents mit websites wie ein mensch: sie machen screenshots, parsen den dom, suchen buttons und klicken sich durch formulare. das ist ungefaehr so effizient, wie wenn du ein restaurant nur bedienen koenntest, indem du die speisekarte fotografierst und die buchstaben einzeln entzifferst.

WebMCP dreht das um. eine website kann dem browser jetzt sagen, was sie kann: nicht als freitext, sondern als strukturierte tool-deklaration mit namen, beschreibung und parameter-schema.

technisch ist das eine einziger funktionsaufruf:

navigator.modelContext.registerTool({
name: 'search_hotels',
description: 'suche verfuegbare hotels fuer einen zeitraum',
inputSchema: {
type: 'object',
properties: {
city: { type: 'string' },
checkin: { type: 'string', format: 'date' },
checkout: { type: 'string', format: 'date' },
guests: { type: 'number' }
},
required: ['city', 'checkin', 'checkout']
},
execute: async (input) => {
const results = await searchHotels(input);
return { content: [{ type: 'text', text: JSON.stringify(results) }] };
}
});

die website registriert eine funktion, der agent ruft sie auf. ein sauberer funktionsaufruf mit typisiertem input und strukturiertem output, statt fragiles screen-scraping und pixel-raten.

der W3C draft [1] wurde am 10. februar 2026 veroeffentlicht, gemeinsam entwickelt von google und microsoft. chrome 146 canary hat die api seit februar hinter dem flag »WebMCP for testing«, die stable-version wird fuer maerz 2026 erwartet [2].

praxisbeispiel: ein nachmittagsprojekt

ich habe WebMCP in snout.pink eingebaut, meinen subscription-tracker [3]. sechs tools: abos auflisten, hinzufuegen, aendern, loeschen, eine ausgaben-zusammenfassung abrufen, daten exportieren. der gesamte service ist ein angular-injectable mit 456 zeilen, geschrieben an einem nachmittag.

der kern sieht so aus (quellcode):

@Injectable({ providedIn: 'root' })
export class WebMcpService {
init(): void {
if (!navigator.modelContext) return;

navigator.modelContext.registerTool({
name: 'list_subscriptions',
description: 'alle abos mit preis und zyklus auflisten',
annotations: { readOnlyHint: true },
execute: async () => {
const subs = this.subscriptionService.subscriptions();
return { content: [{ type: 'text', text: this.format(subs) }] };
}
});

// + add, update, delete, summary, export
console.log('[WebMCP] 6 tools registered');
}
}

in chrome canary mit aktiviertem flag erscheint in der console: [WebMCP] 6 tools registered. die tools sind da. ein agent, der sich ueber das chrome devtools protocol [4] verbindet, kann sie sofort entdecken und aufrufen, ohne die UI jemals zu sehen.

dein morgen in zwei jahren

stell dir vor, dein ai-agent weckt dich nicht mit einem wecker, sondern mit einer zusammenfassung.

er hat ueber nacht deine nachrichtenquellen abgefragt, nicht indem er spiegel.de gescreent hat, sondern ueber strukturierte tool-calls. er weiss, dass dein lieblingskanal auf youtube eine neue folge veroeffentlicht hat, hat den inhalt zusammengefasst und auf deine liste fuer heute gesetzt. er sagt: »uebrigens, auf x hat dein kollege einen thread gepostet, der fuer dein projekt relevant ist. hier ist die kernaussage.«

dein hotelzimmer fuer naechste woche hat er gestern abend gebucht. nicht ueber eine website mit cookie-banner, »nur noch 2 zimmer!«-warnungen und sponsored listings, sondern ueber search_hotels → check_availability → book_room: drei funktionsaufrufe, strukturiert, vergleichbar, ohne dark patterns.

die pwa deines lieblings-nachrichtenportals stellt ihre artikel als WebMCP-tools bereit: get_latest_articles, search_by_topic, get_article_summary. dein agent ruft sie ab, filtert nach relevanz, fasst zusammen. du siehst nie eine startseite, nie eine werbeanzeige, nie einen clickbait-titel.

das klingt nach science fiction. technisch ist es ein W3C draft von vor drei wochen und ein feature flag in chrome.

WebMCP ist das neue seo

2005: wer nicht bei google auffindbar war, existierte nicht. unternehmen haben ganze abteilungen aufgebaut, um ihre websites fuer suchmaschinen zu optimieren. wer das ignoriert hat, verlor traffic, erst langsam, dann ploetzlich.

2028: wer keine WebMCP-tools anbietet, ist fuer ai-agents unsichtbar.

die parallele ist fast eins zu eins. seo optimierte websites fuer suchmaschinen-crawler, WebMCP optimiert websites fuer ai-agents. aber es geht weiter als seo, denn es geht nicht nur um auffindbarkeit, sondern um benutzbarkeit. eine website ohne WebMCP-tools ist fuer einen agent wie ein restaurant ohne speisekarte: man kann reingehen, sich umschauen, aber effizient bestellen kann man nicht.

denk das einen schritt weiter: du installierst eine pwa auf deinem phone. bisher war das eine app mit einer oberflaeche, die du bedienst. mit WebMCP ist es etwas fundamental anderes. dein agent erkennt automatisch die schnittstellen, die die app bereitstellt, und integriert sie in sein repertoire. du installierst keine app mehr, du gibst deiner ki eine neue faehigkeit.

dein podcast-player registriert get_new_episodes, dein task-manager registriert create_task, dein kalender registriert check_availability. die apps auf deinem geraet werden zu einem netzwerk aus funktionen, die dein agent orchestriert. die app-icons auf deinem homescreen sind dann das, was lesezeichen im browser heute schon sind: relikte einer aera, in der menschen die primaere schnittstelle waren.

genau wie bei seo werden verzeichnisse entstehen. ai-anbieter werden registries fuehren, die auflisten, welche domains welche tools anbieten. der naechste schritt sind .well-known/webmcp-manifests: maschinenlesbare deklarationen, abrufbar bevor die seite ueberhaupt geoeffnet wird. die infrastruktur fuer discovery wird kommen, weil die incentives stimmen, denn jeder ai-anbieter will seinem agent moeglichst viele tools zur verfuegung stellen.

die oberflaeche loest sich auf

was passiert, wenn die primaere interaktion nicht mehr ueber die website laeuft?

wenn dein agent dein hotelzimmer bucht, sieht niemand die sponsored listings auf booking.com. wenn er deine nachrichten zusammenstellt, sieht niemand banner-werbung. wenn er deine subscriptions verwaltet, braucht niemand die saas-UI mehr. das werbefinanzierte internet verliert nicht seine nutzer: es verliert seine oberflaeche. ohne oberflaeche gibt es nichts, worauf man werbung platzieren kann.

social media steckt schon in dieser krise. die feeds sind voll mit ai-generiertem inhalt, das sentiment ist negativ, und die ehrliche antwort auf »was hast du die letzten zwei stunden auf instagram gemacht?« ist meistens scham. wenn ein agent die relevanten inhalte kuratiert, gefiltert, ohne clickbait, ohne endlos-scroll, ohne algorithmus der deine aufmerksamkeit monetarisiert: warum wuerdest du noch einen feed oeffnen?

stattdessen: »dein freund hat etwas gepostet, das dich interessieren koennte. hier ist die zusammenfassung.« oder: »es gibt eine neue folge von hard fork, es geht um WebMCP und die zukunft von browser-agents. ich habe dir das auf deine liste fuer heute abend gesetzt.«

die interaktion wird persoenlich, kuratiert, intentional: das gegenteil eines feeds. die oberflaechen treten zurueck, und mit ihnen das oberflaechliche.

wer gewinnt: google, nicht das offene web

google ist mitautor der WebMCP-spec. das ist kein zufall und kein altruismus.

google hat gemini. wenn die ai zum neuen layer wird, durch den inhalte fliessen, hat google mehr kontrolle als je zuvor, nicht weniger. im browser konnten sie suchergebnisse sortieren. in der ai-schicht koennen sie inhalte filtern, zusammenfassen, gewichten, modifizieren, selektieren.

die ai ist der neue browser, nur dass man die inhalte nicht nur darstellen, sondern aktiv veraendern kann, bevor der nutzer sie sieht. das ist maechtiger als alles, was google je hatte.

werbung wird nicht verschwinden, sie wird die form wechseln. statt banner auf oberflaechen: gewichtete empfehlungen in agent-responses. statt sponsored listings in suchergebnissen: bevorzugte tool-aufrufe durch den agent. die mechanik aendert sich, das geschaeftsmodell bleibt, nur wird es unsichtbarer und damit wirksamer.

WebMCP ist ein offener W3C-entwurf, aber die infrastruktur, die ihn nutzt, die agents, die browser, die cloud, gehoert einer handvoll unternehmen. das web wird technisch offener und oekonomisch geschlossener, gleichzeitig.

fluessige software, teil zwei

in meinem letzten artikel [5] habe ich ueber die produktionsseite geschrieben: software wird fluessig, build schlaegt buy, die saas-gleichung kippt.

WebMCP ist die konsumseite derselben entwicklung. dort loest sich die starre schicht zwischen entwickler und software auf, hier loest sich die starre schicht zwischen nutzer und internet auf.

dort war es die saas-UI, die arbeitsprozesse diktiert hat. hier ist es die website-UI, die interaktionen diktiert hat. booking.com entscheidet, in welcher reihenfolge du hotels siehst. instagram entscheidet, welche posts du liest. google entscheidet, welche ergebnisse oben stehen.

in beiden faellen verschwindet die vermittlungsschicht und wird durch ai ersetzt.

das ist die gleiche grundbewegung: die starre schicht zwischen mensch und funktion wird fluessig. das saas-tool wird zum selbstgebauten internen tool, die website wird zum tool-call, die UI wird optional.

was jetzt zu tun ist

WebMCP-readiness ist das neue responsive design. wer 2015 keine mobile-optimierte seite hatte, verlor nutzer. wer 2027 keine WebMCP-tools hat, verliert agent-traffic, der schneller wachsen wird als mobile-traffic es je getan hat.

content-strategie muss maschinenlesbar werden. nicht keywords fuer google-crawler optimieren, sondern strukturierte tools fuer ai-agents bereitstellen. dein content existiert nicht fuer die ai, wenn er nicht als tool abrufbar ist.

das werbemodell muss sich aendern. werbung in tool-responses statt auf oberflaechen. google arbeitet daran. wer nicht google ist, hat ein problem und sollte jetzt anfangen, ueber alternativen nachzudenken.

unternehmen sollten jetzt experimentieren. ein WebMCP-service fuer die eigene website ist kein halbjahresprojekt, sondern ein nachmittag. snout.pink hat sechs tools in 456 zeilen typescript (vollstaendiger quellcode). die lernkurve ist flach, der vorsprung ist real.

die technologie ist ein W3C draft, ein feature flag, ein experiment. aber die richtung ist klar, und sie war noch nie so klar wie jetzt.

das internet verschwindet nicht. aber die art, wie wir es benutzen, durch browser, feeds und oberflaechen: das verschwindet. schneller als die meisten denken.

quellen [1] W3C Web Machine Learning Community Group, »WebMCP: draft community group report,« 10. februar 2026. webmachinelearning.github.io [2] S. Dean, »google chrome ships WebMCP in early preview, turning every website into a structured tool for AI agents,« venturebeat, februar 2026. venturebeat.com [3] snout.pink, subscription-tracker mit WebMCP-integration. snout.pink | github | webmcp.service.ts [4] Google Chrome, »chrome devtools MCP server.« github.com | WebMCP-erweiterung: WebMCP-org/chrome-devtools-quickstart [5] T. Zindler, »fluessige software: warum build jetzt buy schlaegt,« 2026. zindler.dev