Einen Assistenten einen Beitrag entwerfen zu lassen, ist einfach. Ihn veröffentlichen zu lassen, ist eine andere Entscheidung, und der interessante Teil ist nicht die Technik. Es ist das, was passiert, wenn er etwas falsch macht.
So funktioniert die Anbindung, und das solltest du entscheiden, bevor du sie herstellst.
Drei Wege, einen anzubinden
MCP, wenn der Agent ein Assistent wie Claude oder ein KI-fähiger Editor ist. Das Model Context Protocol ist die Art, wie diese Anwendungen mit externen Tools sprechen, und ein MCP-Server macht das Publishing als Tools verfügbar, die der Assistent direkt aufrufen kann. Das ist der geringste Aufwand: Server verbinden, und der Assistent kann im Gespräch Beiträge verfassen, planen und prüfen.
Ein API-Key, wenn du den Agenten selbst schreibst. Dein Code hält einen Schlüssel für dein eigenes Konto und ruft die API auf. Einfach, und richtig, wenn der Agent nur für dich handelt.
OAuth, wenn dein Produkt im Auftrag fremder Konten agiert. Jeder Nutzer autorisiert deine App, statt dir einen Schlüssel einzufügen. Baust du etwas für mehrere Nutzer, ist das die richtige Wahl, und eingefügte API-Keys sind ein Fehler, von dem du später wegmigrieren musst.
BulkPublish bietet alle drei: einen MCP-Server auf npm als @bulkpublish/mcp-server, API-Key-Authentifizierung und OAuth 2.1 für Apps, die für andere Nutzer handeln.
Entscheide zuerst über den Fehlerfall
Ein Agent, der für ein echtes Publikum veröffentlicht, kann auf eine Art falsch liegen, wie es ein Mensch meist nicht tut. Keine Tippfehler, sondern selbstsicher, plausibel, falsch. Eine erfundene Statistik in einem Beitrag liest sich exakt wie eine echte.
Die erste Entscheidung ist also keine technische. Es geht darum, was zwischen Erzeugung und Veröffentlichung passiert.
Entwurf als Standard. Der Agent erstellt Beiträge als Entwürfe, eine Person prüft, eine Person veröffentlicht. Das erhält alles Nützliche am Agenten und entfernt fast das ganze Risiko. Für die meisten ist das die richtige Einstellung, und sie wechseln nie davon weg.
Freigabe-Workflow. Der Agent reiht ein, eine benannte Person gibt frei. Dieselbe Idee mit einem Prüfpfad, was bei einem Team zählt.
Geplant mit Verzögerung. Der Agent plant für später statt sofort zu veröffentlichen, was ein Zeitfenster lässt, um Dinge abzufangen. Schwächer als eine Prüfung, weil es darauf vertraut, dass jemand hinschaut.
Direktes Veröffentlichen. Angemessen für eng umrissene, klar definierte Aufgaben, bei denen Inhalte nach Vorlage statt erzeugt werden: ein Status-Seiten-Update, eine Ankündigung eines neuen Releases aus einem Änderungsprotokoll. Viel weniger angemessen für alles, was Fließtext über dein Unternehmen von Grund auf schreibt.
Grenze den Zugriff ein
Gib dem Agenten den schmalsten Zugriff, der die Aufgabe erledigt.
- Getrennte Zugangsdaten, damit Agenten-Aktivität von deiner unterscheidbar und eigenständig widerrufbar ist
- Begrenzte Kanäle. Ein Agent, der an einem Konto arbeitet, sollte nicht alle erreichen können
- Die schmalsten Scopes. Muss er nur Beiträge erstellen, braucht er nicht, sie zu löschen
Der Grund, sich die Mühe zu machen, ist Widerruf. Geht etwas schief, willst du um zwei Uhr nachts genau eine Sache kappen, nicht den Schlüssel rotieren, den deine ganze Pipeline verwendet.
Die Schutzmaßnahmen, die sich lohnen
Lass ihn nie eine Zahl über dein Produkt behaupten. Preise, Plan-Limits und Funktionszahlen ändern sich, und ein Modell produziert bereitwillig eine plausible. Alles Faktische über dich sollte aus einer Quelle stammen, nicht aus Erzeugung.
Gib ihm deine echte Stimme. Ein Agent ohne Stilvorgabe erzeugt Text, der wie ein Agent klingt, was seine eigenen Reputationskosten hat.
Behalte das Volumen im Blick. Veröffentlichungs-Kontingente sind eine Absicherung gegen eine Endlosschleife, nicht nur ein Abrechnungstarif. Ein Agent in einer Wiederholungsschleife kann schnell viele Beiträge erzeugen.
Behalte für alles Sensible einen Menschen in der Schleife. Alles, was Nachrichten, Kontroversen oder eine Entschuldigung betrifft, ist nicht die Aufgabe eines Agenten.
So sieht das mit BulkPublish aus
- MCP-Server:
@bulkpublish/mcp-server, für Assistenten, die MCP sprechen - API: 59 dokumentierte Endpunkte für Beiträge, Planung, Medien, Kanäle, Labels, Analysen und Kontingente
- Auth: API-Key, oder OAuth 2.1 für das Handeln im Auftrag anderer Konten
- Plattformen: 15, sodass der Agent von einer Oberfläche aus überall veröffentlicht
| Free | Pro | Business | |
|---|---|---|---|
| API-Anfragen/Tag | 30 | 5.000 | 50.000 |
| API-Keys | 1 | 5 | 10 |
| Beiträge | 3/Tag | 30/Tag | Unbegrenzt |
Beiträge können als Entwurf statt veröffentlicht erstellt werden, das ist die Einstellung, mit der man anfangen sollte.
Die Kurzfassung
Verbinde per MCP für einen Assistenten, per API-Key für deinen eigenen Agenten, per OAuth, wenn du für andere handelst. Entscheide dann über den Prüfschritt, bevor du irgendetwas anderes entscheidest, halte Zugangsdaten getrennt und schmal, und lass ein Modell nie eine Tatsache über dein eigenes Produkt erzeugen. Entwurf-als-Standard kostet dich fast nichts und entfernt fast das ganze Risiko.