Kostenloses Tool

MCP Token Calculator

Tool-Definitionen werden bei jeder Anfrage gesendet, nicht einmalig. Füge deine MCP-Server-URL ein und sieh, wie viele Tokens das sind, welche Tools am schwersten sind und was es kostet.

Funktioniert mit Streamable-HTTP- und SSE-Endpunkten, zum Beispiel https://mcp.example.com/mcp
Dieser Server benötigt eine Authentifizierung
Wird nur für diese eine Anfrage verwendet und nie gespeichert.

Schemas gekürzt. Jetzt zeig, was übrig ist.

Weniger Kontextkosten machen deinen Server günstiger im Betrieb. Einem Kunden zeigen sie trotzdem nicht, was er tut. Richte MCP Showcase auf dieselbe URL für ein Live-Playground mit Dokumentation pro Tool.

So funktioniert es

link
URL einfügen

Wir lesen die Tool-Definitionen, die der Server bereitstellt — dieselben, die ein Agent erhält.

play_circle
Jedes Tool wird gemessen

Name, Beschreibung und vollständiges JSON-Input-Schema, denn alle drei gehen bei jedem Turn an das Modell.

checklist
Kosten und Verursacher sehen

Tokens pro Anfrage, geschätzte Kosten pro 1.000 Turns und die Tools sortiert danach, wie viel Kontext jedes verbraucht.

Tool-Definitionen kosten bei jedem Turn

Das ist der Teil, der die meisten überrascht. Die Tool-Definitionen eines MCP-Servers werden nicht einmal zu Beginn eines Gesprächs geladen — das Modell erinnert sich zwischen den Turns nicht an sie, also wird die vollständige Liste mit allen Beschreibungen und allen JSON-Input-Schemas bei jeder Anfrage erneut mitgesendet. Vierzig ausschweifende Tools sind keine einmalige Sache, sondern eine feste Abgabe auf jeden einzelnen Turn jedes Gesprächs, das dein Agent je führen wird.

Füge oben eine MCP-Server-URL ein: Der Rechner liest genau das, was ein Agent erhält, misst es und zeigt, wo das Gewicht tatsächlich liegt.

Was gemessen wird

  • Tokens pro Anfrage — die Zahl, die zu deinem Kontextfenster hinzukommt, bevor System-Prompt, Gesprächsverlauf oder Tool-Ergebnisse überhaupt dazuzählen.
  • Kosten pro 1.000 Turns — dieselbe Zahl in Geld ausgedrückt, was das Problem meist erst greifbar macht.
  • Tokens pro Tool, sortiert — fast immer verursachen wenige Tools den Großteil der Summe, und es sind selten die, die man erwartet.

Wie du sie verkleinerst

Nach Wirkung sortiert. Entferne Tools, die niemand aufruft. Server sammeln sie an; jedes wird bei jedem Turn berechnet, ob es je nützlich ist oder nicht. Kürze Beschreibungen auf einen klaren Satz dazu, was das Tool tut und wann man es nutzt — alles Längere ist meist für einen menschlichen Leser geschrieben, der es nie zu sehen bekommt. Straffe die Input-Schemas: Lange Beschreibungen pro Property und tief verschachtelte optionale Objekte machen in der Regel den Löwenanteil eines schweren Tools aus, und sie summieren sich, weil Schemas ausschweifendes JSON sind statt Prosa.

Es gibt einen zweiten Grund, der nichts mit Geld zu tun hat: Die Trefferquote bei der Tool-Auswahl sinkt, je länger die Liste wird. Ein Modell, das zwischen achtzig ähnlich beschriebenen Tools wählt, greift deutlich häufiger daneben als eines mit acht — Ausdünnen macht den Agenten also meist nicht nur billiger, sondern auch besser.

Zur Schätzung

Gerechnet wird mit rund 3,6 Zeichen pro Token, was zum JSON-dichten Text von Tool-Definitionen passt und typischerweise etwa 10–15 % von einem echten Tokenizer abweicht. Das ist das richtige Werkzeug, um Tools untereinander zu vergleichen und Ballast zu finden. Es ist nicht das richtige Werkzeug, um eine Rechnung zu prüfen — und die Seite sagt das bei jedem Ergebnis, statt es dich annehmen zu lassen.

Verwandte Tools und Anleitungen

Weniger, klarere Tools brauchen mehr Dokumentation, nicht weniger

Beschreibungen zu kürzen spart Kontext, macht deinen Server günstiger und deinen Agenten treffsicherer. Es macht den Server aber auch schwerer verständlich für Menschen — und das wird zum Problem, sobald jemand ihn bewerten soll. MCP Showcase löst diesen Zielkonflikt: Das Modell bekommt deine schlanken Schemas, Interessenten bekommen ein Live-Playground mit generierter, lesbarer Dokumentation pro Tool. Du schreibst also nicht eine Beschreibung, die zwei sehr verschiedenen Lesern gerecht werden muss.

Häufig gestellte Fragen

Weil das Modell sich zwischen den Turns nicht an sie erinnert. Die vollständige Tool-Liste mit Beschreibungen und JSON-Schemas wird mit jeder einzelnen Anfrage mitgesendet, damit das Modell weiß, was es aufrufen kann. Hundert ausschweifende Tools sind eine feste Abgabe auf jeden Turn jedes Gesprächs.

Es ist eine Schätzung, typischerweise mit etwa 10–15 % Abweichung von einem echten Tokenizer. Gerechnet wird mit rund 3,6 Zeichen pro Token, was zum JSON-lastigen Text von Tool-Definitionen passt. Gedacht ist das zum Vergleichen und zum Aufspüren von Ballast, nicht zur Rechnungsprüfung.

Drei Dinge, nach Wirkung sortiert: Tools entfernen, die ein Agent nie aufrufen wird; Beschreibungen auf einen klaren Satz kürzen, der sagt, was das Tool tut und wann man es nutzt; und die Input-Schemas straffen — lange Beschreibungen pro Property und tief verschachtelte optionale Objekte machen meist den Löwenanteil aus.

Nein. Gemessen werden nur die Tool-Definitionen — der Teil des Kontexts, den du über deinen Server steuerst. System-Prompt, bisheriger Gesprächsverlauf und Tool-Ergebnisse kommen obendrauf.

Im Protokoll nicht, in der Praxis zwei. Die Kosten wachsen linear mit jedem Turn, und die Trefferquote bei der Auswahl sinkt mit der Länge der Liste: Ein Modell, das zwischen achtzig ähnlich beschriebenen Tools wählt, greift deutlich häufiger daneben als eines mit acht.

Weitere kostenlose MCP-Tools