hosting
Dplooy turns an AI assistant into a publishing tool.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeCan modify data
What it can do
- Deploy Website: NEW SITE? STOP — run the BUILD ORDER first (get_account → ask single-file vs multi-page + notification emails → create_data_collection for EVERY repeating section → create_form / creat
- List Projects: List all your deployed projects on Dplooy. Shows name, URL, type, size, views, and status.
- Get Project: EDITING A SITE? Call this FIRST — the inventory of everything attached: forms, Data collections (prerendered vs client-only), booking pages, chatbot, with ids and keys, plus an SEO warnin
What data it sees
Do you need an account
No: the server works without sign-in
Dplooy turns an AI assistant into a publishing tool. Ask Claude or ChatGPT to build a site and it goes live on a real URL in seconds — no build step, no repository, no deploy config.
It is not limited to static pages. The same connector creates a working contact form with a submissions inbox and email notifications, editable content collections your site reads at runtime (services, menu, team, FAQ, pricing — edit them in the dashboard and the live site updates without a redeploy), an approval- based booking calendar with time-zone handling, hosted media, and an AI chatbot that answers from a knowledge base about the business.
Connect with one URL over OAuth — nothing to install and no key to copy. A local npm package is also available for MCP clients that can read your disk, which adds deploying a folder you already have locally.
Free plan includes three projects. No credit card required to try it.
Server tool list (29)
Raw names from tools/list. Only developers need these.
| deploy_website | NEW SITE? STOP — run the BUILD ORDER first (get_account → ask single-file vs multi-page + notification emails → create_data_collection for EVERY repeating section → create_form / create_booking_page → upload_media → THEN deploy). Deploys ONE self-contained HTML file (markup, Tailwind CDN classes, small JS in index.html; optional css/js). Hardcoded list content that belongs in Data is a BROKEN build. After deploy: assign_to_project, configure_chatbot, and ALWAYS hand the user the complete site code in your own interface — deploying alone is not the deliverable. get_guide("workflow") has the full rules. Returns a live URL; reusing a project name redeploys it in-place. |
| list_projects | List all your deployed projects on Dplooy. Shows name, URL, type, size, views, and status. |
| get_project | EDITING A SITE? Call this FIRST — the inventory of everything attached: forms, Data collections (prerendered vs client-only), booking pages, chatbot, with ids and keys, plus an SEO warning when Data is loaded by browser fetch() only. Never infer attachments from the HTML or the live URL. |
| get_project_files | BEFORE ANY EDIT: read the CURRENT LIVE FILES of a deployed Dplooy project — the clean stored source, the ONLY source of truth for edits. Never scrape the site URL instead: served pages contain Dplooy-injected runtime (chatbot, badge, analytics) that is not part of the source. Call this BEFORE editing an existing site — edit against what is actually stored, never from memory (your memory of the site may be stale or from another conversation). Returns the full file inventory plus the text contents (HTML/CSS/JS). Use listOnly first on large sites, then fetch specific paths. After reading, make changes with update_project_files targeted edits ({ path, oldString, newString }) — never re-emit whole files for small changes, and never full-redeploy to edit (a redeploy replaces the whole site and deletes omitted files). Assigned forms, data, bookings and chatbot survive all edits unchanged. |
| update_project_files | EDIT a deployed site — call get_project_files first, never edit from memory. PREFERRED: targeted edits ({ path, oldString, newString }) — you send only the changed text, and the server verifies oldString against the ACTUAL live file (exactly one match required), so a stale copy can never overwrite anything. Use files (full content) only for rewrites or new files, deletePaths for removals. Every file you do NOT name is guaranteed untouched — deletions never happen by omission. All-or-nothing: any failed match or invalid path rejects the whole patch with nothing changed. Text files only (HTML/CSS/JS) — images live in the Media Library. Single-file projects accept edits to their one file (path "/"); adding/deleting files is multi-file only. |
| delete_project | IRREVERSIBLE — confirm with the user first. Permanently deletes a deployed project: all files, analytics, and the subdomain. Forms, Data collections and booking pages attached to it are NOT deleted — they are un-assigned and kept. This action cannot be undone. |
| get_account | Call this FIRST on every build — the plan, usage, limits and FEATURES MATRIX (forms, data, bookings, chatbot, media) and how much of each is left; design only within it. Also lists unassigned leftovers to reuse before creating new ones. |
| get_guide | Get the full canonical guide for how a Dplooy feature works — rules, schemas, plan limits, and embed contracts. Call this BEFORE using a feature for the first time. Topics: workflow (the full build order), forms, data, bookings, chatbot, media, limits. |
| create_form | Create a form endpoint BEFORE deploying (Plus/Pro). Returns the URL + the exact HTML snippet to embed verbatim. Inert until assign_to_project after deploy; movable and un-assignable later, submissions stay with it. Retrying the same name while it is still unassigned returns the existing endpoint instead of a duplicate. Submissions are READ in the owner's dashboard only — no tool reads them (by design: visitor PII). Name it "<Business Name> — <Purpose>". |
| get_form | Read one form endpoint: URL, assignment, active/paused, submission COUNT, notification email, confirmation message, origin rule, and the embed snippet. Submissions themselves are dashboard-only (visitor PII) — this never returns them. |
| list_forms | List your Dplooy Forms endpoints with usage. Shows which are assigned to projects and which are still inert. |
| create_data_collection | EVERY repeating content section (services, features, testimonials, FAQ, pricing, team …) goes in a collection — NOT optional. Create them (all plans) BEFORE deploying: editable content the site embeds with declarative markup (server-prerendered for SEO, kept live by the hosted runtime). Each section of ANY site (services, features, testimonials, FAQ, pricing, team …) belongs in a collection so the owner can edit content from their dashboard without touching code; hardcoding that content into the HTML is a broken build, even on a simple landing page. CREATE THEM ALL IN ONE CALL: pass collections: [...] (up to 16) — plan the site's whole content model, then one call per site, not one per section. Each entry picks the preset matching its content (it seeds the field schema) and optionally rows to fill it; embed each returned key with the declarative markup. Unassigned collections serve [] — assign with assign_to_project after deploy. Name each "<Business Name> — <Purpose>". |
| update_data_rows | Update a Dplooy Data collection's rows (the public JSON republishes automatically, live within ~1 minute). PREFERRED: row-level operations — rowEdits changes ONLY the named cells of the named rows (get row ids from get_data_collection), addRows appends, deleteRowIds removes explicitly; every row you do not name is untouched, and any unknown rowId or field id rejects the whole patch with nothing changed. Use rows (whole-set REPLACE — every row you want to keep must be included) only for full rewrites. Cell values are keyed by field id; image cells take { mediaId, path } from upload_media. |
| list_data_collections | List your Dplooy Data collections with usage. Shows public URLs and which are assigned to projects. |
| get_data_collection | Get one Dplooy Data collection: its field schema, rows, public URL, and the canonical fetch snippet. |
| create_booking_page | Create a booking page BEFORE deploying (Plus/Pro). Returns the two-line widget embed + the frozen .db-* styling contract — embed verbatim, STYLE the classes (mandatory: match the site's fonts, colors, spacing, radius), never reimplement booking logic. Every request needs the owner's approval. Unavailable until assign_to_project. Retrying the same name while unassigned returns the existing page. Name it "<Business Name> — <Purpose>". For a business with priced services (salon, barber, clinic, tours), pass `services` so the widget shows a service picker sourced from the project's "services" Data collection — you must supply the currency; the collection is auto-detected. |
| get_booking_page | Read one booking page in full: weekly hours, slot length, capacity, lead time, booking window, cancel cutoff, timezone, assignment, pending count, services & prices state, and the embed. READ-ONLY — availability changes are made by the owner in the dashboard; tell them what to change and where rather than trying to edit it. |
| list_booking_pages | List your Dplooy Bookings pages with usage. Shows which are assigned to projects and pending request counts. |
| list_media | List images in the Dplooy Media Library with their public URLs and the account's image quota. |
| assign_to_project | Makes forms, Data collections and booking pages LIVE on a deployed project — or MOVES them from another one. Reversible (unassign_from_project); submissions, rows and bookings stay with the object. The response WARNS when the deployed files never reference the object (form action, collection key, widget script) — fix the HTML, do not report success. |
| unassign_from_project | Detaches forms, collections or booking pages from their project — nothing is deleted. They go INERT (form rejects, data serves [], widget unavailable) but keep submissions, rows and bookings; assign_to_project re-attaches. Use before delete_* on something empty, or to move an object between sites. |
| get_chatbot | EDITING A BOT? Call this FIRST — returns the settings AND the full knowledge text. configure_chatbot REPLACES the knowledge string (no merge), so edit the returned text and send all of it back. |
| configure_chatbot | LAST step after deploy + assignment (Plus/Pro). ONLY real facts in the knowledge — never invented prices/hours/addresses. Enables/configures the chatbot on a deployed project; the widget is injected server-side, no HTML changes. Partial update, except `knowledge` REPLACES the whole text — editing an existing bot? get_chatbot first. Point contactFormUrl at the site's Dplooy Form URL when one exists. |
| delete_form | ONLY unassigned + zero submissions (empty scaffolding). Anything attached or holding content is refused (409) — relay the reason to the owner, never retry. |
| delete_data_collection | ONLY unassigned + zero rows. Unassigned WITH rows is content preserved from a deleted site — reuse it via assign_to_project instead. Anything attached or holding content is refused (409) — relay the reason to the owner, never retry. |
| delete_booking_page | ONLY unassigned + never received a request. Anything attached or holding content is refused (409) — relay the reason to the owner, never retry. |
| delete_media | ONLY an image no collection row and no project file references (bounded scan). Reclaims image quota from an abandoned build. Anything attached or holding content is refused (409) — relay the reason to the owner, never retry. |
| deploy_files | NEW SITE? STOP — run the BUILD ORDER first (get_account → ask single-file vs multi-page + notification emails → create_data_collection for EVERY repeating section → create_form / create_booking_page → upload_media → THEN deploy). Deploys a multi-file site from inline file contents (HTML, CSS, JS; index.html at the root required). Compose every file DIRECTLY in this call — never stage to your filesystem first. Data sections use the declarative data-dp-collection markup; hardcoded list content is a BROKEN build. After deploy: assign_to_project, configure_chatbot, and ALWAYS hand the user the complete site code in your own interface — deploying alone is not the deliverable. get_guide("workflow") has the full rules. Returns a live URL; reusing a project name redeploys it in-place. |
| upload_media | Pass public https URLs — base64 ONLY for images you generated yourself. Adds up to 16 images to the Media Library in ONE call (all plans; images only, max 5MB each). For any image that exists on the web, pass its URL; the Dplooy server downloads it directly. base64 is STRICTLY the fallback for images you generated yourself that exist nowhere on the web — NEVER base64-re-encode an image that has a URL. Batch ALL the site's images into one call, do not call once per image. Each image returns a stable public URL for <img> tags plus the { mediaId, path } reference Data image cells need. Items succeed or fail independently. Upload images BEFORE writing the site's HTML. TIP: images the user already added to their Media Library are listed by list_media — reuse those URLs directly, no upload needed. |