Entwickler

MCP-Server

Binde SocialGO in Claude, Cursor und jeden Model-Context-Protocol-Client ein, damit deine KI-Agenten den Katalog durchsuchen und Bestellungen eigenständig ausführen können.

Toolkit auf GitHub inspizieren

Was ist der SocialGO-MCP-Server?

Der SocialGO-MCP-Server stellt das Panel als eine Reihe von Tools für KI-Agenten über das Model Context Protocol bereit. Einmal verbunden, kann ein Assistent den Dienstkatalog durchstöbern, Bestellungen aufgeben und verfolgen, Nachfüllungen anfordern und das Guthaben verwalten – ohne individuellen Klebe-Code. Es ist eine dünne Lese-und-Handle-Schicht über derselben API, die dein Dashboard nutzt, sodass Agenten innerhalb der Limits und Preise deines Kontos bleiben.

Es funktioniert mit jedem MCP-fähigen Client, einschließlich Claude Desktop, Claude Code, Cursor und deinen eigenen Agenten, die auf einem MCP-SDK aufbauen.

Füge es deinem Client hinzu

Der Server wird als Paket @socialgo/mcp ausgeliefert und läuft über stdio via npx, sodass es nichts zu installieren oder selbst zu hosten gibt. Füge deiner MCP-Client-Konfiguration den folgenden Eintrag hinzu:

{
  "mcpServers": {
    "socialgo": {
      "command": "npx",
      "args": ["-y", "@socialgo/mcp"],
      "env": {
        "SOCIALGO_API_KEY": "your_api_key_here"
      }
    }
  }
}

Mit Claude Code kannst du ihn mit einem einzigen Befehl aus deinem Terminal registrieren:

claude mcp add socialgo -- npx @socialgo/mcp

Denke nach dem Hinzufügen daran, SOCIALGO_API_KEY in der Umgebung zu setzen, damit der obige Befehl ihn aufnehmen kann.

Authentifizierung

Der Server liest eine einzige Umgebungsvariable, SOCIALGO_API_KEY. Generiere einen Schlüssel in deinen Kontoeinstellungen, halte ihn geheim und commite ihn niemals in die Versionsverwaltung. Jeder Tool-Aufruf wird mit diesem Schlüssel authentifiziert und autorisiert, und Bestellungen werden gegen das zugehörige Kontoguthaben abgerechnet. Rotiere den Schlüssel jederzeit über dein Dashboard, um den Zugriff zu widerrufen.

Kern-Tools

Der Server hält eine kleine, stabile Tool-Oberfläche, die den gesamten Bestell-Lebenszyklus abdeckt:

search_services — Finde Dienste nach Plattform, Typ oder Stichwort. Es ist der Einstiegspunkt für jeden Workflow.
get_service — Rufe die vollständigen Details eines Dienstes ab: Rate, Min./Max.-Menge und unterstützte Optionen.
create_order — Gib eine Bestellung für einen Dienst gegen einen Ziel-Link oder Benutzernamen auf.
order_status — Prüfe den Live-Status, den Fortschritt und die Restmenge einer Bestellung.
balance — Lies das aktuelle Kontoguthaben und die Währung.
refill — Fordere eine Nachfüllung für eine berechtigte Bestellung an, die unter ihre gelieferte Menge gefallen ist.
cancel — Storniere eine Bestellung, die noch stornierbar ist, und hole das restliche Guthaben zurück.
list_orders — Blättere durch aktuelle Bestellungen mit ihrem aktuellen Status.
add_funds — Erstelle eine Aufladeabsicht, um dem Konto Guthaben hinzuzufügen.

Das „Suchen-dann-Handeln“-Design

Ein typisches SMM-Panel führt Tausende Dienste über Dutzende Plattformen. Ein Tool pro Dienst zu registrieren würde die Tool-Liste des Agenten überfluten, das Kontextfenster sprengen und das Modell langsamer und ungenauer machen. SocialGO vermeidet das vollständig.

Stattdessen lebt der Katalog hinter einem einzigen Discovery-Tool. Der Agent ruft zunächst search_services auf, um Tausende Optionen auf eine Handvoll relevanter Treffer einzugrenzen, inspiziert einen mit get_service und handelt erst dann mit create_order. Dieselben neun Tools decken den gesamten Katalog ab, egal wie groß er wird, sodass das Hinzufügen neuer Dienste im Backend die Tool-Oberfläche, die der Agent sieht, nie verändert.

Ein vollständiger Ablauf sieht so aus:

1. search_services({ query: "instagram followers" })
   → returns a short list of matching services with ids + rates

2. get_service({ id: "<id>" })
   → confirms rate, min/max and options before spending

3. create_order({ id: "<id>", link: "<target>", quantity: 1000 })
   → returns an order id

4. order_status({ id: "<order_id>" })
   → poll until completed

So bleibt die Tool-Liste winzig und vorhersehbar, der Katalog kann auf Tausende Dienste skalieren, und der Agent erhält jedes Mal einen zuverlässigen Bestätigen-vor-dem-Ausgeben-Schritt.