AI Agent Trust & Governance
Build our own MCP server vs using a managed MCP runtime—how do you decide for a production agent?
8 min read
Most teams building their first MCP tools start with a simple question: should we keep rolling our own MCP server, or is it time to plug into a managed MCP runtime that handles auth, execution, and governance for us—especially once we go to production and real users?
Quick Answer: Use your own MCP server when you’re prototyping tools or need highly custom logic in one place; use a managed MCP runtime when you need multi-user authorization, reliable tool execution, and governance for production agents. In practice, most teams end up with both: custom MCP servers for domain logic, plus a runtime like Arcade sitting between the LLM and your real systems.
Frequently Asked Questions
When does a custom MCP server make sense vs a managed MCP runtime?
Short Answer: Build and host your own MCP server when you’re focused on defining custom tools and business logic; use a managed MCP runtime when you need to safely run those tools for many users, with real auth, observability, and lifecycle controls.
Expanded Explanation:
An MCP server is how you expose tools to an agent—essentially “here are the actions you can take, with these inputs and outputs.” For early experiments, standing up your own MCP server is perfect: fast iteration, custom logic, no external dependencies. The problem starts when that same server is suddenly responsible for real users, real credentials, and real systems like Gmail, Slack, Salesforce, and GitHub.
A managed MCP runtime steps in as the runtime between AI and action. It doesn’t replace your MCP servers—it orchestrates them. It handles user-specific OAuth, token refresh, permission checks, execution isolation, and audit trails, so your custom server can stay focused on: “when the agent calls Google.SendEmail, what exactly happens?” The decision point is usually the moment you need multi-user, production-grade behavior instead of a single demo agent.
Key Takeaways:
- MCP servers define tools and logic; MCP runtimes control how tools are invoked, authorized, and governed.
- Use your own server for custom tools; add a managed runtime when you care about user-specific permissions, reliability, and production controls.
How should we evaluate the process of building and running our own MCP server?
Short Answer: Treat “build our own MCP server” as a scoped engineering project: tool design, server implementation, hosting, and ongoing maintenance. It’s very doable—but it’s not the same as having a full runtime for authorization, orchestration, and governance.
Expanded Explanation:
The process to stand up an MCP server is straightforward. With Arcade’s open-source MCP framework, it’s literally:
uv tool pip install arcade-mcp
arcade new my_server
cd my_server
uv run server.py
You get zero-ceremony scaffolding: a working MCP server with tools you can customize in clean, readable Python. From there, you decide which tools to expose (e.g., internal APIs, domain-specific workflows), shape schemas so models can use them reliably, and deploy the server somewhere reachable by your MCP clients (Cursor, Claude, LangGraph, etc.).
What’s not included by default: user-specific OAuth, token storage/refresh, RBAC, SSO/SAML, or an audit trail of which user triggered which tool call. If your “build our own server” plan quietly assumes all of that will be added later, you’re actually signing up to build a runtime, not just a server.
Steps:
- Define your tools: Decide which actions agents should be able to take (e.g.,
Ticket.Create,Report.Generate,CRM.SyncCustomer) and model their input/output schemas. - Implement the MCP server: Use an MCP framework (like Arcade’s) to expose those tools with clean, descriptive schemas and test them against one or two client agents.
- Plan for hosting and evolution: Deploy the server, monitor it, and decide how you’ll add auth, permissions, and observability as usage grows—or when you’ll hand those off to a managed runtime.
What’s the real difference between an MCP server and a managed MCP runtime?
Short Answer: An MCP server is a tool provider; a managed MCP runtime is an authorization and execution engine for those tools, built for multi-user, production agents.
Expanded Explanation:
Think of an MCP server as a stateless function catalog: it says “here are 10 tools, here is how to call them.” It can be hosted by you or by a vendor. It doesn’t inherently know which human is behind each tool call or which scopes they’re allowed to use; it just executes what it’s asked to execute.
A managed MCP runtime like Arcade sits in the middle:
- It talks to the LLM/agent using MCP.
- It talks to multiple MCP servers (your custom ones + Arcade’s catalog).
- It enforces user-specific authorization, routes calls, injects credentials at runtime, and records every action.
API gateways historically tried to be that layer, but they’re request routers, not agent runtimes. They don’t understand tools, schemas, or multi-step agent plans—they just forward HTTP traffic. MCP runtimes are built specifically for “agent-safe” tool execution.
Comparison Snapshot:
- Option A: MCP server (yours or hosted):
You define tools and logic. Great for custom workflows and domain-specific operations. Limited by whatever auth and governance you manually bolt on. - Option B: Managed MCP runtime (e.g., Arcade):
You get a tool-aware execution layer: user-specific auth, scoped OAuth, IDP integration, audit logs, RBAC/SSO, and a catalog of agent-optimized tools. - Best for:
- Just MCP server: Prototypes, small internal agents, single-user or service-account scenarios where security requirements are light and you accept manual token handling.
- MCP runtime: Production, multi-user agents touching systems like Gmail, Calendar, Slack, GitHub, HubSpot, Salesforce, where security and governance are non-negotiable.
How do we actually implement a managed MCP runtime alongside our own MCP server?
Short Answer: Keep your custom MCP server as-is, then plug it into a managed MCP runtime like Arcade, which handles auth and execution. Your agents keep speaking MCP; the runtime coordinates everything.
Expanded Explanation:
The good news: you don’t throw away existing work. You treat your MCP server as one more tool source, then introduce a runtime that:
- Initiates OAuth for each user (
client.auth.start(...)+wait_for_completion). - Maps users to scopes (e.g., Gmail read-only vs send-only).
- Injects tokens and credentials into tool calls without exposing them to the LLM.
- Applies permission gates (“this agent can schedule Google Calendar events but not send emails”).
- Logs every call for later auditing.
From your agent’s perspective, it’s still “call tools over MCP.” The runtime is the piece in the middle making sure those calls are authorized, scoped, and safe.
What You Need:
- Your MCP server(s): Custom tools that represent your domain logic and internal systems, plus any third-party MCP servers you rely on.
- A managed runtime (Arcade):
- Hosted MCP support (you can still bring your own servers).
- Secure Agent Authorization: scoped OAuth, IDP integration, zero token exposure to LLMs.
- Governance: audit logs, RBAC, SSO/SAML, tenant isolation.
- Deployment flexibility: cloud, VPC, on-prem, or fully air-gapped.
How do we make a strategic call between “just our own MCP server” and adopting an MCP runtime for production?
Short Answer: If your agents touch real user data across systems like Gmail, Calendar, Slack, GitHub, HubSpot, Salesforce—or you have more than one user—you will almost certainly need a managed MCP runtime to avoid rebuilding auth, governance, and reliability infrastructure yourself.
Expanded Explanation:
The strategic decision isn’t “MCP server vs managed MCP runtime.” It’s “are we willing to become an auth and runtime team, or do we want to stay focused on agent behavior and business outcomes?”
Most agent projects don’t fail because GPT-4 can’t reason. They fail because:
- Service-account bots don’t match real user permissions.
- Refresh tokens silently break over weekends.
- Security teams block rollout when there’s no clear authorization model, no audit trail, and no integration with existing OAuth/IDP flows.
- “API wrapper” tools behave unpredictably under agents, driving up costs and flakiness.
A managed MCP runtime like Arcade is deliberately built around those pain points:
- Agents act with user-specific permissions—not service accounts.
- Credentials never flow through the LLM—tokens are injected at runtime, stored and refreshed behind the scenes.
- Tool schemas are designed for agents, not humans, reducing vague calls and retries.
- You get lifecycle governance: audit logs, RBAC/SSO, tenant isolation, and a runtime your security team can actually review and approve.
Strategically, that means you can treat “MCP runtime between AI and action” as a solved problem and spend your energy where it matters: better tools, better plans, and better outcomes for your users.
Why It Matters:
- Impact on speed: You ship agents that move from chat to action in days, not quarters, because you’re not rebuilding OAuth, token management, and governance every time you add a new tool or system.
- Impact on trust and scale: You can confidently move beyond demos—multi-user agents sending Gmail, scheduling Calendar events, posting to Slack, updating Salesforce—knowing every action is authorized, auditable, and aligned with your existing security model.
Quick Recap
A custom MCP server and a managed MCP runtime solve different problems. Your server defines what an agent can do—the tools, schemas, and domain logic. A managed runtime like Arcade defines how and under whose authority those tools run, at scale, in production. Use your own MCP server for custom logic and early experiments; adopt a managed MCP runtime when you need multi-user, user-specific permissions, reliable tool execution, and enterprise-grade governance. In practice, the winning pattern for production agents is both: your MCP servers plus a runtime between AI and action.