MCP-Server
Die Real-User-Daten deiner Organisation aus einem KI-Client lesen, den du selbst betreibst (Claude, Cursor), über das Model Context Protocol. Nur lesend, pro Organisation freizuschalten, per OAuth verbunden.
Über das Model Context Protocol (MCP) kann ein KI-Client, den du selbst betreibst, Fragen zu deinen fastmon-Daten stellen. Du verbindest Claude, Claude Code oder Cursor einmal, danach liest das Modell dieselben Zahlen wie das Dashboard: Web Vitals, Traffic, Fehler, Server-Timing-Phasen, Lighthouse-Ergebnisse.
Das Modell ist deins. Fastmon antwortet aus den eigenen Daten, aber das Modell läuft beim Anbieter hinter deinem Client, und den wählen wir weder aus noch haben wir einen Vertrag mit ihm. Deshalb muss ein Owner den Server erst öffnen.
Alle Tools sind read-only. Nichts hier ändert eine Einstellung, löscht etwas oder startet einen Run.
Einschalten
Organisationseinstellungen → MCP-Server → Zugriff aus deinen eigenen KI-Clients. Nur Owner (org:update), und das Audit-Log hält es als Consent-Änderung fest.
Solange er aus ist, lässt sich die Organisation auf dem Consent-Screen nicht genehmigen, und ein früher genehmigtes Token bekommt 403 mcp_disabled, bevor eine Query läuft.
Ein Consent-Schalter, kein Not-Aus
Den MCP-Server auszuschalten schließt den MCP-Endpunkt und sonst nichts. Eine App, die bereits eine Verbindung hält, liest diese Organisation weiter über die normale API, mehr hat sie ohnehin nie verlangt. Eine Verbindung endet durch die Person, die sie genehmigt hat: Sie trennt sie unter Account → Zugriff, ihre Rolle wird eingeschränkt, oder sie geht. Wenn jemand keinen Zugriff mehr haben soll, ist Offboarding der Weg.
Client verbinden
Eine Adresse, für alle dieselbe:
https://api.fastmon.eu/mcpClaude Code trägt sie im Terminal ein:
claude mcp add --transport http fastmon https://api.fastmon.eu/mcpJeder andere Client nimmt dieselbe Adresse als Remote-MCP-Server oder Connector (Claude unter Einstellungen → Connectors, Cursor unter MCP). Danach schickt dich der Client zu fastmon, zum Anmelden und Bestätigen. Kein Key zum Einfügen, kein Secret, das irgendwo liegen bleibt.
Der Consent-Screen fragt nach:
- Einer Organisation, aus denen, die du erreichst. Die Verbindung liest genau diese eine, zwei Organisationen heißt also zwei Verbindungen. Eine mit ausgeschaltetem MCP ist markiert und lässt sich nicht genehmigen.
analytics:read, ohne das kommt keine Verbindung zustande.synthetic:read, optional. Drei Tools lesen Lighthouse-Reports und brauchen es; die anderen 17 funktionieren auch ohne.
Der Screen benennt die Verbindung als MCP-Verbindung, direkt neben der Adresse, an die er dich zurückschickt. Das ist die Tatsache, die man sehen sollte: Was du hier freigibst, kann ein KI-Modell erreichen.
Die Verbindung gehört dir. Ihre Rechte kommen bei jedem Request aus deiner aktuellen Rolle: Sie werden enger, sobald du herabgestuft wirst, und enden mit deiner Mitgliedschaft oder deinem Account. Eine Verbindung, die der Organisation gehört, wird bewusst abgelehnt. Ein Credential, das niemandem gehört, könnte nicht enden, wenn sein Besitzer geht.
Deine Verbindungen verwaltest du unter Account → Zugriff. Trennen wirkt sofort, und bereits ausgestellte Access-Tokens laufen binnen Minuten ab.
Kopiere die Adresse genau so, ohne Slash am Ende. Dein Client nennt sie, wenn er ein Token anfordert, und der Endpunkt akzeptiert nur ein Token, das in dieser Schreibweise an ihn adressiert ist. Unterhalb von /mcp wird nichts ausgeliefert.
Was das Modell lesen kann
20 Tools, alle nur lesend, alle auf die Organisation beschränkt, für die die Verbindung genehmigt wurde:
| Bereich | Tools |
|---|---|
| Discovery | list_sites, get_data_freshness |
| Traffic und Web Vitals | get_overview, get_timeseries, get_breakdown, get_experience_score |
| Veränderung über die Zeit | compare_periods, detect_changes |
| Fehler | get_errors, get_failed_resources, get_error_detail |
| Performance im Detail | get_cwv_distribution, get_loaf_attribution, get_resource_breakdown, get_third_party_impact, get_fetch_xhr, get_server_timing |
| Synthetic (Labor) | list_synthetic_pages, get_synthetic_lighthouse, get_synthetic_lighthouse_audits |
Geantwortet wird mit Aggregaten und Ranglisten, denselben, die hinter dem Dashboard stehen. Rohe Beacon-Zeilen gibt kein Tool zurück, und kein Tool nimmt eine Organisation entgegen: Sie kommt von der Verbindung.
Ein Aufruf ohne Site umfasst die ganze Organisation, denn eine MCP-Verbindung hat keine „aktuelle Site“ wie ein Dashboard-Tab. Geht es um eine bestimmte Site, sollte ein Modell zuerst list_sites aufrufen.
list_sites meldet außerdem, was jede Site sammelt: ob Fetch/XHR-Erfassung, Seitentyp-Erkennung, Checkout-Tracking, Session-Erfassung sowie Fehlermeldungen und Stack-Frames an sind, und welche Besucher-Kennung ihre Zahlen benutzen. Ohne das liest ein Modell das leere Ergebnis eines ausgeschalteten Schalters als „kein Problem“. Besucherzahlen folgen den Einstellungen jeder Site, genau wie im Dashboard, und eine Zahl über Sites mit verschiedenen Kennungen sagt das dazu, statt beides still zu vermischen.
Die drei Synthetic-Tools brauchen synthetic:read und Synthetic Monitoring für die Organisation. Fehlt eins davon, kommt eine Ablehnung mit Begründung zurück, nie ein leerer Report.
Wie Antworten qualifiziert werden. Jedes p75 trägt die Anzahl der Messungen mit, auf denen es steht (samples), und das ist nicht die Zahl der Pageviews: die Vitals-Spalten sind nullable, ein LCP-p75 kann also auf einer Handvoll Messungen ruhen. Damit wird auch ein null lesbar, denn inp_p75_ms: null neben samples.inp: 0 heißt „hier wurde nichts gemessen" und nicht „das Feature ist aus". Wo ein Tool eine Mindestzahl an Messungen anwendet, nennt es diese Schwelle: ein leeres Ergebnis unter einer Schwelle ist ein anderer Befund als eine leere Dimension. Ob eine Zahl zu dünn ist, um sie zu zitieren, bleibt die Entscheidung des Aufrufers.
Wie Filter matchen. Eine url als Pfad geschrieben (/checkout*) matcht den Pfad, und Textfilter matchen ohne Rücksicht auf Groß- und Kleinschreibung: browser: ["chrome"] und device_type: ["Desktop"] finden also das gespeicherte Chrome und desktop. country nimmt Codes, keine Namen, und repariert die, die ISO nicht vergibt (UK und EN zu GB, EL zu GR). Ein Tag, das keine Site trägt, wird abgewiesen, statt als Scope über null Sites beantwortet zu werden. Es gibt keine Zeitzone pro Site: ein Zeitraum ohne Offset wird als UTC gelesen.
Grenzen
- 90 Tage pro Aufruf, und 50 Zeilen pro Breakdown.
- 120 Requests pro Minute, gezählt pro Person statt pro Organisation, damit ein Client in der Schleife keine Kollegen aussperrt. Darüber: 429 mit der Wartezeit in Sekunden.
- Minuten-Buckets gehen über maximal 6 Stunden, weil Minutenauflösung die rohe Beacon-Tabelle liest. Längere Zeiträume laufen über Stunden-Buckets oder gröber.
- 30 Sekunden pro Query, danach wird abgebrochen und das Tool sagt es. Meist steckt ein Breakdown mit hoher Kardinalität (URL, Browser-Version, Origin-Host) über einen langen Zeitraum dahinter.
Was fastmon verlässt
Die Antworten: Seiten-URLs, Referrer und UTM-Parameter, Geografie auf Länderebene, Gerät und Browser, Zeiten, Fehlersignaturen. Es sind dieselben Felddaten, die dein Dashboard zeigt, und kein Tool erreicht Daten, die ein Mitglied nicht ohnehin dort sehen könnte.
Zu prüfen ist, wohin diese Antworten gehen. Empfänger ist, wer das Modell hinter deinem Client betreibt, und das ist deine Beziehung, nicht unsere: Fastmon wählt diesen Anbieter nicht aus, hat keinen Vertrag mit ihm und führt ihn nicht als Unterauftragsverarbeiter. Ob deine Organisation diese Übermittlung vornehmen darf und auf welcher Grundlage, ist deine Bewertung. Daher der Schalter auf Owner-Ebene mit Audit-Eintrag.
Der eingebaute Ask-Assistent ist eine eigene Entscheidung: Er gibt Daten an unseren eigenen Unterauftragsverarbeiter unter unserer DPA. Zwei Empfänger, zwei Schalter, keiner impliziert den anderen.
An dem, was fastmon überhaupt sammelt, ändert sich hier nichts. Ein Feld, das der Tracker nie erfasst hat, kann das Modell auch nicht abfragen.
Agenturen
Eine Partner-Organisation kann sich persönlich mit einer Kunden-Organisation verbinden: Die Kunden-Organisationen stehen auf dem Consent-Screen zur Auswahl. Partner-Zugriff wird bei jedem Request aufgelöst, die Verbindung hört also auf zu funktionieren, sobald die Partnerschaft endet, und es bleibt nichts zu widerrufen.
mcp_enabled bleibt beim Kunden, denn es hängt an org:update, und das trägt Partner-Zugriff bewusst nicht. Das Onboarding kostet auf Kundenseite also einen Klick, und die Genehmigung landet im Audit-Log des Kunden, gekennzeichnet als Partner-Zugriff.
Einen MCP-Client bauen
Streamable HTTP (JSON-RPC 2.0), zustandslos, reine JSON-Antworten. Kein SSE, keine Session-ID, die gehalten werden muss.
OAuth ist der einzige Weg hinein. Der Endpunkt nimmt ein fmt_-Access-Token und sonst nichts: keinen persönlichen fm_-Key, keinen Organisations-Key fmo_, kein Session-Cookie. Ein Key trägt keine Audience und kann deshalb nicht sagen, ob er für diesen Endpunkt ausgestellt wurde.
Richte deinen Client auf https://api.fastmon.eu/mcp, den Rest findet er selbst:
- Der unauthentifizierte Aufruf antwortet mit
401undWWW-Authenticate: Bearer …, scope="analytics:read synthetic:read", resource_metadata="…". - Dieses Dokument (
/.well-known/oauth-protected-resource/mcp, RFC 9728) nennt den Authorization Server und die Scopes, die diese Ressource benutzt. - Registrieren (RFC 7591), Authorization Code mit PKCE ausführen und den Endpunkt im Parameter
resource(RFC 8707) nennen, im Authorization-Request und im Token-Request. Ein String, für jeden Kunden derselbe. Die Audience entscheidet der Authorization-Request, der Consent bindet sie an die Verbindung, und der Token-Request darf denselben Wert nur wiederholen.
Der Mandant wird beim Consent festgelegt und sonst nirgends. Ein Client kann an keiner Stelle des Flows eine Organisation benennen, deshalb gibt es auch in den Tool-Argumenten nichts, was nach Mandant aussieht.
Zwei Defaults solltest du kennen. Eine Registrierung ohne scope bekommt allein analytics:read, nachzulesen in der Antwort. Wer die Lighthouse-Tools braucht, muss synthetic:read also ausdrücklich anfordern. Eine Registrierung ohne Angabe zu credential_owner bekommt eine persönliche Verbindung, und genau die verlangt dieser Endpunkt. organization plus MCP-Ressource wird beim Consent mit einer entsprechenden Meldung abgelehnt.
403 mcp_disabled heißt, die Organisation hat den Server ausgeschaltet. Die Antwort trägt keinen WWW-Authenticate-Header, weil eine neue Autorisierung daran nichts ändert. Zeig die Meldung, statt einen neuen Flow zu starten.
Der vollständige OAuth-Vertrag, inklusive Refresh-Rotation und der Fehler, auf die du verzweigen musst, steht unter OAuth apps (nur auf Englisch).
Verwandt
- OAuth apps (nur auf Englisch): Registrierung, PKCE, Tokens, Trennen.
- Organisationen → Rollen: die Rollen, gegen die eine Verbindung geschnitten wird.
- Privacy: was fastmon überhaupt sammelt.
- Synthetic Monitoring: das Opt-In, das die drei Labor-Tools zusätzlich brauchen.