Magic Now Supports MCP Server Integration for AI Agents

Part of our agent-builder series — start at AI Agent Builders.

Updated September 2026. The connection steps in this announcement have changed since June. The cloudlet now runs its own OAuth 2.1 flow, so there is no JWT to paste and no mcp-remote to install. The setup section below reflects the current path; the MCP Server page is the evergreen reference.

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 is installed from the dashboard's Plugins screen together with the oauth module, 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 oauth and mcp modules from the dashboard's Plugins screen.

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

This section originally showed a claude_desktop_config.json entry that launched mcp-remote with a long-lived Magic JWT pasted in as a bearer token. Do not set it up that way any more. A pasted bearer secret is exactly the failure mode described in 78% of enterprise MCP deployments are doing it wrong, and mcp-remote itself has since carried a critical CVE, covered in the CVE scorecard. The current path needs neither.

With the oauth and mcp modules installed, your cloudlet's MCP URL is:

https://YOUR_CLOUDLET_URL_HERE/magic/modules/mcp/mcp

In Claude, open Customize → Connectors, click Add custom connector, paste that URL, and click Add. Claude then walks you through Authorise. On its first request the cloudlet answers with a 401 pointing at its own OAuth metadata; Claude registers itself as a client, runs the authorization-code flow with PKCE, and you sign in with your Magic username and password. There is no client ID to create and no secret to paste. The token Claude receives carries the roles of the user you signed in as, so connect a scoped user rather than root.

For Claude Code the same URL goes in through one command:

claude mcp add --transport http magic https://YOUR_CLOUDLET_URL_HERE/magic/modules/mcp/mcp

Cursor and any other MCP-over-HTTP client take the same URL and run the same OAuth flow. The full walkthrough, HubSpot included, is in Connect your CRM to Claude with 2 clicks.

This gives Claude access to the HTTP endpoints exposed by your Magic modules, filtered by role, 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 oauth and mcp modules from the Plugins screen, hand your client the URL, 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.