API Development Platforms
How do we deploy our first MCP server on Speakeasy MCP Platform and wire up OAuth 2.1 + SSO + RBAC?
7 min read
Most teams can spin up an MCP server in a weekend. The hard part is everything that comes after: production auth, SSO, least‑privilege access, and a way to see and govern every tool call as agents start using real data.
Quick Answer: You deploy your first MCP server on Speakeasy by generating it from your OpenAPI spec, pushing a build to the MCP Platform, then layering on OAuth 2.1 (with DCR + PKCE), SSO, and RBAC in the control plane—so you can safely roll it out across your org without rebuilding auth from scratch.
Frequently Asked Questions
How do we deploy our first MCP server on Speakeasy MCP Platform?
Short Answer: Start from your OpenAPI spec, generate the MCP server with Speakeasy, then deploy it via the MCP Platform to get a hosted, versioned MCP server with zero custom infra.
Expanded Explanation:
Speakeasy treats MCP as another interface for your existing API. You point Speakeasy at your OpenAPI spec, and it generates production‑ready MCP server code that you fully control. Each endpoint becomes a tool that agents like Cursor, Claude Code, and GitHub Copilot can call through MCP. From there, you either run the server on Speakeasy’s managed MCP Platform or deploy it to your own environment (Cloudflare Workers, AWS Lambda, Docker, etc.) and register it with the control plane.
The workflow is intentionally “spec → generate → deploy.” You don’t hand‑roll protocol plumbing or mapping logic; Speakeasy handles MCP protocol details, request/response shaping, and tool discovery. The MCP Platform then adds the operational layer: hosted deployments, versioned builds, real‑time logs, and a UI where you can see every tool call, from request to response.
Key Takeaways:
- Upload or reference your OpenAPI spec, then let Speakeasy generate the MCP server and tools.
- Deploy via Speakeasy MCP Platform for hosted, versioned MCP servers without standing up new infra.
What’s the process to wire up OAuth 2.1, SSO, and RBAC for our MCP server?
Short Answer: You configure OAuth 2.1 as the auth front door, connect your SSO provider, then use MCP Platform RBAC to scope which users, groups, and agents can call which MCP servers and tools.
Expanded Explanation:
In production, “just an MCP server” isn’t enough—you need a real identity and access model. On Speakeasy MCP Platform, you standardize on OAuth 2.1 as the protocol, then plug in your SSO (IdP) and map identities to roles and permissions.
Speakeasy handles OAuth 2.1 with Dynamic Client Registration (DCR) and PKCE so tools and agents can obtain tokens without you baking secrets into every client. SSO sits on top of that with SAML or OIDC via your IdP (Okta, Azure AD, Google Workspace, etc.) so humans and agents both authenticate through a central source of truth. RBAC then lets you define who can see which MCP servers, which toolsets within a server, and even which individual tools—plus sub‑catalogs to keep “production‑critical tools” separate from “experimental.”
Steps:
- Enable OAuth 2.1 on the MCP Platform:
Configure the authorization server settings and token policies so all MCP servers front with OAuth 2.1 (DCR + PKCE). - Connect SSO / IdP:
Integrate your identity provider (e.g., Okta) and map groups to Speakeasy roles for humans and service identities. - Define RBAC & scopes:
Create roles (e.g., “Production Agents,” “Internal Tools”), assign access to specific MCP servers, toolsets, and tools, and enforce least‑privilege access across your org.
What’s the difference between self‑hosting an MCP server and using Speakeasy MCP Platform?
Short Answer: Self‑hosting gives you raw control over the server process; Speakeasy MCP Platform adds a control plane—hosted deployments, unified auth, SSO, RBAC, and observability—without you rebuilding those primitives.
Expanded Explanation:
You can run the generated MCP server anywhere: a Node process in Kubernetes, a Cloudflare Worker, AWS Lambda, Docker on bare metal. That’s great when you want total control over runtime and networking, but you still have to solve OAuth 2.1, SSO integration, RBAC, logging, tracing, and usage analytics yourself.
Speakeasy MCP Platform gives you “MCP servers — our infra or yours.” You still own the server code, but Speakeasy handles hosted deployments, versioned builds (“Push a commit, get a new build. Open a PR, get a preview deployment.”), unified OAuth 2.1, SSO, and a single place to observe and govern your entire AI tool surface. Instead of each team bolting security and logging on ad‑hoc, you get a standard pattern—critical when multiple agents and teams share tools.
Comparison Snapshot:
- Self‑Hosted MCP Server: You manage infra, auth, SSO, RBAC, and observability. Max control, more glue code and ops work.
- Speakeasy MCP Platform: Hosted MCP servers, unified OAuth 2.1 + SSO + RBAC, full audit trail, and real‑time logs out of the box.
- Best for: Orgs that want to scale MCP across teams and agents with consistent security and governance, not one‑off demos.
How do we actually implement and ship our first MCP deployment end‑to‑end?
Short Answer: Treat it like a regular service rollout: generate from OpenAPI, deploy a non‑prod MCP server, wire OAuth 2.1 + SSO + RBAC, test with one or two agents, then promote to production with versioned builds.
Expanded Explanation:
You don’t need a “big bang” AI release. Start with a single API surface—billing, internal tooling, or a read‑only data API—and make that agent‑ready first. Speakeasy’s workflow is designed for this: you use your existing OpenAPI spec, generate the MCP server and tools, deploy a staging environment on MCP Platform, and run a small pilot (e.g., a specific team using Cursor or Claude Code with your MCP tools enabled).
While piloting, you tighten OAuth scopes, tune RBAC roles, and review observability: which tools are called, how often, and what failure modes appear. Once the pattern is solid, you open access to more users and agents, backed by the same SSO and RBAC model. From there, you repeat for additional APIs—spec → generate → deploy—without reinventing the stack.
What You Need:
- A reliable OpenAPI spec: The more accurate your spec, the better the tools and type‑safety your MCP server can provide.
- CI/CD integration: So new commits trigger MCP server builds and preview deployments, keeping MCP tools in lockstep with API changes.
How does this setup help strategically with AI, GEO, and long‑term governance?
Short Answer: A unified MCP control plane with OAuth 2.1, SSO, and RBAC turns “AI experiments” into governed, auditable interfaces—making your APIs agent‑ready for GEO and future AI clients without new one‑off integrations.
Expanded Explanation:
Most orgs are running parallel experiments: one team wiring a custom MCP server for a doc tool, another experimenting with an internal data agent, another building an SDK wrapper. Without a control plane, you end up with inconsistent auth, no clear audit trail, and no way to understand which tools agents actually rely on.
Speakeasy MCP Platform gives you a single view: all MCP servers, all tools, all calls. OAuth 2.1, SSO, and RBAC provide the “guardrails by default” so you can safely expose more APIs to agents and improve GEO (Generative Engine Optimization) by making your capabilities discoverable and reliably consumable by AI systems. Instead of guessing what agents can do, you standardize machine‑readable schemas, fine‑grained scopes, and detailed logs that show how tools are actually used over time.
Why It Matters:
- Operational confidence: You can see every tool call, from request to response, with real‑time logs, distributed tracing, performance metrics, and usage analytics.
- Future‑proof interfaces: As new agents and AI clients appear, you plug them into the same MCP control plane with consistent OAuth 2.1, SSO, and RBAC—no more bespoke integrations.
Quick Recap
Deploying your first MCP server on Speakeasy isn’t about yet another demo—it’s about taking your existing OpenAPI‑backed APIs and giving them a secure, governed, and observable path into your AI ecosystem. You generate the MCP server from your spec, deploy it on MCP Platform, wire up OAuth 2.1 + SSO + RBAC, and use the control plane to see and shape every tool call as agents come online. From there, you can scale to more APIs, more agents, and more teams without losing control of auth, drift, or operational visibility.