Zum Inhalt springen
BeeuniBeeuni
Deutsch
Esc
↑↓navigieren↵öffnen⌘Jvorschau
Auf dieser Seite

MCP サーバー

OAuth または個人用アクセストークンを使って、Claude、ChatGPT、Cursor、VS Code、Codex、その他の MCP クライアントを Beeuni に接続できます。1 つの URL で、開くことのできるすべてのプロジェクトにアクセスできます。インストールは不要です。

Experimentell. Die Tools können sich ohne vorherige Ankündigung ändern.

Beeuni hat einen gehosteten MCP-Server:

https://api.beeuni.ai/v1/mcp

Füge diese URL einmalig zu einem MCP-Client hinzu. Beim ersten Aufruf wirst du aufgefordert, dich im Browser bei Beeuni anzumelden. Danach handelt der Client in deinem Namen, mit deinen Berechtigungen und über alle Konten und Projekte hinweg, die du öffnen kannst – genau wie die CLI. Die URL gibt kein Projekt an: Die Tools erwarten ein project_id oder ein session_id, und list_projects führt sie auf. Es muss nichts installiert werden.

Zu einem Client hinzufügen

Bei allen folgenden Clients meldest du dich bei der ersten Verwendung mit OAuth an, sofern in den Schritten kein Token angegeben ist. Du musst nichts ersetzen: Die URL ist für alle Projekte dieselbe.

Claude Code

claude mcp add --transport http beeuni https://api.beeuni.ai/v1/mcp

Führe /mcp in Claude Code aus und melde dich an. Wenn du stattdessen ein persönliches Zugriffstoken verwenden möchtest, füge --header "Authorization: Bearer $BEEUNI_TOKEN" zum Befehl hinzu.

Claude Desktop und claude.ai

Settings → Connectors → Add custom connector. Füge die URL ein und melde dich an.

ChatGPT

Für benutzerdefinierte MCP-Connectoren ist der Entwicklermodus erforderlich. Aktiviere laut OpenAIs Anleitung zum Entwicklermodus den Developer mode unter Settings → Security and login. Erstelle anschließend auf der ChatGPT-Plugins-Seite (Plus-Schaltfläche) eine App im Entwicklermodus. Gib die URL ein und wähle die Authentifizierungsmethode OAuth. OpenAI führt die unterstützten Tarife und Menünamen auf; diese können sich ändern. Folge der Anleitung, falls eine Bezeichnung abweicht.

Cursor

Verwende in Connect MCP die Schaltfläche Add to Cursor oder füge den Server zu ~/.cursor/mcp.json (alle Projekte) oder .cursor/mcp.json (ein Projekt) hinzu:

{ "mcpServers": { "beeuni": { "url": "https://api.beeuni.ai/v1/mcp" } } }

VS Code

Füge den Server zu .vscode/mcp.json hinzu. VS Code verwendet servers, nicht mcpServers, und benötigt type:

{ "servers": { "beeuni": { "type": "http", "url": "https://api.beeuni.ai/v1/mcp" } } }

Codex

codex mcp add beeuni --url https://api.beeuni.ai/v1/mcp
codex mcp login beeuni

Oder bearbeite ~/.codex/config.toml. Für ein persönliches Zugriffstoken gib die Umgebungsvariable an, die es enthält:

[mcp_servers.beeuni]
url = "https://api.beeuni.ai/v1/mcp"
bearer_token_env_var = "BEEUNI_TOKEN"

Andere Clients

Füge einen Remote-MCP-Server (Streamable HTTP) mit dieser URL hinzu. Wenn ein Client kein OAuth unterstützt, sendet er ein persönliches Zugriffstoken als Header (siehe unten).

Öffne das Workspace-Menü (den Projektnamen oben links) und wähle Connect MCP, um die URL und die Schritte für Claude, Claude Code, Cursor und Codex zu kopieren.

Anmeldung

Der Server verwendet den in der MCP-Spezifikation definierten OAuth-2.1-Ablauf. Ein Client führt ihn ohne Konfiguration durch:

  1. Ein Aufruf ohne Token liefert 401 mit WWW-Authenticate: Bearer resource_metadata="…", scope="beeuni" zurück.
  2. Der Client liest das RFC-9728-Dokument unter /.well-known/oauth-protected-resource/v1/mcp. Darin ist Beeuni als Autorisierungsserver angegeben.
  3. Der Client registriert sich unter POST /v1/oauth/register (RFC 7591). Er erhält eine öffentliche Client-Registrierung, die sich ausschließlich mit PKCE authentifiziert.
  4. Du genehmigst den Client auf dem Beeuni-Zustimmungsbildschirm. Ein selbst registrierter Client wird als Unverified app gekennzeichnet und zeigt den Host an, zu dem er dich zurückleitet. Genehmige ihn nur, wenn du ihn selbst verbindest.
  5. Der Client tauscht den Code gegen ein beeuni_oat_-Zugriffstoken (1 Stunde) und ein Refresh-Token (30 Tage, wird bei Verwendung erneuert). Läuft das Zugriffstoken ab, erneuert der Client es, ohne dich erneut zu fragen.

Client widerrufen

Unter Settings → Personal access keys → Connected apps werden alle Apps aufgeführt, die du für deine Konten genehmigt hast: ihr Name, wo sie sich anmelden und wann sie zuletzt aktiv waren. Ein selbst registrierter MCP-Client ist als Unverified app gekennzeichnet. Mit Revoke access löschst du deine Genehmigung und widerrufst die Tokens: Die nächste Anfrage schlägt fehl, und der Client muss erneut um deine Genehmigung bitten. Im Terminal: beeuni tokens apps ls und beeuni tokens apps rm <client-id>. Beide funktionieren nur über eine Browsersitzung oder ein persönliches Zugriffstoken, niemals mit dem eigenen Token einer App.

Was eine verbundene App nicht kann

Der Bereich beeuni lässt eine verbundene App in deinem Namen handeln: Sie kann lesen und ändern, was auch du lesen und ändern kannst. Sie kann keine Zugangsdaten erstellen, die länger als ihr eigenes widerrufbares Token gültig sind. Bei einem beeuni_oat_-Token antworten diese Routen mit 403:

  • persönliche Zugriffstoken (POST /v1/accounts/tokens) und Projekt-CLI-Token;
  • Gateway-Schlüssel;
  • SCIM-Token;
  • OAuth-Clients und die Erneuerung ihrer Secrets;
  • Dienstkonten;
  • die Liste verbundener Apps und deren Widerruf (/v1/oauth/grants).

Widerrufst du einen Client, endet sein Zugriff. Ein persönliches Zugriffstoken ist etwas anderes: Es läuft nicht ab, sofern du --expires nicht angibst, und durch den Widerruf einer App wird es nicht widerrufen.

Persönliches Zugriffstoken

Ein Client ohne OAuth oder ein Skript sendet stattdessen ein beeuni_pat_-Token – dasselbe Token, das die CLI verwendet. Erstelle eines mit beeuni tokens new <name> oder unter Settings → Personal access keys und sende es dann als Header:

{ "mcpServers": { "beeuni": { "url": "https://api.beeuni.ai/v1/mcp", "headers": { "Authorization": "Bearer beeuni_pat_…" } } } }

Tools

tools/list gibt 23 Tools zurück. Mit * markierte Parameter sind erforderlich.

Tool Parameter Beschreibung
list_projects keine Listet alle Projekte auf, die du in all deinen Konten öffnen kannst, einschließlich project_id und deiner Rolle.
start_session project_id, prompt, name, agent Startet eine Sitzung in einem Projekt mit einem ersten Prompt. Gibt die session_id zurück.
send_message session_id, text Stellt eine Nachricht für eine Sitzung in die Warteschlange und startet die Sitzung, falls sie angehalten ist.
read_session session_id*, limit, wait_seconds Gibt den Status einer Sitzung zurück, ob ihr Durchlauf idle, booting, running oder queued ist, sowie ihre neuesten Nachrichten mit Eingabe und Ausgabe jedes Tool-Aufrufs. limit beträgt standardmäßig 10, maximal 100. wait_seconds (bis zu 45) wartet, bis der Durchlauf beendet ist.
list_sessions project_id*, limit, cursor Listet die Sitzungen auf, die du in einem Projekt sehen kannst: ID, Titel, Status, Agent, Besitzer, Branch und Datumsangaben. limit beträgt standardmäßig 20, maximal 200.
run_command session_id*, command, cwd, timeout_seconds, job_id, cancel Führt einen Bash-Befehl in der Sandbox einer Sitzung aus und gibt stdout, stderr und den Exit-Code zurück. Bei einem lang laufenden Befehl wird ein job_id zurückgegeben, mit dem du weiter warten kannst.
read_file path*, session_id, project_id, ref, offset, limit Liest eine Datei aus der Sandbox einer Sitzung oder aus dem Git-Repository eines Projekts unter ref. Bilder werden als Bilder zurückgegeben.
write_file session_id, path, content*, encoding Schreibt eine Datei in die Sandbox einer Sitzung und erstellt die übergeordneten Verzeichnisse. encoding ist utf8 (Standard) oder base64.
list_files path, session_id, project_id, ref, offset Listet ein Verzeichnis in der Sandbox einer Sitzung oder alle Dateien des Repositorys eines Projekts unter einem Pfad auf.
read_skill name, file, project_id Listet die Anleitungen der Beeuni-Plattform auf oder gibt eine Anleitung (name) oder eine ihrer Referenzdateien (file) zurück. Mit project_id werden zuerst die projektspezifischen Skills aufgelistet; ein Projekt-Skill name gibt seine SKILL.md und die Pfade seiner Referenzdateien zurück.
list_connectors project_id*, connector Listet die Connectors eines Projekts auf: Slug, Anbieter, ob jeder connected ist (also derzeit von dir genutzt werden kann), Anzahl der Aktionen und Konten. Mit connector werden alle Konten dieses Connectors aufgelistet.
search_connector_actions project_id*, query, connector, limit Sucht anhand der Absicht nach Connector-Aktionen. Gibt tool (<connector>.<action>), risk und eine einzeilige Beschreibung zurück. Gibt niemals Schemas zurück.
describe_connector_action project_id, tool Gibt das JSON-Schema der Eingabe, das Risiko und die Beschreibung einer Aktion zurück.
call_connector project_id, tool, args, account, reason Führt eine Aktion in deinem Namen aus. Gibt die Daten und account zurück, der sie ausgeführt hat, ein Ergebnis vom Typ pending_approval mit dem Genehmigungslink oder eine Ablehnung mit Begründung.
upload_connector_attachment project_id, connector, filename*, content_base64 oder session_id + path Stellt eine Datei bereit und gibt die {"$beeuni_attachment": "<id>"}-Referenz zurück, die in args einzutragen ist.
connect_connector project_id, connector, owner, label Gibt den Link zurück, den eine Person öffnet, um das Konto des Connectors zu verbinden.
search_connector_apps project_id, query, limit, cursor Durchsucht den Katalog verwalteter Apps, über den ein Connector hinzugefügt werden kann.
add_connector project_id*, app oder provider + slug, name, url, transport, endpoint, spec, base_url Fügt einen Connector sofort zum Projekt hinzu (wird auf main in beeuni.yaml übernommen und anschließend synchronisiert).
remove_connector project_id, connector Entfernt einen Connector aus dem Projekt.
beeuni args*, project_id, session_id Führt die echte beeuni-CLI in deinem Namen aus und gibt exit_code, stdout (oder json bei --json-Ausgabe) sowie stderr zurück. Siehe Beliebigen CLI-Befehl ausführen.
search_api query*, limit Durchsucht die Beeuni-API-Routen nach Schlüsselwörtern.
describe_api method, path Gibt die Parameter, den Request-Body und das Response-Schema einer Route zurück.
call_api method, path, project_id, query, body Ruft eine beliebige /v1/-Route in deinem Namen auf. project_id füllt {projectId} im Pfad aus.

search_api, describe_api und call_api bieten alle Funktionen der Web-App und der CLI, da beide Clients derselben API sind. call_api weist /v1/oauth/* und alle Pfade zurück, die zu einem MCP-Endpunkt führen. Fülle alle anderen {placeholder} im Pfad selbst aus. Für jeden Aufruf gelten dieselbe autorisierung und dasselbe Audit wie für eine Anfrage aus der Web-App. Im Audit wird jeder Aufruf mit credential_kind: "oauth_app" und dem Namen der verbundenen App erfasst, da die API die authentifizierte Anmeldeinformation protokolliert, nicht eine vom Client übermittelte Bezeichnung.

Beliebigen CLI-Befehl ausführen

Das Tool beeuni führt die echte beeuni-CLI in deinem Namen aus. Jeder CLI- Befehl funktioniert darüber, sodass der MCP-Server denselben Zugriff wie ein Terminal hat: Secrets, Trigger, cr, review, Erinnerungen, Agents, Modelle, Gateway, Anbieter, Channels, Sandboxes, Apps, Marketplace, Dateien, Zugriff, Rollen, Berechtigungen, Audit, Freigaben, Mitglieder, Gruppen, Tokens, Abrechnung, Projekte, Sitzungen und system-skills. Ein Tool ersetzt etwa 200 Unterbefehl-Tools, die das Tool-Limit von Clients wie Cursor überschreiten würden.

args ist das argv nach beeuni, mit einem Array-Element pro Argument. Es ist niemals eine Shell-Befehlszeile.

{ "name": "beeuni", "arguments": { "args": ["--help"] } }
{ "name": "beeuni", "arguments": { "args": ["secrets", "ls", "--json"], "project_id": "<project_id>" } }
{ "name": "beeuni", "arguments": { "args": ["triggers", "ls", "--json"], "project_id": "<project_id>" } }
{ "name": "beeuni", "arguments": { "args": ["system-skills"] } }
  • Entdecke Befehle mit ["--help"] und ["<group>", "--help"]. Füge --json zu den Ausgaben hinzu, die du verarbeitest.
  • project_id legt das Projekt für einen projektbezogenen Befehl fest. session_id legt die Sitzung für einen Befehl fest, der auf eine Sitzung angewendet wird.
  • Das Ergebnis ist JSON: exit_code, stdout, stderr. Mit --json wird die Befehlsausgabe als JSON-Wert in json statt in stdout übermittelt. Ausgaben, die nicht hineinpassen, werden abgeschnitten und mit truncated markiert; abgeschnittenes JSON ist ungültig, daher sollte der Befehl eingegrenzt werden. Ein von null verschiedener exit_code ist ein MCP-Fehler. Jeder Stream wird bei 24.000 (stdout) bzw. 8.000 (stderr) Zeichen abgeschnitten. Das Ergebnis weist in truncated darauf hin.
  • Ein Befehl, der länger als etwa 45 Sekunden läuft, wird beendet. Das Ergebnis enthält timed_out.
  • Der Server führt höchstens 4 CLI-Befehle gleichzeitig aus. Ein fünfter Aufruf gibt Busy zurück: erneut versuchen.
  • Für Sitzungen, Sandbox-Dateien und Connectors gibt es eigene Tools (start_session, run_command, read_file, call_connector). Verwende bevorzugt diese.

Die CLI wird auf dem Server mit deinem eigenen Token und gegen diese API ausgeführt. Sie erhält keine Server-Anmeldedaten: Ihre Umgebung enthält nur dein Token, die API-URL, die Projekt- und Sitzungs-IDs sowie ein leeres temporäres Home- und Arbeitsverzeichnis. Der Server entfernt beides nach dem Befehl. Für Autorisierung und Audit ist die API zuständig: Das Token eines Außenstehenden erhält dieselbe 403 wie bei einer Ausführung im Terminal.

Diese Befehle werden abgewiesen, bevor etwas ausgeführt wird. Die Fehlermeldung nennt den Grund und die Alternative.

Befehl Warum Stattdessen verwenden
beliebiges --host- oder --host=-Flag, hosts Verweist die CLI auf einen anderen Server und würde dein Token dorthin senden. Dieser Server handelt bereits in deinem Namen.
login, logout Browser-Anmeldung und gespeicherte Tokens. Du bist über die MCP-Verbindung angemeldet.
init, ship, deploy Ein lokales Verzeichnis lesen oder beschreiben. run_command in einer Sitzungssandbox, in der sich der Quellcode befindet.
tools Liest und bearbeitet eine lokale beeuni.yaml, und auf dem Server gibt es keinen Projekt-Checkout. run_command in einer Sitzungssandbox: Führe dort beeuni tools ls aus.
apps deploy Stellt ein lokales Verzeichnis bereit, das auf dem Server nicht vorhanden ist. run_command in einer Sitzungssandbox: Führe dort beeuni apps deploy <path> aus.
env pull, env push Eine lokale Datei schreiben oder lesen. secrets ls, secrets set KEY=value.
token, whoami --token-only Gibt das rohe Zugriffstoken aus. whoami --json.
update, uninstall Ändert den Rechner, auf dem die CLI ausgeführt wird. Keines.
tui, t, connect, attach, `sessions connect shell forward`
chat und sessions chat ohne --prompt Öffnet einen interaktiven Chat. start_session, send_message oder --prompt "<text>" hinzufügen.

Das Audit protokolliert einen CLI-Befehl mit denselben Anmeldedaten wie alle anderen Aufrufe über die Verbindung (credential_kind: "oauth_app"). Es kann das Tool beeuni nicht von call_api unterscheiden: Beide greifen mit deinem Token auf die API zu.

Projekt-Skills

read_skill mit einem project_id listet die projektspezifischen Skills auf (die skills/<slug>/SKILL.md-Dateien des Repositorys oder das ältere .beeuni/opencode/skills/), bevor die Plattformleitfäden angezeigt werden. Übergib den Skill-name, um dessen SKILL.md und die Pfade seiner Referenzdateien zu lesen, und file, um eine Referenz zu lesen. Du siehst die Skills, die für deine Rolle und Berechtigungen verfügbar sind.

Deine Konnektoren verwenden

Die Konnektor-Tools sind die beeuni connectors CLI als MCP-Tools. Sie rufen dieselben API-Routen auf wie die CLI und das SDK. Daher verhalten sich Konnektorrichtlinien, Genehmigungen und Audits auf allen Oberflächen gleich.

  1. list_connectors zeigt, was verbunden ist. Mit einem Konnektor mit connected: false lassen sich keine Aktionen ausführen: Rufe connect_connector auf, öffne den zurückgegebenen Link und rufe dann die Liste erneut ab.
  2. search_connector_actions sucht anhand der Absicht nach einer Aktion, zum Beispiel send an email. describe_connector_action gibt die Argumente zurück.
  3. call_connector führt die Aktion aus. Das Ergebnis nennt das account, das den Aufruf ausgeführt hat. Bei einem Konnektor mit mehreren Konten und ohne Standardkonto ist account erforderlich.
  4. Übergib reason bei einem Schreibvorgang, dessen Argumente nur IDs sind (send_draft, Löschen anhand der ID). Die genehmigende Person sieht es neben den tatsächlichen Argumenten.

Eine Richtlinie kann einen Aufruf zur Genehmigung zurückhalten. call_connector gibt dann status: "pending_approval" mit einem approval_url zurück. Eine Person öffnet den Link und genehmigt den Aufruf. Rufe innerhalb von 15 Minuten dasselbe Tool mit denselben Argumenten und demselben Konto erneut auf: Der genehmigte Aufruf wird einmal ausgeführt. Eine Ablehnung mit policy_block ist endgültig.

Ein Ergebnis mit mehr als etwa 40.000 Zeichen wird als markierte Vorschau zurückgegeben (data_truncated). Schränke die Argumente ein und rufe das Tool erneut auf. Um eine Datei anzuhängen, bereite sie mit upload_connector_attachment vor und übergib den zurückgegebenen Verweis in args. Connectoren mit dem Provider composio akzeptieren keine Verweise auf Anhänge.

Ergebnisgröße und Seitennavigation

  • Ein Tool-Ergebnis wird nach 60.000 Zeichen abgeschnitten und endet mit …[truncated at 60000 chars].
  • read_file gibt eine lange Textdatei seitenweise mit jeweils bis zu etwa 50.000 Zeichen zurück. Ein abgeschnittenes Ergebnis endet mit dem offset, mit dem du fortfahren kannst. offset überspringt Zeilen und limit begrenzt die zurückgegebenen Zeilen. Eine Binärdatei wird nicht als Text zurückgegeben: Lies sie mit run_command.
  • list_files schneidet eine lange Liste auf dieselbe Weise ab. Übergib das offset, das es nennt.
  • list_sessions gibt next_cursor zurück, wenn weitere Sitzungen vorhanden sind. Übergib es erneut als cursor.
  • read_session gibt die neuesten limit Nachrichten zurück. Es schneidet jede Tool-Ein- und -Ausgabe ab und entfernt die ältesten Nachrichten, wenn das Ergebnis nicht hineinpasst (omitted_older). last_turn_error benennt einen fehlgeschlagenen Durchlauf.
  • Eine MCP-Anfrage wird innerhalb von 55 Sekunden beantwortet. Sowohl read_session mit wait_seconds als auch eine noch startende Sandbox werden vorher beendet: Rufe es erneut auf.

Sandboxes

run_command, read_file, write_file und list_files mit einem session_id greifen auf die aktive Sandbox der Sitzung zu, genau wie das Web-Terminal und das Dateifenster. Relative Pfade werden unter /workspace aufgelöst, dem Git-Checkout der Sitzung. Eine gestoppte Sandbox wird beim ersten Aufruf gestartet. Die beeuni-CLI in der Sandbox ist als Sitzung angemeldet. Mit einem project_id und ohne session_id lesen read_file und list_files das Git-Repository des Projekts und starten keine Sandbox.

Ein Befehl kann mehrere Minuten laufen. Ein Tool-Aufruf wartet etwa 50 Sekunden. Wenn der Befehl dann noch läuft, gibt run_command status: running, ein job_id und die bisherige Ausgabe zurück. Rufe run_command mit diesem job_id auf, um weiter zu warten, oder mit cancel: true, um den Befehl zu beenden. timeout_seconds (Standardwert 600, Maximum 86400) beendet einen zu lange laufenden Befehl mit dem Exitcode 124. Die Ausgabe bleibt in ~/.cache/beeuni-mcp/jobs/<job_id>/ in der Sandbox erhalten; ein Tool-Ergebnis zeigt die letzten 24.000 Bytes jedes Datenstroms. Wenn eine Sandbox stoppt, werden auch alle darin laufenden Befehle beendet.

Der Server ist zustandslos: Er beantwortet POST mit JSON und GET und DELETE mit 405.

War diese Seite hilfreich?