Vibo MCP

vibo-mcp

MCP server for Vibo (vibodj.com) — plan your event music as a host/couple. Browse your events and timeline, see and add song requests, like songs, manage notifications, and export selections to Spotify/Apple Music, all via natural language.

Developed and maintained by AI (Claude Code). Use at your own discretion.

Unofficial — not affiliated with Vibo. Works only with your own account/data.

Install

{

"mcpServers": { "vibo": { "command": "npx", "args": ["-y", "vibo-mcp"], "env": { "VIBO_EMAIL": "you@example.com", "VIBO_PASSWORD": "your_password" } } } }

Authentication

Choose one method:

The server boots without credentials; the config error only surfaces on the first tool call.

ContextMint Bridge (for SSO capture)

vibo_capture_session reads your signed-in tab through the ContextMint Bridge browser extension. Install it from github.com/nullnet-app/contextmint-bridge/releases:

• Chrome: download the Chrome zip, unzip it, and load it unpacked at chrome://extensions (Developer mode → Load unpacked).
• Safari: not available yet — it will ship inside the ContextMint app, which has no public download. Use Chrome for now.

Approve the pair code the extension shows on first use.

ContextMint Bridge is the fetchproxy browser extension under its new name, from the same maintainer — fetchproxy's own README (https://github.com/chrischall/fetchproxy#extension) points to it. Its source is public at https://github.com/nullnet-app/contextmint-bridge: build it yourself, or check a release zip against the .sha256 file published beside it (shasum -a 256 -c contextmint-bridge-chrome- .zip.sha256).

Uploads

vibo_set_profile_photo and photo/file answers to vibo_answer_question take each file one of three ways:

• A local path (local installs only). Files are read only from the upload directory — VIBO_UPLOAD_DIR, default ~/Downloads/vibo-mcp. Copy a file there before asking Claude to upload it. Hidden files and symlinks that lead outside the directory are refused. For a photo, the path you pass must be the file itself: any symlink is refused, even one pointing inside the upload directory. On a hosted deployment a path is refused, with a pointer to the routes below.
• Inline base64 (fileData, or images/files), for small files on any deployment. It is decoded strictly: truncated, mis-padded or otherwise malformed base64 is refused rather than sent as a corrupt file. A data: ;base64, prefix and line breaks are fine.
• An upload slot (hosted deployments with a blob store). Call vibo_upload_slots with the filenames, PUT each file to the signed URL it returns (its curl field is a ready command), then pass the blobKey (blobKey, or imageBlobKeys/fileBlobKeys). The stored copy is deleted only after Vibo accepts the upload, and the result reports it in blobCleanup. If the upload fails, the copy is kept so you can retry.

Every route is capped at 25 MiB. Photos must be real images (jpg/png/gif/webp/heic) by any route: the type must be an image type *and* the bytes must match it, so a renamed text file is refused. The confirmation preview shows each file's source, name, type, size and SHA-256. If the bytes change before you confirm, such as a different file at the same path or a re-uploaded slot, the confirmation is refused.

Timeline sections and limits

• vibo_create_section adds a section and can place it (afterSectionId or a 0-based position). The web app only appends new sections to the end. Visibility is host (default, "Me and DJ") or public (guests too).
• vibo_delete_section previews the section's name, its song count and its answered questions before deleting. It refuses the DJ's do-not-play list (dontPlay) and timeline dividers (headline) unless you pass force: true.
• vibo_reorder_sections moves one or more sections to directly after another section, or to the start. vibo_reorder_songs does the same for songs within a section.

Vibo's limits, checked before anything is sent:

A host can only do some things when the DJ's settings allow it: adding or reordering sections (event settings), or reordering one section's songs (that section's "hosts can order songs"). Vibo turns "hosts can order songs" off for every section a host creates, and only the DJ can turn it on. When a setting blocks you, the tool says which one instead of returning Vibo's bare "Action is not allowed for user".

Vibo doesn't store a section description set by a host, so vibo_create_section takes a note (for the DJ) instead.

Confirmations

Every write (adding or removing songs, comments, invites, exports, answers, uploads, …) is confirmed before anything is sent to Vibo.

A token works once, only for the tool and arguments it was previewed with: a changed argument or a reused token is refused and nothing is sent.

How it works

Vibo's app talks to a GraphQL API at https://api.vibodj.com/v2/graphql, authenticating with an x-token header obtained from an email/password signIn. This server reuses that same flow server-side (no browser needed) and wraps the host/couple operations as MCP tools. Every mutating tool asks you to confirm first: a client that can show a confirmation prompt (Claude Code) shows one (unless MCP_CONFIRM_ELICITATION=off); otherwise the first call makes no network call and returns a preview plus a confirmToken, and only a repeat call with that token makes the change (see Confirmations).

See docs/VIBO-API.md for the reverse-engineered API notes and skills/vibo-mcp/SKILL.md for the full tool list.

Upgrading

2.6.0 — upload previews. In a confirmation preview, willSend.photo (vibo_set_profile_photo) and each willSend.uploads[ ] (question answers) are now objects, not strings: {source, path?, blobKey?, filename, mimeType, sizeBytes, sha256}, where source is path, inline or blob. They used to be the path, or the string "(inline bytes)". A caller that displayed the old string should show filename (and path when present). The sha256 is what the confirm token is bound to.

Development

npm install

npm run build # tsc + esbuild bundle → dist/ npm test # vitest

License

MIT