Dance

Connector documentation

AI Website Builder and Digital Marketing + SEO

Two Model Context Protocol connectors from Dance for small-business owners. AI Website Builder builds and manages the website. Digital Marketing + SEO finds the change that wins more customers and makes it. Both run on the same Dance service, described below as “Dance”, so one access key, one account and one change history work on either.

Built by Dance Technologies, Inc. Support: admin@startdancing.ai. Not affiliated with or endorsed by Meta; listing in Muse is subject to Meta’s review.

The two connectors

Each connector lists only the tools for its job, with its own name, description and instructions, so an assistant can tell which one fits a request. Editing a connected website is in both, because both may need it: a person asking for a new headline uses AI Website Builder; a person asking why they don’t rank, and to fix it, uses Digital Marketing + SEO. Both call the same editing and approval service.

AI Website Builder by Dance

Build, redesign and manage your business website with AI.

Use when someone wants to create, rebuild, redesign, edit, publish or check on their business website, for example a new site, a modern redesign, adding a page, changing the text on a page, or putting it on their own domain.

AI Website Builder details
ItemValue
Endpointhttps://www.startdancing.ai/muse/mcp/website
Server namedance-website-builder
Landing pagehttps://www.startdancing.ai/muse/website-builder-connector
Toolsbuild_website, get_website_build, change_website, get_website_change_status, undo_website_change, connect_domain, check_domain, list_connected_sites (both), get_site_context (both), prepare_website_change (both), apply_website_change (both), publish_website_change (both), get_website_change (both), revert_website_change (both)

Digital Marketing + SEO by Dance

Digital marketing and SEO for small businesses: find the change that matters most, then make it.

Use when someone wants more customers or more visibility online: SEO audits, Google rankings, search demand and keywords, who outranks them, what to change on their website first, and making that improvement.

Digital Marketing + SEO details
ItemValue
Endpointhttps://www.startdancing.ai/muse/mcp/marketing
Server namedance-marketing-seo
Landing pagehttps://www.startdancing.ai/muse/digital-marketing-seo
Toolsanalyze_business, get_analysis, propose_page_update, plan_site_rebuild, list_connected_sites (both), get_site_context (both), prepare_website_change (both), apply_website_change (both), publish_website_change (both), get_website_change (both), revert_website_change (both)

The original endpoint, https://www.startdancing.ai/muse/mcp (“Dance: AI Website Builder + Digital Marketing + SEO”), keeps serving every tool so earlier installs, including ones named muse-marketer or matt-mcp, keep working. New installs should use one of the two endpoints above.

What they do

Any public website: analysis and recommendations. Dance reads the site, search demand, search results and AI answers, ranks what to fix first with the evidence behind it, and drafts page copy. It never changes a website it has only analyzed.

Connected websites: editing and publication. When a site’s owner has connected a compatible structured CMS to their account, Dance can change specific page text on that site: it plans the exact before and after, saves an unpublished draft, publishes only after the person approves, verifies the live page, and can undo that one change.

New websites: a free preview, $49 to keep. When the person asks for a new website, build_website builds one from their current site on Yoink (yoink.website), a Dance product, and returns a private link where they watch it being built. The preview is free. Keeping the website costs $49, paid on Yoink through its own checkout, never in the conversation. Their current website, domain and DNS are not changed. When there is no website at the address, nothing is built automatically: Dance’s team follows up to build it with them.

Websites built here: any change, then their own domain. change_website takes any change in plain words, such as a new page, a section, a photo from their current site or a public image link, a booking button that goes to their existing booking tool, layout or words. Each change lands on the preview first; undo_website_change takes the latest back out. On the free preview, changes stay on the homepage; new pages come with buying the website. Once it is bought and published, connect_domain connects a domain the person already owns and returns the DNS records to add. Dance never sells or registers domains, and image files can’t be uploaded from the chat.

The first supported CMS is Dance’s structured CMS. Other deployments of the same CMS are connected through configuration and authorization. Dance does not edit arbitrary WordPress, Wix or Squarespace sites and takes no payments itself.

Endpoint and authentication

Connection details
ItemValue
Endpointshttps://www.startdancing.ai/muse/mcp/website (AI Website Builder), https://www.startdancing.ai/muse/mcp/marketing (Digital Marketing + SEO)
TransportMCP Streamable HTTP (POST, JSON responses). Stateless: no session ID is required.
Protocol versions2025-11-25 (latest), 2025-06-18, 2025-03-26 and 2024-11-05
AuthenticationAccess key sent on every request as Authorization: Bearer <key>. This is API-key authentication, not OAuth. The same key works on both connectors and reaches the same account.
UnauthenticatedHTTP 401 with WWW-Authenticate: Bearer realm="dance". No tools are listed or callable without a key.
Server namesdance-website-builder, dance-marketing-seo (the original endpoint is muse-marketer; earlier installs named matt-mcp keep working)

Access keys are issued by Dance. Each key is its own account: its investigations, proposals, connected sites and website changes are invisible to every other key, even to callers who know an ID. Only a SHA-256 fingerprint of each key is stored, and a key can be revoked at any time, which immediately stops it and disconnects its sites.

Each key carries scopes:

Access key scopes
ScopeAllows
researchSaved research, analysis results, page proposals and rebuild assessments.
liveStarting new live investigations and new website previews, within the daily limits.
sitesReading and changing websites connected to this key’s account, within each connection’s own permissions.
List the tools
curl -s https://www.startdancing.ai/muse/mcp/website \
  -H "Authorization: Bearer $DANCE_ACCESS_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Connected websites

A site connection links one account to one CMS deployment. It records the managed site address, the public research domain it represents, the permissions granted (read, draft, publish, revert), a sealed copy of the CMS’s own integration key, and its status. The CMS key is encrypted at rest (AES-256-GCM), is never returned by any tool or page, and is deleted when the connection is revoked.

Authorization is checked twice. The CMS verifies its integration key, that key’s permissions and the records it may touch. Dance separately verifies that the caller owns the connection and that the connection grants the action. A matching domain never grants access: it only helps find a page, and a page addressed by its research URL must be recorded in the CMS as the import of that URL.

Demonstration site. polar-website-migration.vercel.app is Dance’s demonstration import of polarseltzer.com into the structured CMS. polarseltzer.com is the research source only and is never modified. The demonstration keeps its own indexing settings (it is not indexed).

Connecting a site

  1. The site owner signs in to their CMS editor and opens Integrations, creates a connection key, chooses its permissions and, optionally, the pages it may touch. The key is shown once.
  2. The owner gives that key to Dance through a secure channel (never in a chat or a URL). Dance links it to the owner’s Dance access key and runs a connection test, which records the permissions the CMS actually grants.
  3. The site now appears in list_connected_sites. Either side can revoke the connection at any time.

Asking to edit a website that is not connected returns the setup steps instead of an edit. Analysis still works.

Tools

Classifications follow Muse’s connector guidelines. Read changes nothing. Write saves data in Dance or an unpublished CMS draft. Sensitive write changes the live public website and needs approval every time.

  • analyze_business

    Write

    Researches a public website: the business, its pages, search demand, search results and AI answers, then ranks what to fix first and drafts a page proposal.

    Side effects
    Saves an investigation to the caller’s account. Reads public pages (bounded, honours robots.txt) and makes paid search-data lookups for new live investigations. Never changes any website.
    Inputs
    url (homepage or deep page), goal, evidence_mode ("saved" | "live"), run_id to resume, country_location_code, language_code.
    Returns
    run_id, status (queued, running, complete, partial, failed, needs_input), stages, recommendation, proposal handoff, limitations, an expiring report link.

  • get_analysis

    Read

    Returns one of the caller’s investigations (or a public demo): ranked actions with evidence, confidence, sources and proposals.

    Side effects
    None. Reading never advances or changes an investigation.
    Inputs
    run_id.
    Returns
    The full analysis with evidence IDs and expiring read-only links.

  • propose_page_update

    Write

    Creates an evidence-grounded proposal for one inspected page, or revises it from plain-language instructions.

    Side effects
    Saves a proposal revision in Dance. Refining shared demo material creates the caller’s private copy. Never changes any website.
    Inputs
    run_id, action_id, page_url, instructions, proposal_revision (rejects edits to a stale revision).
    Returns
    Proposal ID, revision, validation checks, declined claims.

  • plan_site_rebuild

    Read

    Assesses whether a finished investigation’s site would benefit from a structured, plain-language-editable CMS and returns a brief when it would.

    Side effects
    May fetch the site’s homepage once to detect its platform (cached). Builds, deploys and changes nothing.
    Inputs
    run_id, force.
    Returns
    Fit, reasons, blockers, cautions and an optional brief. The brief is not a built website; build_website builds one.

  • build_website

    Write

    Builds a brand-new website for a business from its current site, as a free homepage preview. Built and hosted by Yoink (yoink.website), a Dance product. Keeping it costs $49, paid on Yoink.

    Side effects
    Starts one preview build on Yoink and returns a private link to it. Never changes the current website, its domain or DNS. Nothing is charged in the conversation. The same site from the same access key returns the same website instead of a second build.
    Inputs
    website_url (the business’s current website), email (optional; Yoink emails when the preview is ready).
    Returns
    website_id, status (building, ready, failed, no_website), open_url (private), price, paid.

  • get_website_build

    Read

    Reports the progress of a website started with build_website.

    Side effects
    None.
    Inputs
    website_id.
    Returns
    Status, the private link, the price and whether it has been bought.

  • change_website

    Write

    Sends a plain-language change (a page, section, photo from their site or a public image link, booking button, layout, words) to the builder of a website started with build_website.

    Side effects
    Changes the website’s preview only, never the live site. On the free preview, changes stay on the homepage and each one uses a free change; a refused or failed change uses none.
    Inputs
    website_id, request (plain words, up to 2,000 characters).
    Returns
    change_id, state (working, applied, saved, answered, refused, failed, unconfirmed), the builder’s reply, preview_url, changes_left, can_undo.

  • get_website_change_status

    Read

    Reports where one change or undo stands. Never sends it again.

    Side effects
    None for the person; a finished change is moved onto the preview.
    Inputs
    change_id.
    Returns
    The same fields as change_website.

  • undo_website_change

    Write

    Takes the latest change back out, when it is the person’s own and nothing else is running.

    Side effects
    Changes the website’s preview only.
    Inputs
    website_id.
    Returns
    change_id and its state, as change_website.

  • connect_domain

    Write

    Connects a domain the person already owns to a website started with build_website, once it is bought and published on Yoink.

    Side effects
    Attaches the domain to the website’s hosting. Never changes the person’s DNS and never buys or registers a domain.
    Inputs
    website_id, domain.
    Returns
    status (needs_verification, pending_dns, active), the DNS records to add, live_url once live.

  • check_domain

    Read

    Re-checks a connected domain: live yet, or which records are still missing.

    Side effects
    None.
    Inputs
    website_id, domain.
    Returns
    The same fields as connect_domain.

  • list_connected_sites

    Read

    Lists the websites connected to the caller’s account, with their permissions and capabilities.

    Side effects
    None.
    Inputs
    None.
    Returns
    Sites (managed address, research domains it represents, permissions, status) or the setup steps when none are connected.

  • get_site_context

    Read

    Finds a page on a connected site by URL, path, record ID or search, and returns its published values, editable fields, any draft and its version.

    Side effects
    Reads from the connected CMS. Changes nothing.
    Inputs
    site_id, page, query.
    Returns
    Page record with editable fields and limits, unsupported areas, open changes.

  • prepare_website_change

    Write

    Reads the page’s current content from the CMS and saves a validated change plan with the exact before and after of every field. Accepts explicit field values, a plain-language request, or a proposal.

    Side effects
    Saves a plan in Dance. Changes nothing in the CMS or on the website. Plain-language requests are mapped by the AI model; no crawl or keyword research runs.
    Inputs
    site_id, page, changes[] or request or proposal_id (+ proposal_revision), context, change_id (revise), idempotency_key.
    Returns
    change_id, plan_revision, plan_hash, changes (before → after), not_applied, approval_summary.

  • apply_website_change

    Write

    Saves exactly one plan revision to the connected CMS as an unpublished draft, then reads it back.

    Side effects
    Creates one draft change in the CMS. Nothing is live. Creates a signed draft-preview link that expires after two hours. Refuses if the page changed or holds someone else’s draft.
    Inputs
    change_id, plan_hash, idempotency_key.
    Returns
    CMS change reference, baseline and draft versions, read-back result, preview_url.

  • publish_website_change

    Sensitive write

    Publishes only this change’s own draft to the live website, then fetches the public page to verify the new values.

    Side effects
    Changes the live public website. Other pending drafts are never published. Fails without changing anything if the plan, draft or page changed after approval.
    Inputs
    change_id, plan_hash (the plan the person approved), idempotency_key.
    Returns
    Publication reference and version, verification (verified, pending or mismatch) or approval_url.

  • get_website_change

    Read

    Reports the actual state of one change, or lists recent changes.

    Side effects
    Asks the CMS about any unconfirmed operation and re-checks the public page, then records what it found. It never repeats or starts a write.
    Inputs
    change_id (optional).
    Returns
    Status, CMS references, versions, verification and next step.

  • revert_website_change

    Sensitive write

    Undoes exactly this change: removes its draft, or restores the live page values from before it was published.

    Side effects
    Changes the live public website when the change was published. Never undoes an unrelated change. Refuses if the page was edited since.
    Inputs
    change_id, plan_hash, idempotency_key.
    Returns
    Reverted CMS references, read-back of the restored values and public-page verification.

Approval and publishing

Talking about a change is not permission to make it, and a draft is not permission to publish. The flow is: prepare_website_change (plan) → apply_website_change (unpublished draft, read back from the CMS) → publish_website_change (live, verified) → optionally revert_website_change.

Every plan has a plan_hash that pins its exact fields, values, page and the CMS version it was read from. Revising a plan creates a new revision and a new hash, and approval given for the old one no longer works, in either direction. If the page changed in the CMS after the plan was read, or holds someone else’s unpublished draft, nothing is written.

In Muse. publish_website_change and revert_website_change are sensitive writes, so Muse asks the person to Allow once or Deny every time, showing the change and its approval_summary. The access key issued for Muse treats that allowed call as the approval for exactly the change_id and plan_hash shown. Dance does not use or imitate any other Muse approval interface.

Other MCP clients. For keys whose client cannot guarantee a per-use human approval, publishing and live reverts return an approval_url instead. That Dance review page shows the exact before and after; the person approves by entering their own access key. The link expires after 24 hours and is tied to the change, the action and the plan hash. A value supplied by the model, such as an “approved” flag, is never accepted as approval.

Publication affects only the change’s own records. Other pending drafts on the site, including other editors’ work, stay unpublished. Reverting undoes only the identified change and refuses if the page was edited since.

Status, retries and errors

Change statuses
StatusMeaning
plannedA plan exists in Dance. Nothing in the CMS.
draftedSaved as an unpublished draft in the CMS and read back. Nothing is live.
awaiting_approvalPublication requested; waiting for the person to approve on the review page.
publishedThe CMS confirmed publication. See verification for what the public page shows.
revertedThis change was undone. The page fields are back to their earlier values.
conflictThe page changed outside this plan, so nothing was overwritten. Prepare a new plan.
failedThe operation failed without modifying the site. See last_error.
applying · publishing · revertingAn operation started and its result is not yet confirmed. get_website_change reconciles it with the CMS.

Verification. After publishing or a live revert, Dance fetches the managed public page without caches and checks the title, meta description, H1 and changed copy. verified means the page shows every value. pending means the CMS confirmed the change but the page could not be read or still shows older content; it is reported as propagating, not as failed. get_website_change checks again.

Retries. Write tools accept an optional idempotency_key. Repeating a call with the same key and request returns the stored result without writing again; reusing a key for a different request fails without changing anything. Applying, publishing or reverting the same plan revision twice also writes nothing new, and every CMS mutation carries its own idempotency key that the CMS records in the same transaction as the content change. If a call times out, the outcome is reported as uncertain: call get_website_change, which asks the CMS what happened instead of repeating the action.

Errors
ErrorMeaning
needs_inputNo website or page was given. Nothing was started; ask the person which site they mean.
no_connected_site · site_not_connectedThe website is not connected to this account. It can be analyzed, not edited. Setup steps are included.
permission_deniedThe access key or the site connection does not allow this action.
identity_unverifiedThe managed page is not recorded as the import of the research URL given. Name the managed page directly.
unrelated_draftThe page already holds someone else’s unpublished draft. The connector will not merge into or publish it.
conflictThe page changed after the plan was read. Nothing was written.
plan_changedThe plan_hash is not the current plan revision. Review and approve the current plan.
validation_failedA requested value is not allowed (unknown field, too long, markup, unknown link). Nothing was planned.
idempotency_key_reusedThat idempotency_key was used for a different request. Nothing was changed.
request_in_progressThe same request is running or its outcome is unknown. Check get_website_change.
cms_unreachable · outcome "uncertain"The CMS did not confirm. Nothing is assumed; get_website_change asks the CMS what happened.
daily_limitA published usage limit was reached. Saved research still works.
unsafe_urlThe address is not a public website (private networks and unsafe redirects are refused).
invalid_addressbuild_website: not a public address. Nothing was built. (An address with no website returns status no_website: Dance’s team follows up in person.)
unavailableWebsite tools: Yoink did not answer. Nothing was built or charged; a change already sent is read back with get_website_change_status, never resent.
account_ownedchange_website / undo_website_change / connect_domain: the website now belongs to a Yoink account; its owner works on it there. Nothing changed.
not_paid · not_publishedconnect_domain: the website must be bought, then published once on Yoink, before a domain connects. Nothing was connected.
invalid_domainconnect_domain / check_domain: not a domain name that can be connected. Nothing was connected.
site_unreachableNo server answers for that address (DNS lookup failed). Nothing was analyzed; confirm the address and try again.

What can be edited

On a connected page, one change can update any of these existing fields:

  • SEO title and meta description
  • Page headline (H1)
  • Introduction or hero paragraph
  • Tagline on product pages
  • Labels and destinations of existing buttons (a page on the same site, or a link the site already uses)
  • Text of existing sections: headings, eyebrows, subheadings, paragraphs, bullets, intros and bodies

Not supported:

  • Images, layout, adding or removing sections, creating or deleting pages
  • Navigation, footer and other sitewide settings (no sitewide changes are possible through the connector)
  • Prices, product facts, nutrition and structured data
  • Any website that is not connected through a compatible CMS, including arbitrary WordPress, Wix or Squarespace sites

Values must be plain text within each field’s limit, and links must point to an existing page on the same site or a link the site already uses. When a recommendation includes something the CMS cannot apply, such as a new section or FAQ, it is listed under not_applied in the plan before anything runs, so nothing is silently dropped. On product pages the H1 is stored separately from the product name, so changing a headline does not rename catalog cards or breadcrumbs.

Usage limits

Using the connector is free within these limits. One thing it leads to is paid: a website built with build_website is a free preview, and keeping it costs $49, a one-time payment the person makes on yoink.website through Yoink’s own checkout. Nothing is charged in the conversation, and the connector never sees card details.

Usage limits
WhatLimit
New live investigationsSet per access key (3 a day by default, 5 for the reviewer key); 6 a day per network; 30 a day across Dance. Reusing finished research is not limited.
Website-change operations60 a day per access key and 120 a day per network (prepare, apply, publish and revert each count).
New website previews1 a day per access key, 2 a day per network and 10 a day across Dance. Checking a website already started is not limited. An address with no website builds nothing and uses none.
Changes to websites built here20 a day per access key, 40 a day per network and 200 a day across Dance (changes and undos), on top of the website’s own allowance on Yoink: a few free changes on the preview, homepage only, then the bought website’s allowance. Checking a change is not limited.
CrawlingUp to 60 pages per investigation (7 for a single deep page), public addresses only, robots.txt and its crawl delay honoured, at least 2 seconds between requests to one site.
Call durationEach call returns within about 80 seconds. Longer investigations return status "running" and a run_id to continue.
Field lengthsSEO title 120 characters, meta description 320, H1 140, introduction 1,500, button label 60. Plain text only.
Scope of one changeOne page and up to 20 fields per change.
LinksReport and proposal links expire after 7 days and can be revoked; draft previews after 2 hours; approval links after 24 hours.

Data handling

What is stored, per account: the websites a person asks about and the evidence gathered from them (page text excerpts, search data), investigations, proposals and their revisions, change plans with their before and after values, CMS change references, approval records and verification results. Access keys are stored only as fingerprints; connected-site credentials are encrypted.

Who processes it: Vercel (hosting and the AI Gateway, which sends prompts to the configured model provider, currently Anthropic), Neon (database, United States) and DataForSEO (search data for the domains and keywords being researched). For a new website, Yoink (Dance) receives the current site’s address, an opaque ID for the access key (never the key) and, only if the person gives it, an email address for the ready notice. Changes go only to the CMS the site owner connected. Dance’s private analytics accounts are never exposed to other callers.

Use: only to answer the person’s requests and to operate, secure and support the connector. Data shared through Muse is not sold, not used for advertising or unrelated profiles, and not used to train models.

Retention and deletion: an account’s research and change history are kept until the account owner asks for deletion (privacy@startdancing.ai). Revoking a site connection deletes its stored CMS credential immediately; revoking an access key stops all of its access. Report links, draft previews and approval links expire.

Safety: fetched website content is treated as evidence and never as instructions; it cannot authorize an edit or change permissions. Crawling is bounded, honours robots.txt and refuses private network addresses. Secrets never appear in tool output, URLs or logs.

Dance Technologies’ Privacy Policy and Terms of Use apply.

Reviewer setup

Reviewers receive a dedicated access key through the submission portal’s secure credential method. It is never published. The key:

  • Has its own isolated account with research, live and sites scopes, and 5 new live investigations a day.
  • Uses Muse’s per-use approval for publishing and reverting (sensitive writes).
  • Is connected to the Polar demonstration site with read, draft, publish and revert permission on a fixed set of test pages, including /lemon/. It cannot touch sitewide settings or other pages.
  • Can be revoked by Dance at any time; a replacement is issued on request at admin@startdancing.ai.
  1. Add the connector with the endpoint above and the reviewer key as a Bearer token.
  2. Ask “What websites can you edit for me?” to see the demonstration site and its permissions.
  3. Research-led: “How can I make polarseltzer.com/lemon/ better?”, then “Put that proposal on the connected page.” Review the plan, apply it as a draft and open the preview link.
  4. Direct edit: “Change the headline on the lemon page to …”. No investigation runs.
  5. Approve the publication when Muse asks, then “Is it live yet?” to see the public-page verification.
  6. “Undo that change” restores the earlier values; approve it when asked.
  7. Ask to edit any other website, for example https://example.com, to see the connection requirement.

Example prompts

  • How can I make my website better? It’s https://example.com
  • Analyze polarseltzer.com/lemon/ and tell me the one change that matters most.
  • What websites can you edit for me?
  • Change the headline on the lemon page to “Lemon Sparkling Water”.
  • Make the introduction on that page shorter.
  • Update the title and meta description of the lemon page.
  • Put the proposal you just made on the connected page.
  • Publish it.
  • Is it live yet?
  • Undo that change.
  • Build me a new website. My current one is example.com.
  • Is my new website ready?