You can use DashPloy by pasting one line into your assistant. That works everywhere, it's fine, and nothing here replaces it.
If your client supports MCP, connect once in the settings instead and never paste anything again. Your assistant gets a set of tools — deploy, list projects, read logs, set secrets — the same way it has a web search tool. In a chat app that can sign you in, this is now the shorter path of the two: there is no code to copy at all.
What MCP is
Model Context Protocol. A standard for describing tools to an AI assistant so it can call them directly, instead of reading documentation and constructing HTTP requests.
The practical difference: without it, your assistant reads /llms.txt, works
out the right request, and sends it. With it, it sees a tool called deploy
that takes a project and some files, and calls it.
Same platform, same errors, same results. It's a wrapper over the API, not a different service.
Setting it up
If your client offers to sign you in, take that. Add
https://dashploy.com/mcp wherever it lists connectors, choose the sign-in
option rather than the one asking for a key, and press Connect on the page it
sends you to. Nothing is copied and there is no code to keep safe. That is the
whole setup, and it is what most people should do.
The rest of this section is for clients configured from a file, which have no way to sign you in.
For a Claude-style client, add this to your MCP settings:
{
"mcpServers": {
"dashploy": {
"type": "http",
"url": "https://dashploy.com/mcp",
"headers": { "Authorization": "Bearer dp_xxxxxxxx" }
}
}
}
Replace dp_xxxxxxxx with your code, from your dashboard.
In a hosted connector, use X-API-Key instead, with the bare code and no
Bearer in front of it. Some apps reserve Authorization for their own sign-in
and silently drop whatever you put there — the connector then reports itself
connected, lists every tool, and fails on the first real call. Measured, not
guessed: the identical code worked from curl and never arrived from the
connector. A config file like the one above is unaffected.
Three things to know about the transport, because they're the usual cause of a failed connection:
- It's Streamable HTTP, not the older stdio transport. There's nothing to install locally and no process to run.
- It's POST only. A
GETreturns a deliberate 405 — that's a probe refusing, not an outage. If you paste the URL into a browser and see an error, that's expected. - Every call needs a credential, including the first handshake. An unauthenticated request gets a 401 pointing at where to sign in, which is how a client that supports it starts the sign-in flow on its own. If yours simply reports an error instead, it does not support that flow — use a key.
What you get
Twenty-five tools. The ones you will notice are whoami, list_projects,
deploy, get_deployments, get_logs, set_env, add_domain and
delete_project; the rest cover domain search, buying and renewal.
The interesting one is get_logs. Without it, an assistant that deploys a
broken app can see the deploy succeeded and nothing else — the failure happens
later, at runtime, when someone visits. With it, it can read the actual
exception and fix the bug. That's the difference between "I published it, let me
know if there are problems" and an assistant that notices and repairs.
Whether it's worth it
Honestly: for most people, no, and that's fine.
Use the pasted line if you're publishing a personal site, you use whichever assistant is convenient, or your client doesn't have connector settings. It works identically. Nothing is degraded.
Use MCP if you're deploying often, you want your assistant to read runtime logs without being asked, or you're tired of re-pasting the line into every new conversation.
The pasted line is not a lesser path. It's the same API, and the same
instructions in /llms.txt that the MCP tools wrap.
Security, briefly
If you signed in rather than pasting a code, there is no code involved at all — nothing to leak, nothing in your chat history, and you can end the connection from Connected apps. That is the meaningful improvement, and it is why it is the recommended route now.
If you pasted a code into connector settings, that is a milder improvement: it isn't sitting in chat history, and you're not re-pasting it into new conversations where it accumulates.
It's not a different trust model — the access is the same either way, and it is worth reading it properly rather than assuming it is publish-only. It can create and publish websites, change their settings and secrets, read their logs, connect domains you own, buy new domains using a card you already have on file, and delete websites on your account.
It can't sign in as you anywhere else, see your password, change your plan, or touch your billing details. The page you approve when you sign in lists exactly this, which is the point of showing it rather than a shorter, friendlier summary.
One practical note: once your assistant makes its first call, the code stops being visible on your dashboard. That's deliberate, and it means you should put it into the connector settings while you can still see it. If you lose it, get a new one rather than going looking.
If the connection fails
"Unauthorized" — in a hosted connector, the usual cause is the app dropping
your Authorization header. Re-add the code as X-API-Key with no Bearer
prefix. In a config file, check the header is exactly
Authorization: Bearer dp_... with the space, and that the code is not
truncated.
It says connected but nothing works — connecting proves less than it looks.
Ask it to run whoami: that is the cheapest call that proves your credential
actually arrives.
"Method not allowed" — something is sending GET. The endpoint is POST only.
Tools don't appear at all — most clients need a restart after editing MCP settings. If a restart doesn't do it, the client is being refused: every call needs a credential now, the tool list included.