Bitculator

Richtlinien

MCP-Server-Richtlinien

Wie Keys und Limits beim MCP-Server funktionieren, worauf du dich verlassen kannst, wie Änderungen angekündigt werden und was über deine Tool-Aufrufe protokolliert wird.

Keys

Der Server akzeptiert nur MCP-Keys, die in der MCP-Konsole erstellt und als Authorization: Bearer YOUR_API_KEY oder X-API-Key: YOUR_API_KEY gesendet werden. Data-API- und Widget-Keys werden mit 401 abgelehnt. Das Erstellen oder Rotieren eines Keys erfordert eine verifizierte E-Mail-Adresse; der Key wird einmal angezeigt, kann nach 30, 90 oder 365 Tagen oder nie ablaufen, und Free, Starter und Pro erlauben 2, 5 und 10 aktive Keys.

Limits und Fair Use

Jeder Plan hat eine monatliche Anzahl an Tool-Aufrufen - Free 2.500, Starter 50.000, Pro 250.000 - und ein Burst-Limit von 30, 60 oder 120 Anfragen pro Minute. Das Burst-Limit zählt jede Anfrage an /mcp; das Monatskontingent zählt nur Tool-Aufrufe, auch solche, die mit einem Fehler enden, etwa bei einem unbekannten Coin. Der Monat ist bei Free der Kalendermonat in UTC und läuft bei kostenpflichtigen Plänen ab deinem Verlängerungstag.

Über dem Monatskontingent antwortet ein Tool mit rate_limited (HTTP 429) samt Limit, Nutzung und Rücksetzzeitpunkt; über dem Burst-Limit erhält die Anfrage selbst HTTP 429. Ein Tool, das dein Plan nicht enthält, antwortet mit plan_required und nennt den Plan, der es freischaltet.

Worauf du dich verlassen kannst

Der Vertrag umfasst die Tool-Namen, ihre Eingaben und ihre Ergebnisse. Alle Tools sind schreibgeschützt: Keines kann dein Konto oder irgendwelche Daten ändern. Jedes Tool antwortet aus der Data API v1, daher folgen die Ergebnisse deren Regeln - Kurse, Raten und Umlaufmengen als Dezimal-Strings und dieselbe Validierung - und kommen als JSON-Text plus structuredContent. Fehler lauten code (HTTP status): message.

Der Server meldet sich als Bitculator 1.0.0 in serverInfo und in /.well-known/mcp/server-card.json und antwortet in der MCP-Protokollversion, die der Client anfragt, von 2024-11-05 bis 2025-11-25.

Was als Breaking gilt

Das passiert nie ohne Ankündigung:

  • Ein Tool oder eine seiner Eingaben entfernen oder umbenennen oder eine optionale Eingabe zur Pflicht machen.
  • Ein Ergebnisfeld entfernen oder seinen Typ oder seine Bedeutung ändern.
  • Die Tool-Aufrufe oder das Burst-Limit senken, die ein Plan bereits hat.

Das kann jederzeit passieren und wird im Changelog festgehalten:

  • Neue Tools, neue optionale Eingaben und neue Ergebnisfelder.
  • Klarere Tool-Beschreibungen und Server-Anweisungen.
  • Neue Fehlercodes für neue Situationen - matche immer auf den Code, nie auf die Nachricht.
  • Höhere Limits und Kontingente.

Abkündigung

Ein Tool oder eine Eingabe, die zur Entfernung vorgesehen ist, wird im Changelog angekündigt, und ab diesem Tag weist die Beschreibung darauf hin. Die Entfernung erfolgt frühestens sechs Monate nach der Ankündigung.

Derzeit ist nichts abgekündigt oder zur Entfernung vorgesehen.

Was protokolliert wird

Jeder Tool-Aufruf wird mit deinem Konto, dem Key, dem Daten-Endpunkt des Tools und dem Abrechnungszeitraum erfasst, dazu eine Tageszählung, um dein Kontingent durchzusetzen und deine Nutzung anzuzeigen. Diese Einträge werden 12 Monate lang aufbewahrt. Die JSON-RPC-Nachrichten selbst und die Angaben zu deinem Client werden nicht gespeichert.

Schlägt ein Tool mit einem Serverfehler fehl, wird ein Teil der internen Antwort ins Server-Log geschrieben, damit der Fehler behoben werden kann.

Responsible Disclosure

Wenn du glaubst, eine Sicherheitslücke in bitculator.com, der Data API, dem MCP-Server oder den SDKs gefunden zu haben, schreib an contact@bitculator.com - mit der betroffenen URL oder dem betroffenen Endpunkt, Schritten zur Reproduktion und der Auswirkung, die du siehst. Du bekommst innerhalb von drei Werktagen eine Antwort.

Bitte halte die Meldung vertraulich, bis das Problem behoben ist, greife nicht auf fremde Daten zu und verändere sie nicht, und führe keine Denial-of-Service-Angriffe oder automatisierten Scans gegen die Produktion aus. Meldungen, die in gutem Glauben unter diesen Bedingungen erfolgen, werden nicht mit rechtlichen Schritten beantwortet. Es gibt kein bezahltes Bug-Bounty-Programm; auf Wunsch wird namentlich gedankt.

Derselbe Kontakt ist maschinenlesbar unter /.well-known/security.txt (RFC 9116) veröffentlicht.

Status und Vorfälle

Der Live-Status der Komponenten, offene Vorfälle und die Ausfälle der letzten 30 Tage stehen auf der Statusseite und unter /status.json.