AI agents become much more useful the moment they can do something real.
Not just answer questions. Not just generate code. But actually reach backend tools, company data, workflows, APIs, and internal systems.
That is exactly why MCP matters.
And it is also why Magic now supporting MCP is a bigger deal than simply adding one more protocol checkbox to the product.
Magic now has a new module called mcp.
It can be installed from the Plugins section under the Manage menu, and once installed, it turns your Magic Cloud cloudlet into an MCP server.
The important part is what happens next.
The MCP server automatically exposes all HTTP endpoints inside modules in the /modules/ folder.
That means a Magic cloudlet can now act as a direct bridge between AI clients such as Claude Cowork, Codex, and other MCP-compatible systems, and the actual backend capabilities you already have inside Magic.
Why this matters
A lot of AI tooling still has the same structural limitation.
The model may be smart, but it is isolated.
It can reason about your business. It can generate suggestions. It can propose workflows. But unless it can connect to real systems, it remains trapped inside its own token stream.
MCP helps solve that problem by standardising how AI systems connect to tools.
Magic makes that standard immediately useful.
Because Magic is not just a thin MCP wrapper. It is already a backend platform with:
- modules
- HTTP endpoints
- workflows
- generated APIs
- database tools
- custom business logic
- integrations with internal systems
So when MCP support lands in Magic, it does not expose a toy surface. It exposes a real backend capability layer.
Install the module, expose the endpoints
The design is intentionally simple.
Install the mcp module from Manage → Plugins.
After that, the MCP server automatically exposes the HTTP endpoints found inside your modules under /modules/.
This is important because it removes a lot of manual glue work.
In many stacks, adding MCP means building and maintaining a separate adapter layer just to make existing tools available to external AI systems.
Magic skips much of that friction.
If a capability already exists as an HTTP endpoint in one of your modules, it can become available through MCP automatically.
That creates a very short path from:
backend capability → MCP tool → usable AI integration
Getting started with Claude Cowork
One of the easiest ways to try this is with Claude Cowork.
After installing the mcp module in Magic, open:
Claude → Settings → Developer → Edit
This opens your claude_desktop_config.json file.
Then add a configuration similar to the following:
{
"mcpServers": {
"MagicCloud": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://YOUR_CLOUDLET_URL_HERE/magic/modules/mcp/mcp",
"--header",
"Authorization: Bearer ${AUTH_TOKEN}"
],
"env": {
"AUTH_TOKEN": "JWT_KEY_HERE"
}
}
}
}
Replace JWT_KEY_HERE with your own Magic JWT token, and YOUR_CLOUDLET_URL_HERE with your cloudlet's URL.
Save the file, restart Claude, and Claude Cowork will be able to use your Magic cloudlet through MCP.
This gives Claude access to the HTTP endpoints exposed by your Magic modules, which means your cloudlet can start acting as a practical bridge between Claude and your backend capabilities.
Why this is especially powerful in Magic
Magic already has a strong model for backend extensibility.
You can create APIs, workflows, database wrappers, and custom tools. You can generate missing capabilities on demand. You can connect to company systems. You can wrap old infrastructure. You can expose narrowly scoped functionality instead of handing out raw access.
Now all of that becomes easier to surface to external AI clients.
This makes Magic useful in a new role.
Not just as the place where you build tools. But also as the place where outside AI systems discover and use those tools.
That matters because many organisations do not want their AI clients talking directly to databases, legacy systems, or ad hoc internal services.
They want a bridge.
Magic can now be that bridge.
A bridge to company data
This is where the new MCP support becomes strategically interesting.
Most companies already have data.
The problem is rarely lack of information. The problem is access, structure, safety, and integration.
That data may live in:
- SQL databases
- old internal applications
- custom APIs
- operational workflows
- small helper endpoints built over time
Magic was already good at wrapping those things and exposing them in usable ways.
Now the MCP module makes it much easier to put that capability in front of tools like Claude Cowork or Codex.
So instead of asking an AI assistant to guess, simulate, or work around missing backend access, you can let it call real backend functionality through your Magic cloudlet.
That is a major shift.
The assistant stops behaving like an isolated model and starts behaving more like a system participant.
Practical examples
Once MCP is enabled, a Magic cloudlet can help external AI systems do things such as:
- query internal business data through controlled endpoints
- invoke workflows already implemented in Magic
- access generated APIs for CRUD, reporting, or operational tasks
- connect coding agents to backend helpers they can actually use
- wrap legacy systems and expose them in a modern tool-friendly format
This is valuable for both operational agents and development agents.
A coding assistant such as Codex can use Magic as a backend bridge. A business-facing assistant such as Claude Cowork can use Magic to reach workflows and data that would otherwise be unavailable.
And because the exposure happens through the module HTTP endpoint layer, the capabilities are grounded in the same backend environment you already control.
Why automatic endpoint exposure matters
The strongest part of this release may be how little ceremony it requires.
You do not need to redesign the entire system around MCP.
You do not need to build a second parallel tool surface from scratch.
You do not need to maintain separate logic for “internal backend use” versus “AI tool use” if your existing module endpoints already express the right capabilities.
Magic simply turns those endpoints into something MCP-compatible systems can use.
That is the kind of leverage that matters in practice.
The less integration tax a protocol introduces, the more likely it is to become part of the real architecture instead of staying a demo feature.
The bigger picture
What makes this interesting is not only interoperability.
It is architecture.
Magic is gradually becoming more than an app builder, more than an API runtime, and more than a backend generator.
With MCP support, it also becomes connective tissue between AI clients and real company infrastructure.
That means you can increasingly treat your cloudlet as:
- a backend runtime
- an integration layer
- a tool surface for agents
- a bridge to internal systems
And because the MCP module automatically exposes module HTTP endpoints, the features you already build in Magic can become useful to a much wider ecosystem of AI tools.
Conclusion
MCP is important because it gives AI systems a standard way to reach tools.
Magic makes that standard practical by turning your existing module endpoints into an MCP-accessible capability layer.
Install the mcp module from Manage → Plugins, and your Magic Cloud cloudlet can start acting as a bridge between systems such as Claude Cowork, Codex, and the backend functionality, workflows, and company data already living inside Magic.
In other words, Magic is no longer only a place where you build the tools.
It is now also a place where outside AI systems can discover and use them.