You can absolutely build and run your own MCP server with the official SDK. This page lays out, as plainly as we can, what that path looks like versus what you get out of the box here — so you can pick the right tool for where you are.
You write the server with an MCP SDK (e.g. the TypeScript or Python SDK), define tools by hand, host it yourself, and build any multi-tenancy, auth, and governance you need on top. Full control, full responsibility.
You point at an OpenAPI spec or a REST base URL; the platform generates typed tools, runs a hosted multi-tenant runtime with Postgres RLS isolation, and enforces boundary/risk policy on every call — with a marketplace for discovery.
Both are legitimate approaches. The right one depends on how many tenants you serve, how sensitive the underlying API is, and how much infrastructure you want to own.
| Dimension | DIY (own MCP SDK server) | MCP Platform |
|---|---|---|
| Setup time | Days to weeks — write tool handlers per endpoint, wire transports, stand up hosting, add TLS. | Minutes — import an OpenAPI spec or REST base URL and tools are generated automatically. |
| Multi-tenant isolation | Not included. You design and implement tenant scoping yourself — typically app-level WHERE tenant_id = ? filtering, which is easy to get wrong in one route and hard to audit. | Built in. Postgres Row-Level Security enforces tenant_id on every read/write at the database layer, not just in application code. |
| Governance / risk controls | None by default. You'd need to build your own policy layer to classify tools as safe vs. destructive, gate approvals, or scope what an agent can call. | Boundary system (internal / partner / public) plus per-tool risk levels, with allow / confirm / approve / deny decisions enforced by the runtime on every tools/call. |
| Hosting & ops burden | All yours: process management, scaling, TLS, patching, monitoring, incident response, upgrades to the MCP spec/SDK over time. | Hosted runtime, managed upgrades, and audit logging included. You focus on the API contract, not the server process. |
| Discoverability | You distribute the endpoint URL yourself — READMEs, docs, word of mouth. | A marketplace/catalog where servers can be listed and installed by URL, with visibility you control. |
| Pricing model | "Free" in license terms, but you pay in engineering time plus your own infrastructure bill (compute, DB, TLS, on-call). | Usage-based: free tier to start, then priced by tenants provisioned and governed calls — see pricing. |
You have a single internal API, one consumer, no multi-tenant requirement, and an engineering team that wants full control over the transport and tool definitions — or you're prototyping something highly custom that doesn't map cleanly to an OpenAPI contract.
You need to expose one or more APIs to AI agents across multiple tenants or customers, you care about row-level data isolation and auditability, or you want to control what risk level of tool an agent is allowed to invoke without hand-building a policy engine.
Bring an OpenAPI spec, get a governed, multi-tenant MCP server — no infrastructure to run.
Start free