Instrumentiere den alten Pfad, bevor du ihn löschst

MCP ist ein offenes Protokoll für LLM-Apps, um Tools über JSON-RPC aufzurufen.

Kents Hausaufgabe: Du hast einen Legacy-Pfad, der noch eingebunden ist, und du hast nicht gezählt, ob ihn noch jemand nutzt. Miss, bevor du löschst.

Dieses Repo betreibt einen Dual-Era-MCP-Server und ein SQLite-Ledger, das einen Neustart übersteht. Du behältst den Fallback, solange eine Legacy-Operation verbleibt.

Die Versionierungsseite nennt die beiden Spuren. Legacy ist 2025-11-25 und früher: Die Sitzung beginnt mit initialize. Modern ist 2026-07-28 und später: Jede Anfrage trägt Version und Identität in _meta.

Abgeschlossene Arbeit zählen

Ein sich neu verbindender Client ändert die Anzahl der Anfragen. Fünf Legacy-Tool-Aufrufe kosten fünfzehn Anfragen, wenn der Client bei jedem Aufruf eine neue Verbindung öffnet, und sieben, wenn er eine Verbindung hält. Der Legacy-Handshake verbraucht initialize und notifications/initialized einmal pro Verbindung, sodass ein sich neu verbindender Client wie starker Legacy-Verkehr aussieht. Jede Zeile enthält dieselben fünf Tool-Aufrufe pro Spur:

Du zählst 5 und 5 in der Operationszeile. Die Anfragezeilen unterscheiden sich um sechs Punkte, weil der Client sich entschieden hat, sich neu zu verbinden. recommend() liest die Operationszeile. Zähle die Einheit, die nach einem Transport-Rewrite oder einem Client, der seine Verbindungsweise ändert, immer noch übereinstimmt.

Related MCP server: mcpstat

Ausführen

Node 24 oder neuer. Du speicherst das Ledger mit node:sqlite.

Starte zuerst den Collector, dann den Server, dann generiere Verkehr:

pnpm install

pnpm collector   # http://127.0.0.1:3000, OTLP (the metric export format) and agent tools
pnpm server      # http://127.0.0.1:8787, dual-era MCP server
pnpm traffic     # legacy and modern tool calls, plus DCR and CIMD hits

DCR ist Dynamic Client Registration: Der Client POSTet Metadaten an /register bei jeder Verbindung. In 2026-07-28 veraltet. CIMD ist Client ID Metadata Documents: Die Client-ID ist eine HTTPS-URL zu statischen Metadaten, der Ersatz für DCR.

Dann lies die beiden Speicher:

pnpm report      # verdict from .data/migration-evidence.db
pnpm proof       # lane series from the collector

Warte sechs Sekunden nach pnpm traffic vor pnpm proof, damit das Scraping landet.

Der erste Lauf gibt Folgendes aus:

Migration readiness: MCP protocol lanes
=======================================
window            : 7 days
active days       : 1/7 required
legacy operations : 5
modern operations : 3
total operations  : 8/100 required
legacy %          : 62.50%
raw requests      : 15 legacy / 6 modern
legacy methods    : initialize x5, notifications/initialized x5, tools/call x5
legacy clients    : legacy-dashboard@0.9.4
modern clients    : modern-agent@2.1.0
auth DCR          : 2 attempts (1 success, 1 failure)
auth CIMD         : 3 attempts (2 success, 1 failure)

recommendation    : keep_both

A legacy client completed an operation. Keep the fallback and check next week.
Ask these clients to upgrade: legacy-dashboard@0.9.4.

pnpm traffic sendet fünf Legacy-Clients und drei moderne, die Mischung, die Kent einige Wochen nach einer Spezifikationsveröffentlichung beschreibt. Jeder Client verbindet sich für seinen einen Aufruf neu, sodass die Anfragezeile 15 gegen 6 liest. Der Bericht nennt legacy-dashboard@0.9.4, damit du weißt, wem du schreiben sollst.

Die Richtlinie

Standardwerte: ein Sieben-Tage-Fenster, sieben aktive Verkehrstage, 100 abgeschlossene Operationen.

recommend() gibt keep_both nach einer Legacy-Operation zurück, selbst bei zweihundert modernen. Dieser Aufruf gehört immer noch einem Client. Modernes Volumen sagt dir nicht, ob jemand den alten Pfad noch braucht.

Veraltungsfenster

Das Register veralteter Funktionen listet DCR, roots, sampling und logging als in 2026-07-28 veraltet. Früheste Entfernung ist die erste Revision am oder nach 2027-07-28. Ein sauberer lokaler Bericht verschiebt dieses Datum nicht. Clients, die der Spezifikation folgen, haben das zugesagte Fenster weiterhin.

Frag deinen Agenten

Lass Collector und Server laufen. .mcp.json zeigt autotel auf http://127.0.0.1:3000/mcp und migration auf http://127.0.0.1:8787/mcp. migrationStatus liest das dauerhafte Fenster.

Liste mcp.protocol.lane.operations in autotel auf und vergleiche die Serien lane=legacy und lane=modern. Rufe migrationStatus auf dem Migrationsserver auf. Können wir den 2025-11-25-Fallback entfernen? Zitiere die Operationszahlen, aktiven Tage und Richtlinienschwellen.

Führe diesen Prompt wöchentlich per Cron aus und du erhältst Kents Antwort.

Signale

list_metrics gibt eine Serie pro Attributsatz zurück, also gruppiert der Agent nach lane. Du benötigst autotel-mcp 0.5.1 oder neuer, damit diese Attribute den Ingest überleben.

Kent durchschnittlich 125 DCR-Registrierungen pro Benutzer, weil jede Wiederverbindung einen weiteren Datensatz schreibt. Ein CIMD-Client schreibt keine. Zähle beide Modi und du kannst sehen, wann DCR verstummt ist.

Entscheidungen zum Übernehmen

Zähle Volumen, dann miss Stille. Lies die Zähler für das eingehende Legacy-Volumen. Du brauchst die letzte Ankunft, um über die Entfernung zu entscheiden. mcp.protocol.legacy.days_since_last_operation liest das Ledger, wenn der Collector scraped, sodass du es nicht im Anfragepfad neu berechnest. Alarmiere, wenn der Messwert 30 überschreitet.

Setze Methodennamen auf die Metrik. Setze Clientnamen ins Ledger. mcp_method ist ein Label, also erzeugt jeder neue Wert eine weitere Serie, und ein nicht authentifizierter Aufrufer wählt den Wert. STANDARD_METHODS in factory.ts ist eine Allow-List: Alles Unerkannte wird als unknown aufgezeichnet. Clientnamen haben keine Grenze, also gehen sie in SQLite. Ein weiterer Name kostet eine Zeile.

Behalte beide Schwellen. Eine Mindeststichprobe verhindert, dass du die Entfernung an einem ruhigen Nachmittag genehmigst. Eine Mindestanzahl aktiver Tage verhindert, dass du sie an einem einzigen geschäftigen Dienstag genehmigst, der den wöchentlichen Batch-Job verpasst hat.

Bediene beide Epochen ohne Sitzung. createMcpHandler läuft mit legacy: 'stateless'. Eine Factory bedient beide Epochen und ctx.era benennt die Spur. Jede Instanz kann jede Anfrage beantworten, also schreibst du den Zähler. Du brauchst keine Sitzungstabelle oder Sticky-Routing. Ein zustandsbehafteter Fallback würde dich zwingen, Sitzungen zu instrumentieren. Der Bericht würde dann vom Load Balancer abhängen.

Clientnamen pro Epoche

Eine moderne Anfrage nennt ihren Aufrufer. Eine Legacy-Anfrage nennt den Aufrufer einmal, während initialize.

Der moderne Envelope wiederholt clientInfo in params._meta bei jeder Anfrage, sodass jede Instanz sie bedienen kann. Die Legacy-Spur legt den Namen auf den Handshake. Ein zustandsloser Server hat keinen Ort, um ihn für den folgenden Tool-Aufruf zu behalten. factory.ts liest beide. Der Bericht kann legacy-dashboard@0.9.4 nennen, weil dieser Name bei initialize ankam, nicht bei dem Tool-Aufruf, der gezählt wird.

Du kannst ein Gateway auf MCP-Method routen, weil die Anfrage sich selbst beschreibt. Du attribuierst Verkehr aus diesem Grund auch ohne Sitzung.

activeDays bucketed nach UTC-Datum, sodass ein Client, dessen Benutzer abends in den USA arbeiten, in zwei Buckets landen kann. Die Auth-Routen schreiben DCR- und CIMD-Versuche. Sie prägen keine Tokens und holen keine CIMD-Dokumente.

Konfiguration

GET /metrics/lanes?windowDays=30 nimmt dasselbe Fenster, bis zu 90 Tage.

Um zu sehen, dass das Ledger einen Neustart übersteht: Führe traffic aus, stoppe den Server, starte ihn erneut, führe pnpm report aus. Die Zähler bleiben.

pnpm collector hält Telemetrie in autotel.db für 30 Tage. Der Server hält Beweise in .data/migration-evidence.db für 90. Git ignoriert beide.

Dual-Era-Server

Der Server ist Dual-Era, weil createMcpHandler mit legacy: 'stateless' läuft und ctx.era die Spur benennt, die du zählst. Siehe das Changelog für den Rest des 2026-07-28-Änderungssatzes.

autotel-mcp-instrumentation fügt Spans und Dauer-Histogramme auf beiden Seiten hinzu. Du beantwortest die Entfernungsfrage aus den Zählern und dem Ledger.

Code-Map

Verifizieren

pnpm typecheck
pnpm test

Dreizehn Tests decken den Verhältnis-Bias, Fensterfilterung, Neustart-Persistenz, Auth-Ergebnisse, Client-Attribution, Legacy-Methodenzählungen und beide Entfernungsschwellen ab.