Ein MCP-Server übergibt Zahlen an etwas, das danach laut, selbstsicher und gegenüber jemandem, der es nicht prüfen kann, darüber nachdenken wird. Das ist ein anderes Entwurfsproblem als eine API für ein Programm, und das meiste daran hat mit dem Protokoll nichts zu tun.

Dies sind sechs Entscheidungen in Skomis MCP-Server und wogegen jede sich wehrt. Keine davon ist raffiniert; mehrere sind die zweite Fassung, nachdem die naheliegende sich als Falle erwiesen hatte.

1. Das Token ist eine Kopfzeile, nie ein Werkzeugparameter

Der naheliegende Entwurf ist ein Parameter token an jedem Werkzeug. Er dokumentiert sich selbst, er funktioniert, und er setzt das Geheimnis des Kunden in die Unterhaltung, wo es in die Protokolle des Clients gelangt, in jedes Gesprächsprotokoll, das exportiert wird, und in alles, was das Modell beim Erklären dessen, was es gerade getan hat, zurückzugeben beschließt.

Eine Kopfzeile ist für das Modell unsichtbar. Sie kann nicht zitiert werden, weil sie nicht im Kontext steht.

Dieselbe Überlegung sagt, dass der Server kein eigenes Token halten sollte. Skomis leitet weiter, was der Aufrufer sendet, und behält nichts, er kann also nichts, was Sie nicht schon mit curl könnten. Es gibt keinen Modus, in dem er festen Zugang zu irgendjemandes Daten hat, was die einzige prüfbare Fassung von „wir nehmen Sicherheit ernst" ist.

2. Nichts schreibt

Jedes Werkzeug ist mit readOnlyHint versehen, und die API dahinter ist von vornherein nur lesend, die Kennzeichnung ist also eine Beschreibung und kein Versprechen.

Das lohnt deutlich gesagt zu werden, denn die Versuchung geht in die andere Richtung: Ein Assistent, der eine Einstellung ändern könnte, führt sich großartig vor. Es heißt auch, dass eine falsch gelesene Anweisung Folgen hat, die die Unterhaltung überleben. Lesen ist heilbar; Schreiben nicht, und ein Analytics-Werkzeug hat nichts zu schreiben, was das wert wäre.

3. Eine Störung gibt einen Fehler zurück, keine Nullen

Wenn der Speicher nicht verfügbar ist, scheitern die Werkzeuge. Sie geben bewusst keine Seite voller Nullen zurück.

Nullen wären die freundlichere Antwort und die gefährlichere, denn ein Modell kann eine kaputte Woche nicht von einer ruhigen unterscheiden. „Der Verkehr fiel am Dienstag auf null" ist ein Satz, den ein Assistent in gutem Glauben aus plausibel aussehenden Daten erzeugen wird, und wer ihn liest, hat keine Möglichkeit zu wissen, dass es eine Störung in der Analytics war und keine auf seiner Website.

Ein Fehler ist die schlechtere Erfahrung und die wahre. Die allgemeine Regel: Geben Sie nie einen Wert zurück, der von einer echten Messung nicht zu unterscheiden ist, wenn Sie keine Messung haben.

4. „Kein Vergleich" statt einer erfundenen Zahl

Jede Kennzahl kommt mit ihrer Veränderung gegenüber dem vorigen Zeitraum. Wenn der vorige Zeitraum null war, ist die Veränderung null im Sinne von nicht vorhanden: nicht unendlich, nicht 100 %, keine große Zahl, die sich zufällig darstellen lässt.

Die prozentuale Veränderung von null ist undefiniert, und jeder konkrete Wert, den Sie einsetzen, ist eine Zahl, die das Modell als Tatsache wiederholen wird. Die Werkzeuge sagen „kein Vergleich". Das ist weniger befriedigend und das einzige Ehrliche, das zur Verfügung steht.

5. Die Zeilen ergeben nicht 100, und das Werkzeug sagt es

Eine Aufschlüsselung zählt eindeutige Besucher je Zeile. Ein Mensch auf einem Telefon und einem Laptop steht in zwei Zeilen, die Zeilen ergeben also mehr als die Gesamtzahl, und die Prozentwerte addieren sich nicht zu 100.

Unausgesprochen ist das eine Falle mit einem sehr bestimmten Fehler: Ein Modell, das nach dem „Anteil des Verkehrs nach Land" gefragt wird, wird die Zeilen hilfsbereit auf 100 % normalisieren, eine völlig vernünftige Sache, die man mit einer Liste von Zahlen tut, und hier auf eine Weise falsch, die niemand stromabwärts bemerken wird.

Also sagt die Beschreibung des Werkzeugs es selbst: durch die Besuchergesamtzahl des Zeitraums aus dem Zusammenfassungswerkzeug teilen, nie durch die Summe der Zeilen. Die Berichtigung muss dort stehen, wo das Modell hinsieht, und das ist die Werkzeugbeschreibung, nicht die Dokumentation, die jemand anderes gelesen hat.

6. Filter sind Dimensionen, und es gibt einen Parser

Jeder Dimensionsname funktioniert auch als Filter, mit derselben Bedeutung an beiden Stellen:

breakdown  dimension=path  filters={"country":"EE","device":"mobile"}

Ein Parser heißt, dass die beiden nicht uneins sein können: ein Filter, den das Modell baut, ist genau ein Filter, den das Dashboard anwenden könnte, und eine Dimension, die es durch Fragen entdeckt hat, ist eine, nach der es sofort filtern kann. Es gibt auch ein Werkzeug, das nichts als die zulässigen Dimensionen, Zeiträume und Filterregeln zurückgibt, ein Modell kann also fragen, was erlaubt ist, statt zu raten und es erneut zu versuchen.

Die unschöne Ecke: Um auf einen Wert zu filtern, der nie aufgezeichnet wurde, etwa Besuche ohne Kampagne, übergeben Sie __none__. Eine leere Zeichenkette ist von einem fehlenden Parameter nicht zu unterscheiden, sobald die Anfrage geparst ist, der leere Wert muss also als irgendetwas reisen. Jede API bekommt eines davon; der ehrliche Zug ist, es zu dokumentieren, statt vorzugeben, die Form sei einheitlich.

Worauf das hinausläuft

Das meiste davon ist ein wiederholt angewandter Grundsatz: Eine mehrdeutige Antwort ist schlimmer als eine Verweigerung, denn das, was Ihre API verbraucht, wird die Mehrdeutigkeit selbstsicher und laut auflösen.

Das ist an MCP nichts Besonderes. Es ist bloß so, dass der übliche Verbraucher, ein Programm mit einem Programmierer dahinter, eine Ausnahme geworfen hätte, und dieser hier schreibt stattdessen einen Absatz.

Skomis Server steht unter mcp.skomi.com, und es gibt nichts zu installieren; die Query-API, die er liest, ist dieselbe, die alles andere auch nutzen kann.

Die Zahlen, die er liest, sind dieselben, die Analytics Ihnen zeigt, durch dieselbe Query-API; es gibt keine zweite Verarbeitungskette, über die das Modell falsch liegen könnte. MCP-Server definiert den Begriff, falls er neu ist.