Website Host

Verbindungsdaten

{
  "name": "RTK Website Host",
  "server_url": "https://host.kuble.ai/mcp",
  "authentication": "No authentication"
}

Instruktionen fuer LLMs

Diese Regeln werden verbundenen LLMs auch direkt ueber MCP als Server-Instruktionen mitgegeben.

RTK Website Host MCP build contract:

Base domain: host.kuble.ai
Users choose only a slug such as "meinprojekt". The resulting training subdomain is always <slug>.host.kuble.ai, for example meinprojekt.host.kuble.ai. Never tell users that training sites are under *.kuble.com or <slug>.kuble.com. Do not include the base domain in the slug argument.
Use the returned url/full_domain as the website address. Do not give users /s/<slug>/ preview URLs; those are local-development previews only and are disabled on the production host.

CRITICAL existing-site workflow: if the user says they already have a site and want to continue/edit/work on it from this LLM or computer, do NOT ask for the old site_token and do NOT ask for the original voucher. Use continue_site if available. First call continue_site with slug and editor_email to request an emailed EDIT-... code. When the user gives the EDIT-... code, call continue_site again with slug and editor_code to receive a fresh site_token. If continue_site is not available but claim_subdomain is available, use claim_subdomain fallback: code="REQUEST_EDITOR_ACCESS", slug=<site slug>, owner_label=<editor email>; then claim_subdomain again with code=<EDIT-code>, same slug, owner_label="MCP session".

1. Start question: before claiming or building, ask whether the site should be public ("everyone can view it") or protected ("only allowed emails can view it"). Also ask for one or more editor email addresses so the user can reconnect from another LLM or computer later. If protected, ask for one or more allowed viewer email addresses before calling claim_subdomain.
2. Registration: call claim_subdomain directly with the one-time voucher code or admin-created permanent creator token, wanted slug only, site_visibility, allowed_emails when protected, and editor_emails. check_subdomain is optional only. claim_subdomain validates the code/token and subdomain availability again. After claim, use the returned full_domain/url as the only source of truth for the final domain.
3. Do not publish without a site_token. Keep the site_token private in the chat context. Never write it into HTML, CSS, JS, database rows, logs, public text, or form data.
4. Reconnect flow: if the user already has a site but this chat has no site_token, ask for the slug and their editor email. Prefer continue_site. Otherwise call request_site_editor_access. Ask the user to copy the code from the email. Then call continue_site with editor_code or redeem_site_editor_code and use the returned fresh site_token.
4a. Reconnect fallback: if this MCP client does not expose continue_site, request_site_editor_access, or redeem_site_editor_code but does expose claim_subdomain, use claim_subdomain as the compatibility path. First call claim_subdomain with code="REQUEST_EDITOR_ACCESS", slug set to the site slug, and owner_label set to the editor email. After the user gives you the emailed EDIT-... code, call claim_subdomain again with code set to that EDIT-... code, the same slug, and owner_label="MCP session". This returns a fresh site_token for the existing site; it does not claim a new site.
5. Editor management: if the user wants future access from another LLM/computer, configure editor emails with configure_site_editors. Use get_site_editors to review them. Removing an editor email revokes extra editor tokens for that email.
6. First full publish: call publish_site with replace=true. Include at minimum index.html. Prefer a clean structure: index.html, assets/styles.css, assets/app.js, favicon.svg.
7. Favicon: every published site should include a favicon. If the user does not provide one, create a simple SVG favicon as favicon.svg and link it from index.html with <link rel="icon" href="favicon.svg" type="image/svg+xml">. Use relative paths so preview and live domain both work.
8. Images and assets: do not rely on transferring files from Code Interpreter or sandbox storage into MCP. For icons, logos, patterns, charts, and simple illustrations, create SVG/CSS/text assets directly with publish_site. For photos or binary assets that already have a public URL, call import_asset_from_url and save them under assets/... . If a file exists only as a local Code Interpreter artifact and has no public URL, explain that limitation and ask the user for a public URL or use a text/SVG alternative.
9. Website quality: create responsive, accessible HTML with viewport meta tag, title, visible focus states, useful empty/success/error states, and no broken placeholder links. Avoid external CDNs unless the task clearly requires them.
10. Databases: create_database first, then create_table. Database/table names must start with a letter and use lowercase letters, numbers, and underscores. Column names must start with a letter; allowed types are string, number, boolean, date, json.
11. Public database access from the website: for frontend reads set public_read=true; for public forms set public_insert=true. Frontend endpoints are relative to the site: GET /_db/{database}/{table}?limit=50&field=value and POST /_db/{database}/{table} with JSON. Never expose site_token in frontend code. On protected sites, these endpoints require an allowed magic-link session.
12. Forms: if creating a contact/signup/lead form, create the database/table first, publish JS that POSTs JSON to /_db/{database}/{table}, validate inputs, and show a clear success or error message.
13. Login/auth: if the user asks for login, members, private area, account, or magic link, use the built-in site auth endpoints. Do not set up Resend, OAuth, API keys, SMTP, or external auth. The host sends magic-link emails. Frontend endpoints: POST /_auth/request with { "email": "...", "redirect_path": "/" }, GET /_auth/me, POST /_auth/logout. The email link is handled by /_auth/verify and sets an HttpOnly session cookie.
14. Auth/access UX: for protected sites, the host automatically shows a login page before serving HTML, assets, and public database endpoints. For custom login UI, build a login form that calls /_auth/request, show "check your email", then use /_auth/me on page load to show logged-in state. Do not expose tokens.
15. Custom domains: if the user wants a real domain such as example.com or app.example.com, call start_custom_domain_setup and show the DNS records exactly. The user must create DNS records at their DNS provider unless they have a separate DNS-provider tool/connector. Then call check_custom_domain_dns. Only call activate_custom_domain when DNS is ready. For www.example.com and example.com, set up each domain separately.
15a. Kuble internal domains: direct subdomains of kuble.com, for example felix.kuble.com, are reserved for Kuble users only. They are allowed only when the site has at least one editor email ending in @kuble.com. Apex kuble.com, reserved names such as www/v3/host/mail, and nested names such as a.b.kuble.com remain blocked. For approved kuble.com subdomains, show the A record target exactly.
16. Checkpoints: before risky edits, full redesigns, database migrations, or deleting files, call create_checkpoint with a short description. Use list_checkpoints when the user asks what can be restored. Use restore_checkpoint only when the user asks to go back; it replaces current files and JSON databases with the snapshot. Each site keeps at most 3 checkpoints, and a new fourth checkpoint removes the oldest.
17. Updates: use list_files/read_file before partial edits when preserving existing work. Use replace=true only for an intentional full replacement.
18. Error handling: if claim_subdomain returns voucher_code_not_found, voucher_code_already_used, voucher_code_expired, permanent_token_revoked, permanent_token_expired, or subdomain_already_claimed, explain the issue and ask for a new code/token or slug instead of guessing. If redeem_site_editor_code returns invalid_editor_access_code, ask the user to request a fresh code.

Start-Prompt

Diesen Text kannst du nach dem Verbinden in ChatGPT oder Claude verwenden:

Nutze RTK Website Host.
Mein Code ist RTK-ABCD-2345.
Ich moechte die Subdomain meine-seite.
Meine Editor-E-Mail ist person@example.com.
Frage mich zuerst, ob die Website public oder geschuetzt sein soll. Wenn geschuetzt, frage nach den erlaubten E-Mail-Adressen.
Registriere sie danach direkt mit claim_subdomain, merke dir das site_token und publiziere eine einfache Website mit Startseite, CSS und Kontaktformular.
Erstelle ausserdem eine Datenbank main mit einer Tabelle leads.

Reconnect-Prompt

Diesen Text kannst du in einem neuen LLM verwenden, wenn die Site schon existiert:

Nutze RTK Website Host.
Ich habe bereits die Subdomain meine-seite.
Ich bin mit person@example.com als Editor freigeschaltet.
Fordere bitte einen Editor-Code an. Wenn ich dir den Code aus der E-Mail gebe, loese ihn ein und arbeite danach mit dem neuen site_token weiter.

Offizielle Hilfe

ChatGPT Developer Mode und MCP Apps
Claude Custom Connectors mit Remote MCP