Zuplo
API Gateway Comparisons

Zuplo vs
Obot

  • SOC 2 Type II
  • 99.999% SLA
  • 300+ edge locations

An MCP Gateway Alternative to Obot's Open-Source Kubernetes-Native MCP Platform

Talk to an Architect
Feature
Zuplo
Obot
Product Category
MCP Spec Compliance
OAuth 2.1 Authorization Server
Credential Models for Upstream MCP Servers
Virtual MCP Servers / Federation
API to MCP Ingestion
AccuWeather
Read the Case Study
Blockdaemon
Read the Case Study
Lake Michigan Credit Union
Read the Case Study
Finsolutia
Read the Case Study
VNDR
Read the Case Study
Mews
Read the Case Study
Yext
Read the Case Study
Zumiez
Read the Case Study

What's wrong with Obot

Obot's key limitations for modern engineering teams

The forces driving enterprises off Obot in 2026 — operational tax, plugin sprawl, retrofitted AI, and pricing that doesn't predict.

Kubernetes-Native Self-Host in Production

Obot's production deployment is self-hosted on Kubernetes with an external Postgres database, S3-compatible object storage, and a cloud KMS (AWS KMS or Google Cloud KMS) for encryption at rest. A Helm chart is provided. Teams without an existing Kubernetes practice carry the operational cost of running this stack themselves. Obot now offers a managed hosted option, Obot Cloud, with a free two-week trial of a dedicated gateway environment, but specific SLA, pricing, and regional data-residency terms are not publicly documented.

Bundled Platform, Not a Focused Gateway

Obot is positioned as a complete MCP platform with four components: MCP Gateway, MCP Hosting, MCP Registry, and the Obot Agent chat client (replacing the deprecated Obot Chat), plus an MCP Server Shim sidecar. Recent releases grew the bundle further: skills distribution and device management for local AI clients, and an LLM Gateway that proxies OpenAI- and Anthropic-compatible model traffic for external coding agents. Teams that want a thin MCP gateway sitting in front of existing APIs and SaaS MCP servers, without adopting an agent runtime, a server hosting layer, a model proxy, and an end-user chat surface, may not need most of the bundle.

Compliance Posture Is BYO

Obot has not publicly published its own SOC 2 Type II, HIPAA, ISO 27001, or FedRAMP attestations. The stated posture is that data stays in the customer's environment when self-hosted, so the customer owns the broader compliance program and evidence collection. SLA and 24/7 support terms for Obot Enterprise Edition are not publicly listed.

No Native OpenAPI-to-MCP Ingestion

Obot's model is bring-your-own MCP server: tool servers run in Docker or as Kubernetes Deployments in a dedicated namespace and connect into the gateway. A native OpenAPI-to-MCP generator is not surfaced in public Obot docs. Teams with existing REST APIs typically author MCP servers separately, or wrap their APIs in a container before exposing them through Obot.

Why Zuplo

Built for teams replatforming off Obot

Managed, modern API management with predictable economics across procurement cycles — no operator overhead, no plugin sprawl, no consumption-pricing surprises.

Product Category

Focused MCP Gateway extending an API platform vs. bundled Kubernetes-native MCP platform with hosting, registry, and agent

MCP Spec Compliance

MCP authorization spec 2025-11-25 over streamable HTTP vs. MCP-standards compliance over streamable HTTP without a publicly pinned spec date

OAuth 2.1 Authorization Server

Documented OAuth 2.1 AS RFC stack (7591/8414/9728/8707) plus 11 first-class IdP presets vs. OAuth 2.1 with DCR + token-exchange shim and a standalone OAuth proxy

A solutions architect can walk you through your current Obot setup, surface the biggest operational tax, and map a migration path — no slide deck required.

Talk to an Architect

Enterprise ready

Production-ready for regulated and high-volume workloads

Compliance & Audit

  • SOC 2 Type II audited annually
  • Third-party penetration test reports available under NDA
  • GDPR-aligned data processing
  • Audit logs across the control plane
  • API governance with policy enforcement

Identity & Access

  • SAML SSO and SCIM provisioning
  • Role-based access control across organizations, projects, and environments
  • Service-account credentials with scoped permissions
  • API key metadata for downstream authorization

Deployment Flexibility

  • Managed edge across 300+ locations — global by default
  • Managed dedicated single-tenant on AWS, Azure, GCP, Akamai, or any major cloud
  • Self-hosted on Kubernetes with full control plane
  • Bring-your-own-cloud for data residency requirements

Support & Success

  • Up to 30-minute response SLA on Enterprise
  • 24/7/365 emergency hotline for critical incidents
  • Named technical account manager
  • Architecture and migration professional services

Built for the AI era

Built for MCP and agentic API workloads

Zuplo's MCP Gateway extends a programmable API gateway with a complete OAuth 2.1 authorization server documented to the MCP authorization spec revision 2025-11-25, federated virtual MCP servers with capability allow-lists, per-user and shared-OAuth upstream modes, and audit logs on every tool call.

MCP Gateway with OAuth 2.1 AS

Bundled OAuth 2.1 authorization server with DCR (RFC 7591), PKCE S256, AS metadata (RFC 8414), protected resource metadata (RFC 9728), and resource-indicator-scoped tokens (RFC 8707).

Federated virtual MCP servers

Bind any route to an upstream MCP server and compose virtual servers using capability allow-lists over tools, prompts, and resources — without forking the upstream.

Per-user and shared-OAuth upstreams

Two OAuth modes via `mcp-token-exchange-inbound` — per-user OAuth and shared-OAuth — plus upstream API key policies, configured per route in JSON.

Monetization for API and MCP traffic

Native API monetization (Beta) with per-token metering for the AI Gateway and hierarchical budgets at org/team/app levels.

See it in action

See Zuplo running on your stack

A 30-minute working session with a Zuplo solutions engineer. Bring an OpenAPI spec or a Kong route definition and walk away with a working preview.

Talk to Sales Compare features

Side by side

Feature-by-feature comparison

Feature
Zuplo
Obot
Product Category
Programmable API gateway and management platform that handles REST and GraphQL traffic and exposes a dedicated MCP Gateway on the same runtime, policy pipeline, and OpenAPI workflow.
Open-source MCP platform bundling four headline components — MCP Hosting (runs MCP servers in Docker or Kubernetes), MCP Registry, MCP Gateway, and the Obot Agent client — plus a protocol-aware MCP Server Shim sidecar that runs alongside every MCP server and a newer LLM Gateway that proxies OpenAI- and Anthropic-compatible model traffic for external clients.
MCP Spec Compliance
Targets the MCP authorization spec revision 2025-11-25 over streamable HTTP, with the gateway requiring the `MCP-Protocol-Version: 2025-11-25` header. Tested with Claude Desktop, Claude Code, Cursor, ChatGPT (including the OpenAI Apps SDK), VS Code, and MCP Inspector.
Describes itself as MCP-standards-compliant. All upstream servers are re-exposed via streamable HTTP from the gateway regardless of their underlying transport. Tested clients include Claude Desktop, Cursor, VS Code, ChatGPT, GitHub Copilot, and Cline, plus workflow frameworks n8n and LangGraph. Obot has not publicly pinned a specific MCP spec revision.
OAuth 2.1 Authorization Server
Complete OAuth 2.1 authorization server bundled by default. Dynamic Client Registration per RFC 7591 (accepted at `/oauth/register`), PKCE S256 required as the MCP spec mandates, authorization server metadata at `.well-known/oauth-authorization-server` (RFC 8414), protected resource metadata at `.well-known/oauth-protected-resource/{routePath*}` (RFC 9728), and tokens bound to a route's `operationId` via resource indicators (RFC 8707). First-class IdP presets ship for Auth0, Cognito, Clerk, Google, Keycloak, Logto, Entra, Okta, OneLogin, PingOne, and WorkOS, plus a generic OIDC fallback.
OAuth 2.1 with PKCE. A standalone `mcp-oauth-proxy` ships under Apache 2.0 as a full OAuth 2.1 authorization server. Obot builds a Dynamic Client Registration shim (RFC 7591) in front of providers that do not support DCR natively, notably Microsoft Entra, and the MCP Server Shim handles OAuth 2.0 Token Exchange (RFC 8693). Explicit conformance to RFC 8414, RFC 9728, or RFC 8707 is not publicly documented.
Credential Models for Upstream MCP Servers
Two OAuth modes ship today via the `mcp-token-exchange-inbound` policy — per-user OAuth and shared-OAuth (admin configures one upstream client, users still authenticate individually). Upstream API keys are configured with separate policies (`set-upstream-api-key-inbound`, `set-headers-inbound`) and combine with the OAuth modes on the same route, all in JSON config.
Supports per-user OAuth, a shared OAuth grant model where the admin configures a single client ID and secret but users still each run the OAuth flow, and self-authenticating servers where the MCP server handles its own multi-tenancy. API keys for machine-to-machine callers are supported. A per-user or shared vault-stored upstream API key model is not surfaced as a primary path; Obot's story is OAuth-centric.
Virtual MCP Servers / Federation
Bind any route to an upstream MCP server and compose virtual MCP servers using the `mcp-capability-filter-inbound` policy, which applies exact allow-lists over upstream tools, prompts, and resources — without forking the upstream. Routes and policies are configured in JSON (`routes.oas.json`, `policies.json`) and deployed via GitOps.
Composite servers combine one or more single-user, multi-user, and remote MCP servers into a single virtual MCP server. Administrators select exactly which tools from each server to expose, override tool names and descriptions, and apply per-group access policies. Obot's Git-backed catalog workflow covers standard and multi-user server templates but does not support the composite runtime, so composite servers are managed through the admin UI.
Pre-Built Upstream MCP Catalog
Federates any MCP server reachable over streamable HTTP. Documented worked examples cover Linear, Stripe, and Notion, with broader use cases cited across Linear, Notion, Stripe, GitHub, Slack, and internal services.
Publishes 70+ pre-built enterprise integrations across Microsoft, Google, Salesforce, Atlassian, AWS, and more, along with a community catalog repo at `obot-platform/mcp-catalog`.
API to MCP Ingestion
Zuplo's separate MCP Server handler turns OpenAPI operations into MCP tools natively in the same project as the MCP Gateway, so existing REST APIs become MCP servers without authoring separate tool code. The MCP Server handler and the MCP Gateway can coexist in one Zuplo project.
Bring-your-own MCP server via Docker or Kubernetes. Tool servers can be Node.js, Python, or container-based, and filter webhooks can be written as MCP servers. A native OpenAPI-to-MCP generator is not surfaced in public Obot docs.
Deployment Models
Managed edge across 300+ data centers (default), managed dedicated single-tenant on AWS, Azure, GCP, Akamai, or Equinix, and self-hosted Kubernetes when full data residency is required.
Self-hosted on Docker for development or Kubernetes for production, with an external PostgreSQL 17+ database (with pgvector), S3-compatible object storage (or Azure Blob) for legacy chat workspace and workflow artifacts, and a cloud KMS (AWS KMS, Azure Key Vault, or Google Cloud KMS) for encryption at rest. A Helm chart is available at `charts.obot.ai`. Obot also offers a managed hosted option, Obot Cloud, with a free two-week trial of a dedicated gateway environment, but specific single-tenant SLA, pricing, and regional data-residency terms are not publicly documented.
Licensing and Open Source
Commercial platform. Self-hosted Kubernetes deployment is available on Enterprise plans.
Core `obot` repository is MIT licensed. Adjacent repositories (`nanobot`, `mcp-oauth-proxy`, and the now-archived `tools`) ship under Apache 2.0; the `mcp-catalog` repository does not publish a LICENSE file. Obot AI is a Linux Foundation AAIF Silver member and donated the MCP Dev Summit to the foundation.
Enterprise Identity (SSO + RBAC)
Enterprise SSO via Auth0 supports common identity providers including Azure AD, Okta, and Google Workspace. Account- and project-scoped roles (Admin, Developer, Member) with environment-scoped permissions (Production, Preview, Development) are included on Enterprise.
SSO via OIDC and OAuth: GitHub and Google ship in the open-source build; Okta, Microsoft Entra, Auth0, and JumpCloud are gated behind Obot Enterprise Edition. RBAC ships with predefined roles (Owner, Admin, Power User+, Power User, Basic User, Auditor) that extend to per-MCP-server and per-composite-server policies. SAML and SCIM support are not surfaced in public docs.
Compliance and Audit Readiness
SOC 2 Type II accredited, third-party penetration test reports available under NDA, audit logs across the control plane, and GDPR rights honored in the privacy policy. Trust report at trust.zuplo.com.
Obot has not publicly published its own SOC 2 Type II, HIPAA, ISO 27001, or FedRAMP attestations. The stated posture is that data stays in the customer's environment when self-hosted, so the customer owns the compliance program and evidence collection. Comprehensive audit logging is provided through the MCP Server Shim.
Observability
Typed analytics events across three families (`mcp_request`, `capability_invocation`, `auth_event`), trace-ready structured logs with tenant, MCP session, capability, latency, and failure origin, log destinations including AWS CloudWatch, Datadog, Dynatrace, Google Cloud Logging, Loki, New Relic, Splunk, and Sumo Logic plus OTLP exporters to Honeycomb and other OpenTelemetry-compatible backends, and standardized reason codes (`missing_token`, `invalid_audience`, `connect_required`, `upstream_timeout`, and more) on every failure.
The MCP Server Shim logs every gateway request including filter decisions. A native admin dashboard provides CPU and memory capacity monitoring across MCP servers. Filter webhooks enforce PII redaction and content policy. OpenTelemetry HTTP-request tracing instrumentation is included; dedicated Datadog and Honeycomb exporter integrations are not surfaced in public docs.

What our customers say

Enterprises using Zuplo for API and MCP traffic

Finsolutia

Financial Services

0

Code changes

Exposed mortgage-servicing REST APIs as MCP tools in hours, without touching a line of application code.

Read the Finsolutia case study →

Blockdaemon

Blockchain Infrastructure

90%

Fewer hardware nodes

Serves billions of API calls a month to customers including Goldman Sachs, Microsoft, and J.P. Morgan.

Read the Blockdaemon case study →

Duck Creek Payments

Insurance & Payments

Minutes

To production

Pushes payment API changes to production in minutes rather than the hours or days their previous setup required.

Read the Duck Creek Payments case study →

Trusted for regulated and high-volume workloads

SOC 2 Type II Third-party penetration testing GDPR-aligned 24/7/365 emergency hotline
300+ Global edge locations
Billions API requests served / month
Up to 99.999% Enterprise uptime SLA
<20s Global deploy time

Frequently Asked Questions

Common questions about Zuplo vs Obot.

Ready to talk to an expert?

Book a call with a solutions architect for a tailored walkthrough — SOC 2 controls, dedicated deployment, AI Gateway, and enterprise support. Or start free and explore the platform yourself.

Book a Call Start for Free