Deploy from Cursor or Windsurf with a remote MCP server (no account, no token)

Disclosure: I'm behind DropTheHassle.

If you build in Cursor or Windsurf, the agent already writes the code, runs the build and fixes the errors. The one thing it usually can't do is put the result online. It hands you a dist/ folder and a list of hosting options.

MCP fixes that. You add a server, and the agent gets tools it can call. This post sets up a deploy server that needs no account and no token for the first publish. I build it, so here's the setup, what you get back, and where it stops.

Why MCP instead of a terminal command

You can deploy from a terminal with npx -y dropthehassle deploy, and in Cursor the agent can run that for you. MCP is nicer in three cases:

• You want the agent to decide when to deploy ("put it online when the build passes").
• You want structured results: the tool returns the live URL and the claim link as data, not as terminal text the model has to parse.
• You want the agent to check a domain name without leaving the chat.

Setup in Cursor

Cursor reads .cursor/mcp.json in the project, or ~/.cursor/mcp.json for all projects. Remote servers use a url key:

{
  "mcpServers": {
    "dropthehassle": {
      "url": "https://dropthehassle.com/mcp"
    }
  }
}

No headers block is needed for the first deploy. Open the MCP section in Cursor's settings to check it connected; you should see tools like deploy_site and search_domain.

Setup in Windsurf

It depends on which agent you use.

Cascade (the older agent) uses mcp_config.json, and remote servers take a serverUrl key:

{
  "mcpServers": {
    "dropthehassle": {
      "serverUrl": "https://dropthehassle.com/mcp"
    }
  }
}

Devin Local (the default for new tabs) configures servers through the Devin CLI config instead. There, use the local stdio server, which also works without a token:

{
  "mcpServers": {
    "dropthehassle": {
      "command": "npx",
      "args": ["-y", "dropthehassle-mcp"]
    }
  }
}

Put that in .devin/mcp_config.local.json, or run devin mcp add dropthehassle -- npx -y dropthehassle-mcp.

What works without an account

With no token, the server exposes three tools:

• deploy_site: publishes the built site to a free name.dropthehassle.app link with HTTPS, and returns a claim link.
• search_domain: checks whether a domain is free and what it costs.
• whoami: confirms the connection and lists what works.

The other tools (listing your sites, renaming the free link, pointing a domain, linking a backend, getting a checkout link) need a token from an account.

Deploying

Ask the agent something like:

Build the site and publish the dist folder with DropTheHassle. Give me the live link and the claim link.

Cursor asks for approval before it runs an MCP tool by default, and you can expand the call to see the arguments. The server's own instructions tell the agent it must pass the claim link on to you, so you should see both links in the chat.

This is what the tool returned when I called it with a one-file test site (claim link removed):

Live at https://warm-finch-339.dropthehassle.app […]. Give the human this claim link
(it expires in 7 days): https://dropthehassle.com/claim#… This site is not on an account until they claim it.

One detail matters here. The remote server can't read your disk. Over the URL, deploy_site receives the files inline: each file as a path plus its content, as UTF-8 text or base64. The agent reads the built files and sends them. That works well for a normal static site. For a folder with lots of images or video it's a lot of data to push through a tool call. For those, use the local server (npx -y dropthehassle-mcp), which uploads the folder itself as a zip of at most 100 MB, or run the CLI.

Checking a domain

This is a real response from search_domain for a made-up name:

push100testsite.com: AVAILABLE (EUR 19/yr incl. VAT in the EU, USD 19 elsewhere, the same every year). […]
Buying is a human step in the dashboard; I can search and suggest, not spend.

That second line is the design: your AI can publish, but it can never spend your money. No tool buys anything. With an account, the agent can fetch a checkout link for a domain on your site; you open it and pay yourself. After payment the domain goes live on that site, with no DNS records to edit. A .com is €19 a year including VAT in the EU, or $19 elsewhere, and it's the same every year. If you already own a domain, you point it with one A record instead.

After you claim

The claim link is valid for 7 days. Until you claim the site:

• it's served with noindex, nofollow, so search engines are asked to skip it;
• visitors see a small, dismissible bar: "Made with DropTheHassle · Claim this site · Report abuse";
• after 7 days an unclaimed site is removed.

Once it's claimed and you want the account tools, create a token in the dashboard (it starts with dth_). For the local server, put it in the env block as DTH_TOKEN. For the remote URL, send it as an Authorization: Bearer header. Never commit it to the repo, and don't paste a placeholder value; leave it unset until you have the real one.

Limits

• Built files, plus a linked server part. A folder that still needs a build is refused, and server code (PHP, Node, Python) doesn't run on DropTheHassle itself. Got a server part too? Keep it on AWS, Google Cloud, DigitalOcean or your own server, and your AI links it to your site in one step. With an account, set_backend puts it behind your name: paths such as /api/* go to your server, or the whole site does.
• Remote means inline files. See above. Big assets go through the local server or the CLI.
• Client-side routes survive a refresh: a path that isn't a real file (say /about) gets your index.html, while a missing file such as /missing.png still returns a 404.
• Team policies can block it. Cursor lets enterprise admins restrict which MCP URLs and commands may run. If the server doesn't show up, check with your admin.
• Cloud agents are a different environment. Background or cloud agents run elsewhere, with their own network rules. I've written this for the local editor.

The point

The nice thing about an agent-driven deploy isn't saving 30 seconds. It's that the loop closes: the agent builds, publishes, and hands you a URL you can open on your phone. That's the moment a side project becomes real enough to show someone.

Setup details and more examples: Deploy with your AI (MCP guide). Cursor-specific steps, including the domain: Cursor site on your own domain. Windsurf: Windsurf deploy to a custom domain.

If something in the setup didn't work for you, post the error in the comments. I'd rather fix the rough edges than have you guess.

Disclosure: I'm behind DropTheHassle.