Social-Media-MCP-Server: Was sie sind und wie du auswählst

Ein Social-Media-MCP-Server ist ein kleines Stück Software, das Social-Aktionen — einen Post entwerfen, ihn planen, die Zahlen der letzten Woche abrufen — über das Model Context Protocol für einen KI-Assistenten verfügbar macht, sodass der Assistent sie ausführen kann, statt sie nur zu beschreiben. Es gibt sie in zwei Ausprägungen: Server, die die API einer einzelnen Plattform umhüllen (einer für LinkedIn, einer für X, einer für Instagram), und Connectoren, die vor einem Planer sitzen und jeden dort bereits verbundenen Account abdecken. Die Wahl zwischen beiden läuft auf drei Fragen hinaus: Wer hält deine Access Tokens, wessen Rate Limits verbrauchst du, und wo sitzt das Freigabe-Tor.

Übersichtslisten dieser Server sind diesen Sommer zu einem eigenen Genre geworden. Das hier ist keine weitere Liste — es sind die Fragen, die ich stellen würde, bevor ich irgendetwas mit einem API-Key an einen Kundenaccount lasse, plus die ehrlichen Fälle, in denen die ganze Idee übertrieben ist. Falls MCP für dich neu ist: Unsere Erklärung in klarem Deutsch dazu, was MCP für die Social-Media-Planung bedeutet, deckt die Grundlagen des Protokolls ab; dieser Beitrag setzt bei der Kaufentscheidung an.

Die zwei Ausprägungen eines Social-MCP-Servers

Fast alles, was Stand August 2026 auf dem Markt ist, fällt in zwei Kategorien — und beide scheitern auf unterschiedliche Weise.

Server pro Plattform

Diese umhüllen die API eines Netzwerks direkt. Du gibst dem Server Zugangsdaten für diese Plattform — meist Client-ID und Secret einer App plus ein User Token — und der Assistent bekommt Tools wie create_post, list_recent_posts, get_metrics.

Der Reiz ist die Tiefe: Ein dedizierter LinkedIn-Server kann LinkedIn-spezifische Konzepte bereitstellen, die ein generisches Tool einebnet. Der Preis dafür: ein Server, eine App-Registrierung und ein Token-Refresh-Zyklus pro Netzwerk. Fünf Plattformen heißen fünf von allem — und alles geht unabhängig voneinander kaputt.

Dazu kommt eine Voraussetzung, die die meisten Übersichten überspringen: Bei mehreren Netzwerken kannst du nicht einfach ein Token einstöpseln. Du brauchst eine registrierte Developer-App, und auf manchen Plattformen einen genehmigten Use Case sowie einen Business- oder Creator-Account, bevor die Publishing-Endpunkte freigeschaltet werden. Das ist ein Formular und eine Wartezeit, kein Fünf-Minuten-Setup.

Connectoren auf Planer-Ebene

Diese sitzen vor einem Tool, das deine Plattformverbindungen bereits hält. Der Assistent bittet den Connector, "das für Dienstagvormittag auf Instagram und LinkedIn zu planen", und der Planer erledigt die plattformspezifische Arbeit darunter — Token-Refresh, Medienhandling, Formatierung pro Netzwerk, Retries.

Der Reiz: Eine Integration deckt jeden verbundenen Account ab, und die unangenehmen Teile bleiben das Problem von jemand anderem. Der Preis ist eine Obergrenze: Du kannst nur das, was die API des Planers unterstützt. Kennt sie zum Beispiel kein Konzept für einen angepinnten Kommentar, dann kennt es dein Assistent auch nicht.

Wenn du auf mehr als zwei Netzwerken veröffentlichst und kein Entwickler bist, ist die Connector-Variante fast immer der richtige Standard. Der Weg über Server pro Plattform ist für Leute, die die Spezialfeatures eines einzelnen Netzwerks brauchen und keine Scheu davor haben, App-Registrierungen zu pflegen.

Was du prüfst, bevor du Accountzugriff gibst

Ein MCP-Server ist Software, der du die Schlüssel zu deinem Distributionskanal aushändigst. Bewerte ihn so, wie du einen Handwerker mit Generalschlüssel einstellen würdest. Sechs Dinge zählen mehr als die Feature-Liste.

1. Das Auth-Modell

Frag, wo die Zugangsdaten liegen und welche Form sie haben. Drei Muster:

• Sauberes OAuth gegen die Plattform. Du bestätigst einen Consent-Screen mit klaren Scopes, und der Server hält ein erneuerbares Token. Der gute Fall: gescopt, nachvollziehbar, aus deinen Plattformeinstellungen widerrufbar.
• Ein langlebiges Token in einer Config-Datei auf deinem Rechner. Solo machbar, aber es ist Klartext in einem Dotfile, das synchronisiert, gebackupt und gelegentlich in ein Support-Ticket hineingescreenshottet wird.
• Zugangsdaten, die an einen gehosteten Dritten gehen, zu dem du vorher keinerlei Beziehung hattest. Hier gehst du am langsamsten vor — ein gehosteter Server, der deine Plattform-Tokens speichert, ist ein neuer Anbieter mit Publishing-Rechten auf deinen Accounts.

Die Frage lautet: Kann ich das in dreißig Sekunden widerrufen, ohne dass etwas anderes kaputtgeht? Wenn das Widerrufen des Servers auch deinen Planer abschießt, ist die Kopplung zu eng.

2. Wessen Rate Limits du verbrauchst

Jede Plattform-API deckelt Requests. Bei einem Server pro Plattform gehört das Kontingent deiner App-Registrierung, und ein Assistent, der sich durch "hol die Metriken für jeden aktuellen Post" schleift, kann es in einem einzigen Gespräch aufbrauchen — das Limit entdeckst du dann mitten im Launch, wenn eine echte Veröffentlichung fehlschlägt. Bei einem Connector teilst du dir das gepoolte Kontingent des Planers: nachsichtiger, aber nicht unendlich.

So oder so: Finde heraus, was am Limit passiert. Stellt das Tool in eine Warteschlange und versucht es erneut, oder wirft es einen Fehler, den der Assistent dann kreativ interpretiert? Ein Agent, der eine fehlgeschlagene Veröffentlichung sechsmal wiederholt, kann sechs Live-Posts produzieren.

3. Medien-Support

Hier hören überraschend viele Server still und leise auf. Etliche posten Text wunderbar und bekommen kein Bild zuverlässig angehängt. Prüfe:

• Kann er überhaupt Video hochladen, und was passiert bei längeren Dateien?
• Braucht er Medien unter einer öffentlichen URL, oder kann er Bytes von deiner Festplatte schicken? Mehrere Plattform-APIs verlangen Ersteres, also brauchst du zusätzlich einen Ort, an dem die Datei gehostet wird.
• Karussells mit mehreren Bildern, oder ein Asset pro Post?
• Validiert er vor dem Absenden gegen die Anforderungen der jeweiligen Plattform, oder reicht er die Datei einfach durch und spuckt einen kryptischen Fehler aus?

Der letzte Punkt zählt. Seitenverhältnisse und Längen sind pro Netzwerk fummelig — unser Guide zu Bild- und Videogrößen für Social Media existiert, weil die Vorgaben überall anders sind — und eine Validierung vorab spart Stunden Fehlersuche. Text hat dasselbe Problem im Kleinen: Ein Assistent, der die Zeichenlimits der einzelnen Netzwerke nicht kennt, schreibt Captions, die abgeschnitten werden. Ein guter Server nennt dem Modell die Vorgaben; ein schlechter lässt es raten.

4. Schreibrechte: entwerfen oder veröffentlichen?

Zwischen einem Server, der einen Entwurf anlegt, und einem, der sofort veröffentlicht, liegen Welten. Idealerweise bekommst du beides, getrennt steuerbar, damit du zuerst nur mit Entwürfen starten und den Scope erweitern kannst, sobald du dem Ding vertraust. Sei präzise: "kann posten" in einer README kann "reiht in einen Review-Status ein" bedeuten — oder "geht live, sobald das Modell das Tool aufruft". Ich habe erlebt, wie ein Assistent ein Datum falsch gelesen und "nächsten Dienstag" als "jetzt" behandelt hat.

5. Das Freigabe-Tor

Wo sieht ein Mensch den Inhalt, bevor er ein Publikum erreicht? Drei brauchbare Antworten:

1. Der Assistent erstellt Entwürfe, und du prüfst sie im Kalender, bevor überhaupt etwas geplant wird.
2. Das Tool hat einen echten Freigabe-Workflow, sodass ein vom Agenten erstellter Post in einem Pending-Status liegt, bis eine namentlich benannte Person ihn freigibt.
3. Du akzeptierst autonomes Veröffentlichen auf einem Account mit geringem Risiko und behältst ihn im Auge.

Wenn die Antwort "nichts davon" lautet, ist es für einen Kundenaccount nicht bereit. Dasselbe Prinzip wie in unserem Guide dazu, was du automatisieren solltest und was besser nicht: Automatisiere die Logistik, halte einen Menschen an allem, was in deiner Stimme spricht.

6. Wartung

Plattform-APIs ändern sich, und jemand muss den Server anpassen, wenn es so weit ist. Schau dir die jüngste Commit-Aktivität an, ob es ein Wochenendprojekt eines einzelnen Maintainers ist oder eine Firma dahintersteht, und wie schnell frühere Breaking Changes behandelt wurden. Ein Server, der seit sechs Monaten nicht angefasst wurde, ist nicht stabil — er ist ungepflegt, und du findest das heraus, wenn eine Plattform etwas abschaltet.

Ein konkretes Beispiel

Eine dreiköpfige Agentur will, dass ihr Assistent aus dem monatlichen Blogpost jedes Kunden eine Woche voller Posts macht.

Der Weg über Server pro Plattform: Developer-Apps für fünf Netzwerke bei vier Kunden, zwanzig Token-Lebenszyklen, fünf Server, Formatierungsregeln pro Netzwerk in Prompts codiert. Rund eine Woche Setup und eine dauerhafte Wartungssteuer.

Der Weg über einen Connector: Die Accounts sind im Planer bereits verbunden, der Assistent entwirft und passt pro Plattform an, direkt in den Kalender, eine Account-Managerin gibt frei. Ein Nachmittag Setup — und Plattformänderungen werden weiter oben abgefangen.

Der zweite Workflow geht live. Der erste ist ein Nebenprojekt, das gelegentlich live geht.

Wann MCP übertrieben ist

Ehrliche Antwort: Für viele Solo-Creator ist es das.

MCP verdient sich seinen Platz, wenn du echtes Volumen über mehrere Plattformen bewegst, und zwar wiederholt. Wenn du vier oder fünf Posts pro Woche auf zwei Netzwerken veröffentlichst, kosten Setup, Zugangsdaten und Fehlerquellen mehr, als sie an Zwischenablagenarbeit einsparen. In einem Chatfenster zu entwerfen und in einen Kalender einzufügen ist völlig ehrenwert — ein sorgfältiger menschlicher Schritt, der nie um 3 Uhr nachts veröffentlicht, weil ein Tool-Aufruf wiederholt wurde.

Lass MCP vorerst aus, wenn eines davon zutrifft:

• Du veröffentlichst auf einer oder zwei Plattformen.
• Dein Engpass sind Ideen oder das Filmen, nicht das Verschieben von Text zwischen Fenstern.
• Du wärst der Einzige, der es debuggen könnte, wenn es kaputtgeht.
• Deine Accounts sind deine Lebensgrundlage, und du hast keinen Testaccount zum Ausprobieren.

Komm darauf zurück, wenn Copy-Paste messbar deine Woche auffrisst, oder wenn die manuelle Arbeit pro Account über mehrere Kunden hinweg nicht mehr skaliert. Unser Überblick dazu, was KI-Agenten für Social leisten können und was nicht, ist ein fairer Realitätscheck dafür, wie viel von deinem Engpass ein Agent tatsächlich bewegen kann.

Wo die Planungsebene hineinpasst

Egal, was deine Inhalte entwirft — ein MCP-angebundener Assistent, ein Workflow-Tool, ein Mensch — irgendetwas muss trotzdem die Warteschlange halten, die Regeln jeder Plattform respektieren, pünktlich veröffentlichen und einem Menschen einen Ort geben, an dem er zuerst hinschaut. Genau diese Publishing-Ebene willst du langweilig und verlässlich haben.

SocialKit ist als genau diese Ebene gebaut. Es deckt 11 Plattformen ab — Instagram, TikTok, YouTube inklusive Shorts, Facebook, LinkedIn, X, Threads, Bluesky, Pinterest, Mastodon, Google Business — aus einem visuellen Kalender, mit Einmal-verfassen-dann-pro-Plattform-anpassen, Auto-Publish, Empfehlungen für die beste Posting-Zeit und Post-Analytics. Jeder Plan enthält API-Zugang und Webhooks, also die Ebene, mit der jeder Connector spricht; Freigabe-Workflows gibt es in den Team- und Enterprise-Plänen für das oben beschriebene menschliche Tor. Stand August 2026 sind die Preise pauschal — alle 11 Plattformen und unbegrenzt geplante Posts in jedem Plan, ab €29/Monat bei Solo (€17.40/Monat bei jährlicher Abrechnung), mit einer 7-tägigen kostenlosen Testphase.

Damit klar ist, was es nicht ist: SocialKit hat keine einheitliche Social Inbox, kein Social Listening und keine Warteschlange zur Kommentar-Moderation. Wenn dir eine Übersichtsliste einen MCP-Server für Inbox-Triage verkaufen will, ist das eine andere Tool-Kategorie, und du brauchst etwas anderes, worauf du ihn richtest. Was SocialKit einem Assistenten gibt, ist eine Publishing-Oberfläche mit echtem plattformspezifischem Kontext darunter.

Die Accounts an einen Ort zu bringen ist hier die unglamouröse Voraussetzung — unsere Anleitung zum Verbinden deiner Social-Media-Accounts lohnt sich, bevor du auch nur einen einzigen Server bewertest.

Fang hier an

Eine vernünftige Reihenfolge:

1. Schreib die Aufgabe auf. "Aus einem Blogpost eine Woche voller Posts über fünf Plattformen für vier Kunden machen" ist eine Aufgabe. "MCP nutzen" nicht. Wenn du sie nicht in einem Satz formulieren kannst, shoppst du — du löst kein Problem.
2. Wähl die Ausprägung. Multi-Plattform-Publishing heißt Connector. Tiefe Arbeit auf einer einzelnen Plattform heißt Server pro Plattform. Betreib nicht beides, bevor eines funktioniert.
3. Geh die sechs Checks durch. Auth-Modell, Rate Limits, Medien-Support, Schreibrechte, Freigabe-Tor, Wartung. Ein klares "Nein" bei Auth oder Freigabe ist ein Ausschlusskriterium.
4. Teste auf einem Wegwerf-Account. Gib ihm Schreibzugriff auf etwas, das dir egal ist, und versuch, es kaputtzumachen. Schau zu, was bei einer fehlgeschlagenen Veröffentlichung passiert.
5. Starte read-only, dann nur mit Entwürfen. Eine Woche lang nur deine Warteschlange und Analytics lesen. Dann entwerfen. Erst danach planen.
6. Behalte das Tor. Eine namentlich benannte Person gibt frei, bevor irgendetwas ein Publikum erreicht. Solo bist das du, im Kalender, bevor die Warteschlange läuft.
7. Zieh nach einem Monat Bilanz. Hat es Arbeit entfernt oder nur verschoben? Etliche Leute gehen still und leise dazu zurück, alles im Kalender zu prüfen — und sind damit glücklicher.

Das Framework zählt mehr als die Shortlist, denn die Shortlist wird in sechs Monaten anders aussehen. Alles, was Social-Media-Automatisierung berührt und Publishing-Rechte hat, verdient dieselbe Prüfung wie eine Neueinstellung mit allen Passwörtern — und dieselbe Probezeit. Wenn die Publishing-Ebene darunter noch nicht feststeht: Unser Guide zur Auswahl eines Social-Media-Planers behandelt genau das für sich.