Neblla

Create a new Neblla app. Returns the app ID (appId) to use in subsequent file upload operations. Recommended flow for a NEW app: 1) Call neblla_validate_requirements with the decisions you can infer from the request — it walks the same decision map as the dashboard wizard; answer what you can yourself, ask the user only what it flags, repeat until have_enough_context. 2) Call neblla_get_llms to read the SDK reference (the core section at minimum). 3) Call neblla_create_app (this tool) with the display name AND the validated `decisions` — that scaffolds the matching pattern with a themed UI piece per enabled feature (login, store, AI box, friends, inbox…) and writes the full app config, so you only EDIT files instead of writing from scratch. Omit `decisions` only if you genuinely want a blank app (just index.html). 4) Edit/replace the scaffolded files (or upload new ones). The server-side files live under server/ — index.html references only main.css and client.js (NEVER the server/ files — the SDK loads them); client.js wraps code in window.onNeblla; the server/ files are top-level code with no DOM access; client and server communicate only via events (tellServer / tellPresenter / sendMessage / setState / on('messageToServer'|'messageFromServer'|'message'|'state')). 5) Call neblla_get_app_url(appId) to get the correct public URL — NEVER construct it manually. Apps are served at play.neblla.com/<slug>, not under any /apps/ path.

Create a purchasable product for a Neblla app. type must be "one_time" (single purchase, fixed price) or "consumable" (quantity selector, price per unit). name should be a multi-language object e.g. { en: "Gold Coins", es: "Monedas de Oro" }. price (one_time) and pricePerUnit (consumable) are in cents (e.g. 499 = $4.99).

For safety the MCP never deletes accounts directly. Returns a URL for the user to visit and confirm deletion from the Neblla dashboard.

Permanently delete an app and all its files.

Permanently remove a communication from a user's thread. The end user is notified via a `communicationDeleted` socket event so their UI updates in real time.

Delete a single file from an app.

Permanently delete a product from a Neblla app.

Returns the canonical public URL for a Neblla app in the gallery. ALWAYS call this after neblla_create_app — never construct the URL yourself. Apps are published and browsed at play.neblla.com. The URL format is https://play.neblla.com/<slug>, where <slug> is auto-generated from the app name at creation time and can be renamed in the dashboard.

Get the content of a specific file. Text files (HTML, CSS, JS, JSON, SVG, plain text) are ALWAYS returned as UTF-8 strings — never base64. Binary files (images, fonts, audio) are returned as base64. The response includes an `encoding` field ("utf8" or "base64") so you know how to interpret `content`. Always returns the real current source, including for apps you created or published in a previous session. Use this to resume editing an existing app across sessions. Large files are returned in CHUNKS — `content` may be only PART of the file. After each call, check `hasMore`: if true, call this tool again with `offset` set to the returned `nextOffset`, then concatenate the chunks in order. Decode (for binary) or edit only the FULLY reassembled string. `totalLength` is the total length of `content` across all chunks; `length` is this chunk's length.

Fetch the Neblla developer guide (llms.txt), split by topic so you read only what the app uses. Call this BEFORE designing or writing any code for a Neblla app — at minimum the `core` section (the default): the canonical six-file structure, the events-only client/server contract, and the five app patterns. Then fetch the sections matching the features you enabled: salas (rooms, lobby, matchmaking), servidor (the 3 server modes, setState, anti-cheat), identidad (login/SSO/scopes/save), social (friends + dev↔user communications), pagos (products/Stripe), ia (neblla.ai routes), publicar (gallery + quota table), referencia (the full API/events tables), mcp (this server's tools + creation flow), index (the table of contents), full (everything at once). Skipping core risks producing incorrect Neblla apps. Each response lists the available `sections`. Most sections fit in one response; for long ones check `hasMore` and re-call with `offset` = `nextOffset`, concatenating chunks in order. STALENESS CHECK — you connected to Neblla build 36. Each response carries the LIVE `latestBuild`. If `latestBuild` is greater than 36 (the build noted here), the server was redeployed AFTER you connected, so your loaded Neblla tool list is STALE. In that case, tell the developer plainly: "⚠️ The Neblla MCP updated to build <latestBuild> since this session started (you are on build 36). Restart/reconnect Claude Code to get the latest tools."

Fetch the full record of a single end user — their saved data, public info, purchases, and communications thread. Use the `_id` from neblla_list_users / neblla_search_users_by_email as `userId`.

List all apps owned by the authenticated developer.

List communications across ALL users of an app, filtered and sorted. The most useful tool for triaging an inbox: show only unread, only messages from users (not the dev), only flagged-important, or only those mentioning a given email. Returns flat items with userId so you can follow up via neblla_send_communication on each thread.

List all files staged for an app. Returns path, mimeType, size, and timestamps for each file.

List all products for a Neblla app.

List end users of an app — the people who connected through the SDK, NOT the developer's own account. Use this as the entry point for the backoffice flow: it returns a paginated list with each user's mongo `_id` (needed for every other backoffice tool), email, name, language, and stats. Pass `withCommunicationsOnly: true` to get only users who have communication threads — useful when triaging support.

Rename or move a file within an app. oldPath is the current path, newPath is the destination.

Publish a Neblla app to the public gallery. BEFORE calling this tool you MUST follow these steps with the user: 1) Ask for the app title and a short description (1-3 sentences) in the user's language. 2) Ask for the gallery section: "multiplayer" (games/apps where users interact in real time), "singleplayer" (games/tools for one person at a time), or "app" (everything else — utilities, tools, sites). 3) Ask for tags that describe the app (e.g. "puzzle", "multiplayer", "drawing"). 4) Ask what devices the app is best suited for: "mobile", "desktop", or omit for both. 5) Ask if the user wants to upload a cover image — pass an http(s) URL, a data: URI, or raw base64 JPEG/PNG. It will be auto-scaled to 400x400. 6) Provide the title and description in at least the user's language. You SHOULD also translate into other supported languages (en, es, fr, de, it, pt, ja, ko, zh, ar) for wider reach, but only the original language is required. Set defaultLang to the language the user originally provided the content in. titles and descriptions MUST each contain at least one entry in the same language.

Find users of an app by a partial email match (min 2 characters). Returns the matching user docs with email, communications, data, stats, and language. Use neblla_list_users for full pagination instead when no email is known.

Send a message from the developer to a specific end user. The user receives it live via the SDK's `communicationUpdated` event if connected, and on next reconnect otherwise. Optionally attach a `data` JSON payload (rendered by the app), or a calendar/appointment proposal via dateFrom/dateTo. Set `thread` to the id of an earlier communication to group replies. BEFORE calling: confirm the message wording with the developer (you are speaking to their users on their behalf).

Toggle the "important" flag on a communication. This is dev-only metadata and is NOT broadcast to the end user — use it to bubble messages to the top of your own triage view.

Mark a specific communication as read or unread (from the developer's side). The end user is notified live via a `communicationRead` socket event if connected.

Remove an app from the public gallery. The app keeps its files and URL — only its public listing is hidden. Use neblla_publish_app to re-publish.

Update an app's configuration. Pass only the fields you want to change. Use addDomain/removeDomain to mutate the allowed-origins list atomically without overwriting other entries. `sandbox: true` lets the app load on localhost / non-https origins for development. `ai` is the AI proxy config for the SDK's neblla.ai() — set { model, maxOutputTokens, userTokenMode, presets, limitsEnabled, tokensPerDay } or null to disable. userTokenMode is one of: 'off' (server uses dev key only), 'browser' (user key, browser-direct), 'server' (user key, server-side with private preset prefixes). presets is a {name: prefix} map of named prompt prefixes invoked via neblla.ai({preset:'name'}). limitsEnabled + tokensPerDay cap how many Claude tokens each end-user can spend per day; only applied when userTokenMode = off. `inbox: true` enables the in-app communications inbox feature for end users.

Update an existing product. Pass only the fields to change. Use this to adjust price, rename, or republish a product without losing its productId — changing the id would break checkout flows already wired into the app.

Replace the `data` object for a specific end user (the same object the SDK's neblla.save() reads/writes). Use sparingly: this overwrites the user's saved state and the change is broadcast live. Useful for support (unstuck a player), moderation (clear a corrupted save), or admin tooling. If the app has a "bring your own database" target configured, this writes there. Mongo-reserved keys (starting with $ or containing ".") are rejected; total JSON size is capped at ~100KB and 10 levels deep.

Upload or update a file for an app. Pass text files (HTML, CSS, JS, TS, JSON, SVG) as raw UTF-8 text with encoding="utf8" (the default) — do NOT base64-encode them, even if they contain quotes, backticks, ${...} or newlines; send the source verbatim. For binary files (images, fonts, audio, video) you have TWO options: (a) pass a public URL via `contentUrl` — Neblla downloads the bytes server-side (recommended: no need to spend tokens base64-encoding the file in this conversation), OR (b) pass a base64 string via `content` with encoding="base64". Always prefer `contentUrl` when you have one. Uploading the same path again overwrites the previous version. Canonical paths for a Neblla app are index.html, main.css, client.js (front-end) plus server/lobby.js, server/gathering.js, server/room.js (server-side). The server/ files are special: the SDK loads them itself and runs them in an isolated scope with no DOM access — never reference them from index.html, and never put DOM code or window.onNeblla in them (they must be top-level code where `neblla` is in scope as a global). client.js, by contrast, uses window.onNeblla = (neblla) => {…}. Communication between client.js and the server files is events-only (sendMessage / tellPresenter / tellServer / messageToServer / messageFromServer / setState / on('message')) — never direct function calls. All three server/ files run on the room's SERVER PEER (a device the SDK picks, never the presenter): server/lobby.js for the lobby (matchmaking); server/gathering.js while a non-lobby room is in 'gathering' state (decide when to call neblla.startRoom() to start the game); server/room.js post-startRoom (authoritative game logic — handle messageToServer, broadcast with sendMessage / setState).

Walk the SAME decision map the Neblla dashboard wizard uses, before creating an app. STRONGLY RECOMMENDED before neblla_create_app on any new-app request (skip it only for edits/fixes to existing code). It front-loads every structural decision so the app is born configured right. How to use it: pass the `decisions` you can already answer from the user's request. The tool returns every still-pending decision, each with `how_to_infer` (how to answer it YOURSELF from context) and `ask_user` (whether it deserves a question to the human). The contract: ANSWER EVERY DECISION YOU CAN YOURSELF — only surface the ones in `ask_user_questions` to the user, and only when you genuinely cannot infer them; ask them all in ONE message. Then call this tool again with the full set. When `have_enough_context` is true, pass the returned `decisions` straight to neblla_create_app({ name, decisions }) — it scaffolds the matching pattern + themed UI pieces and writes the app config in one go. `plan` previews exactly what that will build. Decision ids: kind (game|app), players (single|lobby-only|multi — single = one device; lobby-only = everyone in one shared space with no separate rooms; multi = separate rooms), structure (turn-based|host-controllers|collab-realtime; multi only), login/friends/purchases/ai/communications (booleans — the feature pieces), connections (all|p2p|server), serverMode (js|wasm), roomsPolicy (ephemeral|public|private|mixed), matchmakingMode (nocode|custom), aiPayer (off|browser|server; when ai is on), palette ({primary, secondary, alert} hex colors — PICK THEM YOURSELF to match the app's character), typography (modern|editorial|techy|serif|playful — pick it yourself too).