Cursor/Claude Desktop MCP: hosted vs self-hosted MCP server for a multi-user product—what do teams pick?

Quick Answer: For multi-user products using Cursor or Claude Desktop with MCP, most teams start with a hosted MCP runtime (like Arcade) for auth, permissions, and reliability, and only self-host when they need tight VPC/on‑prem control or have a strong infra team ready to own the runtime.

Frequently Asked Questions

How should I think about hosted vs self-hosted MCP for a multi-user product?

Short Answer: Treat hosted MCP as the default for multi-user agents; move to self-hosted only when you have clear regulatory, network, or customization requirements and the engineering bandwidth to own the stack.

Expanded Explanation:
In a single-user Cursor or Claude Desktop setup, running a local MCP server is easy: uv run server.py and you’re off to the races. For a multi-user product, the problem shifts from “can I call tools?” to “how do I safely call tools for hundreds or thousands of users with the right permissions, no token leaks, and no refresh-token roulette?” That’s where the runtime between AI and action matters more than the model.

Hosted MCP runtimes like Arcade give you authentication flows, user-specific permissions, OAuth token storage/refresh, secrets isolation from the LLM, and MCP compatibility with Cursor, Claude, LangGraph, and more—without rebuilding that infrastructure yourself. Self-hosting is viable when you absolutely need everything inside your VPC or air-gapped environment and you’re ready to run the MCP runtime as a production service (monitoring, scaling, patching, audits) instead of a sidecar script.

Key Takeaways:

• Start hosted if you want to move from “Cursor prototype” to “multi-user production agent” without building auth and token plumbing.
• Choose self-hosted when compliance, network isolation, or deep customization outweigh the cost of running the runtime yourself.

---

What does the process look like to go from a local MCP server in Cursor/Claude to a hosted MCP runtime?

Short Answer: You wire your existing MCP tools into a hosted runtime, connect OAuth/IDP for user auth, then point Cursor/Claude (or your agent framework) at that runtime instead of a local server.

Expanded Explanation:
Most teams start by hacking on an MCP server locally:

uv tool pip install arcade-mcp
arcade new my_server
cd my_server
uv run server.py

This is perfect for a single builder in Cursor or Claude Desktop: tools are local, credentials live in .env, and you don’t worry about other users. As soon as you’re building a product where many users share the same agent, that architecture breaks:

• You can’t ship .env files to users.
• You can’t safely reuse one service account for everyone.
• You can’t debug or govern what the agent actually did.

Moving to a hosted MCP runtime means your tools and auth logic run behind an HTTP endpoint that Cursor, Claude Desktop, or your LangGraph/LangChain agent talks to. The runtime handles auth.start and wait_for_completion, exchanges OAuth codes, stores/refreshes tokens, and injects credentials at tool execution time—without exposing tokens to the LLM.

Steps:

1. Abstract your tools from your local server. Keep your Python tool implementations clean (no hard-coded tokens), using environment variables locally.
2. Deploy those tools behind a hosted MCP runtime. Use a platform like Arcade so the runtime provides OAuth, secrets, and multi-user support out of the box.
3. Update your client configuration. Point Cursor, Claude Desktop, or your agent framework at the new MCP endpoint and wire in user-specific auth (e.g., redirect users through client.auth.start(...) to connect Gmail, Slack, etc.).

---

How do hosted and self-hosted MCP options compare for Cursor/Claude multi-user use?

Short Answer: Hosted MCP optimizes for speed, auth, and governance; self-hosted optimizes for environment control and custom infrastructure, at the cost of owning more complexity.

Expanded Explanation:
Both models expose MCP tools to Cursor and Claude Desktop, but the tradeoffs shift once you go beyond a single developer. The root question becomes: who owns identity, tokens, and runtime reliability—the vendor, or your team?

Hosted MCP runtimes (like Arcade’s) are designed to be “agent-compatible” out of the box—working with Cursor, Claude, LangGraph, and more—while providing authorization, secrets management, and deployment options (cloud, VPC, on‑prem, air-gapped). Self-hosting gives you maximum control, but also means you’re rebuilding the pieces Arcade and similar platforms already handle: scoped OAuth, token refresh, user/session mapping, audit logging, and MCP gateway management.

Comparison Snapshot:

• Hosted MCP:
  • Fastest path from local MCP in Cursor/Claude to multi-user production.
  • Built-in OAuth, IDP integration, token refresh, secrets isolation, audit logs, RBAC, and SSO/SAML.
  • Deployment flexibility: public cloud, private VPC, on‑prem, or air-gapped.
• Self-hosted MCP:
  • Full control of network, infra, and runtime behavior.
  • Requires owning uptime, security patches, capacity planning, and auditability.
  • You must implement or integrate OAuth, token storage/refresh, and permissioning yourself.
• Best for: Hosted MCP if you care most about shipping a reliable multi-user agent vs. building yet another auth/runtime layer; self-hosted when your security model mandates everything run entirely under your own orchestration.

---

What does it take to implement a production-grade MCP runtime for a multi-user agent?

Short Answer: You need more than a Python script—you need user identity mapping, OAuth flows, token lifecycle management, scoped permissions, secrets isolation from LLMs, observability, and a runtime that can scale and be audited.

Expanded Explanation:
This is where many teams underestimate the lift. Running uv run server.py is not the same as running “the runtime between AI and action” for production. In a multi-user world, every tool call—Google.SendEmail, Google.CreateEvent, Gmail.ListEmails, Slack.PostMessage, Salesforce.UpdateRecord—has to:

• Run with the right user’s permissions.
• Respect scopes and tenant boundaries.
• Be observable with logs and metrics.
• Be revoke‑able if security needs to pull a plug.

Hosted MCP runtimes like Arcade ship SDK patterns to standardize this (client.auth.start(...), wait_for_completion, strongly typed tool calls) and keep credentials out of the model entirely. If you roll your own, you’re re-implementing those patterns and then layering on RBAC, SSO/SAML, tenant isolation, audit trails, and deployment tooling.

What You Need:

• Identity + auth infrastructure: OAuth integrations for systems like Google Workspace, Slack, GitHub, HubSpot, Salesforce; IDP integration; SSO/SAML; and a model to map identities to tool calls.
• Runtime + governance: A scalable MCP runtime with secrets management, audit logs, RBAC, environment isolation (prod vs staging), and a deployment story (cloud/VPC/on‑prem) that your security team signs off on.

---

Strategically, when should a team choose hosted MCP vs self-hosting for Cursor/Claude MCP in a multi-user product?

Short Answer: Use hosted MCP to get to “agents taking real actions for real users” quickly and safely; reserve self-hosting for later, when you have strong infra maturity and specific constraints that hosted options can’t meet.

Expanded Explanation:
From a product and business perspective, your competitive advantage isn’t “we built our own OAuth refresh/token store again.” It’s “our agent reliably books meetings, sends emails, updates CRM, and posts to Slack with the exact permissions each user has—and our security team can see and control all of it.”

Hosted MCP runtime:

• Lets you validate product value early: you can plug into Gmail, Google Calendar, Slack, Linear, GitHub, HubSpot, Salesforce in weeks, not quarters.
• Reduces risk: zero token exposure to LLMs, user-specific permissions instead of service accounts, and auditability built-in.
• Keeps you agent- and client-agnostic: works with Cursor, Claude, LangGraph, and more, so you’re not locked into one IDE or orchestration stack.

Self-hosted:

• Makes sense when regulatory or network constraints are very strict and you have the team to run an MCP runtime like any other core service (SLAs, on-call, security reviews).
• Is more of an infrastructure strategy than an agent strategy; you’re choosing to invest engineering cycles in the runtime rather than the agent behaviors and business logic.

Why It Matters:

• Impact on time-to-value: Hosted MCP lets you move from “local Cursor/Claude prototype” to “multi-user product in production” quickly, so you learn from real usage instead of spending months on auth plumbing.
• Impact on risk and governance: Agents that can send emails, schedule meetings, or update records without a clear authorization model are a non-starter for serious teams; hosted MCP runtimes solve that with scoped OAuth, RBAC, audit logs, and environment controls—features you’d otherwise have to build and maintain yourself.

---

Quick Recap

For Cursor and Claude Desktop MCP usage, the local, self-run server is perfect for prototyping. Once you’re building a multi-user product, the decision shifts to who runs the runtime between AI and action. Most teams pick a hosted MCP runtime like Arcade so they get user-specific permissions, OAuth flows, secrets isolation from LLMs, and governance without re‑implementing all of that in-house. Self-hosting MCP remains an option when you need maximum environment control and have the infra maturity to own auth, tokens, and runtime operations over the long haul.

Next Step

Get Started