Angeschlossene MCP-Server
Bearbeiten Sie eine beliebige Zeile. Lassen Sie eine Zeile leer (kein Name), um sie auszuschließen. Alle Zeilen zählen für die Schema-Vereinigung, die jedes Mal erneut gesendet wird – unabhängig davon, ob die Tools dieses Servers diese Sitzung aufrufen oder nicht.
Sitzungsvolumen und Preise
—
monatliche Schemakosten, aktuelle Einstellung—nicht zwischengespeicherte Gesamtmenge/Monat
—zwischengespeicherte Gesamtmenge / Monat
—durch Caching gespeichert
Zugeordnete monatliche Kosten nach Server
Sortiert nach den zugeschriebenen monatlichen Kosten, die höchsten zuerst. In der obersten Reihe befinden sich häufig die größte Toolanzahl und das schwerste Schema – nicht unbedingt der Server, den Sie am häufigsten aufrufen.
| Server | Werkzeuge | Schema-Tok/Tool | Tok/drehen | Anteil an der Gesamtmenge | Zugeordnete monatliche Kosten |
|---|
Wie dies mit anderen Tools verbunden ist
Bei diesem Rechner handelt es sich um die Multi-Server-Ebene zusätzlich zu den beiden Einzel-Server-Tools, die es bereits auf dieser Website gibt – lesen Sie beide, um zu sehen, wie die drei zusammenpassen. Der MCP-Serverkostenrechner Preise für die Infrastruktur für den Betrieb eines MCP-Servers: Hosting, amortisierte Baukosten und eine monatliche Wartungspauschale. Diese Zahl wird von demjenigen bezahlt, der den Server betreibt, und hat nichts damit zu tun, wie eine bestimmte LLM-Konversation sie nutzt – ein Server kann nahezu kostenlos gehostet werden und dennoch der größte Einzelposten in Ihrer Token-Rechnung sein. Der MCP-Tool-Schema-Token-Overhead-Rechner Bepreist die wiederkehrende Token-Steuer der Tool-Schemata eines Servers, die bei jeder Sitzungsrunde erneut gesendet wird – die Einzelserverversion der Schema-Steuer. Dieser Rechner fügt den Teil hinzu, der keines dieser Dinge abdeckt: Was passiert, wenn mehr als ein Server gleichzeitig mit derselben Sitzung verbunden ist und der Client die erneut sendet? Union der Schemata jedes verbundenen Servers auf Schritt und Tritt zusammen und wie diese Gesamtrechnung wieder pro Server aufgeteilt werden sollte, damit Sie wissen, welche Verbindung es tatsächlich wert ist, beibehalten zu werden. Dedizierte Runtime-Observability-Produkte wie MCPSpend gehen noch einen Schritt weiter, indem sie die tatsächlichen Ausgaben pro Server und pro Projekt anhand von Proxy-Protokollen messen und nicht anhand einer modellierten Schätzung. Die Kombination mit diesem Rechner lohnt sich, wenn Sie die modellierte Zuordnung anhand der tatsächlichen Ereignisse in der Produktion überprüfen möchten.
So funktioniert dieser Rechner
Der MCP Multi-Server-Kostenzuordnungsrechner beginnt mit der Multiplikation der Werte jedes verbundenen Servers Werkzeuganzahl durch seine durchschnittliche Schema-Tokens pro Tool um die Token pro Runde dieses Servers zu erhalten, und summiert dann die Zeile jedes Servers totalSchemaTokensPerTurn – die Union, die der Client in jeder Runde erneut sendet, unabhängig davon, welches Tool tatsächlich aufgerufen wird. Multiplizieren Sie das mit Umdrehungen pro Sitzung um die Schema-Token-Anzahl pro Sitzung zu erhalten, dann um Sitzungen pro Tag × 30 um das monatliche Schema-Token-Volumen zu erhalten. Der Preis für dieses Volumen beträgt entweder den nicht zwischengespeicherter Eingabepreis oder die zwischengespeicherter Eingabepreis Abhängig von der Caching-Umschaltung wird die Überschrift der monatlichen Schemakosten angezeigt.
Der Unterschied zu einem einfachen Token-Rechner ist der Attributionsschritt: der jedes Servers Anteil an der Gesamtmenge ist seine eigenen Tokens pro Runde dividiert durch die kombinierten Tokens pro Runde auf allen verbundenen Servern und seine zugerechnete monatliche Kosten ist einfach die monatlichen Schemakosten multipliziert mit diesem Anteil. Da der Anteil jedes Servers genau 100 % des verbundenen Schemas ausmacht, summieren sich die zugeordneten Kosten immer auf die gesamten monatlichen Kosten – es entstehen keine Kosten, die durch die Aufteilung entstehen oder vernichtet, sondern nur neu zugewiesen werden. Dies basiert bewusst auf Wie viel vom verbundenen Schema jeder Server ausmacht, nicht wie oft seine Tools tatsächlich aufgerufen werden – Ein Server kann der teuerste Einzelposten in Ihrer Rechnung sein, während er in dieser Sitzung völlig inaktiv ist, einfach weil er mit einer großen Anzahl an Tools und ausführlichen Schemata verbunden bleibt. Prompt-Caching ändert den Dollarbetrag der Gesamtsumme (normalerweise etwa 90 % Rabatt, sobald sich das identische Schemapräfix Runde für Runde wiederholt), ändert aber nicht, welcher Server den größten Anteil hält – es verringert nur die Zahl daneben.
Häufig gestellte Fragen
Warum kostet die Verbindung von drei MCP-Servern mehr als die Summe, die jeder Server für sich allein kosten würde?
Es kostet nicht mehr pro Server, aber es kostet mehr pro Runde, als die meisten Leute erwarten, weil der Client nicht nur die Tool-Schemata für den Server sendet, den Sie verwenden möchten, sondern in jeder Runde die Schemata für jeden MCP-Server, der derzeit mit dieser Sitzung verbunden ist, gebündelt in einer einzigen Union. Wenn Sie einen GitHub-MCP-Server mit 26 Tools, einen Slack-MCP-Server mit 11 Tools, einen Postgres-MCP-Server mit 6 Tools und einen Dateisystem-MCP-Server mit 8 Tools verbinden, sendet der Client das Schema aller 51 Tools in Runde eins, Runde zwei und in jeder Runde danach erneut, unabhängig davon, welches Tool in dieser Runde tatsächlich aufgerufen wird. Drei oder vier Server, von denen jeder einzeln kostengünstig zu betreiben ist, können zu einer Schema-Nutzlast von Zehntausenden von Tokens führen, die in jeder Anfrage sitzen, bevor die Konversation überhaupt beginnt. Derselbe Mechaniker der Vereinigung verbundener Tools ist für schwere Einzelserver wie GitHub dokumentiert, dessen Tooldefinitionen allein Zehntausende von Tokens umfassen können, einfach multipliziert mit der Anzahl der Server, die zufällig mit derselben Client-Sitzung verbunden sind.
Wenn die Tools eines Servers in dieser Sitzung nie aufgerufen wurden, warum werden ihr dann trotzdem Kosten zugeordnet?
Denn bei den hier genannten Kosten handelt es sich nicht um die Kosten für den Aufruf eines Tools, sondern um die Kosten für das Schema, das in jeder Anfrage enthalten ist, unabhängig davon, ob es verwendet wird oder nicht. Der Client schließt nicht selektiv nur die Schemata für Tools ein, die er voraussichtlich aufrufen wird; Es enthält das vollständige Schema für jedes Tool auf jedem verbundenen Server in jeder Runde, und dieser Tokenblock wird als gewöhnlicher Eingabetoken abgerechnet, unabhängig davon, was das Modell tatsächlich damit macht. Dieser Rechner rechnet den Anteil jedes Servers an der monatlichen Schemarechnung im Verhältnis zum Anteil dieses Servers am gesamten verbundenen Schema zu – Tools mal durchschnittliche Token pro Tool, dividiert durch die Summe aller Server – und nicht im Verhältnis dazu, wie oft seine Tools aufgerufen werden. Ein Server mit einer großen Anzahl an Tools und ausführlichen Schemata kann selbst bei null tatsächlichen Anrufen für den Großteil Ihrer monatlichen Rechnung verantwortlich sein, indem er einfach die Verbindung aufrechterhält, während ein Server, den Sie ständig nutzen, der aber zwei kleine Tools offenlegt, im Vergleich dazu fast nichts kostet. Dieses Missverhältnis zwischen „teuer für die Verbindung“ und „teuer für die Nutzung“ ist der springende Punkt bei der Preiszuordnung auf diese Weise statt nach Anrufvolumen.
Löst die Aktivierung des Prompt-Caching das Problem der Multi-Server-Schemakosten?
Es geht um die Höhe des Dollars, nicht um die zugrunde liegende Form der Kosten. Beim Caching zahlt der erste Durchgang einer Sitzung den vollen Eingabepreis für den Schemablock und liest dann diesen identischen Block mit einem erheblichen Rabatt – normalerweise etwa 90 % Rabatt – für jeden weiteren Durchgang aus dem Cache zurück, solange der exakt gleiche Satz an Tools verbunden bleibt und mitten in der Sitzung nichts neu angeordnet oder geändert wird. Dieser Rabatt ist real: Bei einem typischen Multi-Server-Setup kann er aus einer monatlichen Rechnung von mehreren Tausend Dollar ein paar Hundert machen. Es ändert sich jedoch nicht, welcher Server für den größten Anteil dieser Rechnung verantwortlich ist, da die Zuordnung immer noch proportional zum Anteil jedes Servers am verbundenen Schema ist, ob zwischengespeichert oder nicht – ein schwerer Server, der verbunden, aber selten genutzt wird, ist immer noch der größte Posten, nur mit einer geringeren Anzahl. Und das Caching funktioniert nur, solange die Werkzeugliste von Runde zu Runde identisch bleibt; Fügen Sie während der Sitzung einen verbundenen Server hinzu, entfernen Sie ihn oder ordnen Sie ihn neu an, und bei der nächsten Anfrage fehlt der Cache und es wird erneut der volle Preis gezahlt.
Wie unterscheidet sich dies vom MCP-Serverkostenrechner und dem MCP-Tool-Schema-Token-Overhead-Rechner, die bereits auf dieser Website verfügbar sind?
Alle drei haben etwas mit MCP zu tun, aber keiner von ihnen überschneidet sich. Der MCP-Server-Kostenrechner berechnet die Kosten für den Aufbau, das Hosting und die Wartung eines MCP-Servers als Infrastruktur – Ingenieurstunden, eine monatliche Hosting-Rechnung, Wartungsgebühr – eine Zahl, die sich nicht ändert, je nachdem, wie ein LLM-Gespräch ihn nutzt. Der MCP-Tool-Schema-Token-Overhead-Rechner berechnet die wiederkehrende Token-Steuer der Tool-Schemata eines Servers, die bei jeder Runde einer Sitzung erneut gesendet werden, die Einzelserverversion der Schema-Steuer. Bei diesem Rechner handelt es sich um die Multi-Server-Version: Er modelliert, was passiert, wenn Sie mehr als einen MCP-Server gleichzeitig mit derselben Client-Sitzung verbinden, wobei der Client die Vereinigung der Schemata jedes verbundenen Servers bei jeder Runde neu sendet und diese kombinierte Monatsrechnung dann wieder durch den Anteil jedes Servers am gesamten verbundenen Schema aufteilt – das Zuordnungsproblem, das nur dann auftritt, wenn sich mehr als ein Server im Raum befindet.