The normal way to use BlueDeploy is pasting one line into your assistant. It works everywhere and it's fine.
If your client supports MCP, there's a tidier option: connect once in the settings 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.
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
For a Claude-style client, add this to your MCP settings:
{
"mcpServers": {
"bluedeploy": {
"type": "http",
"url": "https://bldeploy.com/mcp",
"headers": { "Authorization": "Bearer bd_xxxxxxxx" }
}
}
}
Replace bd_xxxxxxxx with your code, from your dashboard.
Two 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.
What you get
Eleven tools: whoami, list_projects, deploy, get_deployments,
get_logs, set_env, list_env, delete_env, add_domain, list_domains
and delete_project.
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
Your code goes in the connector's settings rather than in the conversation. That is a mild 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 code can do the same things either way — publish to your account, and nothing else. It can't sign in as you, see your card, or change your plan.
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" — the code is wrong, truncated, or was replaced. Check the
header is exactly Authorization: Bearer bd_... with the space.
"Method not allowed" — something is sending GET. The endpoint is POST only.
Tools don't appear — most clients need a restart after editing MCP settings.
Everything connects but calls fail — ask it to run whoami. That reports
what your account can and can't do, and turns a vague failure into a specific
one.