Studio’s own code comments describe MCP Builder as a “thin client”: it renders profiles and relays intent to a composition layer in
machina-client-api — it doesn’t own the builder’s state itself. This page documents what Studio shows and does; the underlying contract lives in machina-client-api (epic 86ajkh09z) and wasn’t read directly for this page — treat exact lifecycle/versioning semantics as needs-validation if you’re building against the contract directly rather than through Studio.It’s chat-driven, not a form
There’s no “new MCP server” wizard with fields to fill in. From the MCP Builder list page, “New MCP” / “Describe your first MCP” opens the Studio Copilot with this prompt already sent:
“Help me build a new outbound MCP server. Ask me what tools it should expose, then use create_mcp_server to draft a profile composing existing workflows, agents, prompts and connector operations in this project.”
Editing an existing one works the same way — “Edit in chat” sends:
“Continue editing the MCP server “So the actual authoring loop is a conversation with Copilot, which calls<slug>” in this project. Show its current tools and help me add, remove or adjust bindings withupdate_mcp_server, then validate and preview before publishing.”
create_mcp_server / update_mcp_server on your behalf.
What a tool binding is made of
Each tool the profile exposes (ToolBinding) has:
Lifecycle: draft → published → paused → archived
A profile version’sstatus is one of draft, published, paused, or archived. The actions Studio exposes, each proxying a machina-client-api endpoint under /mcp-profile/<slug>/*:
Where it shows up for callers
Once published, the profile’s tools become part of the same MCP endpoint every project already exposes — see MCP Overview for the URL/transport/auth, and Connecting External Agents for how an external client actually connects to it.Related
- MCP Overview — the shared connection endpoint.
- External MCP Integrations — the inbound counterpart (consuming someone else’s MCP server).

