What is an MCP Gateway? Architecture, Security, and Use Cases

MCP server vs. MCP gateway

An MCP server is a process that exposes tools to AI clients. Your AI calls get_schema and the server returns your database schema. Simple.

The problem starts when you have more than one person, more than one database, or any concern about what the AI is actually doing with your data.

A standard MCP server runs as a local process (stdio). You pass it a connection string in your config file. It has full access to whatever that connection string allows. There's no authentication, no permission scoping, no record of what happened.

An MCP gateway sits between AI clients and your data sources. It adds a layer: auth, permissions, routing, logging. The AI talks to the gateway over HTTP. The gateway talks to the database. You control what happens in between.

The architecture

┌────────────┐     HTTPS      ┌─────────────┐     SSL      ┌──────────────┐
│  Cursor    │ ──────────────> │  MCP        │ ──────────> │  PostgreSQL  │
│  Claude    │   MCP protocol  │  Gateway    │  connection  │              │
│  VS Code   │ <────────────── │             │ <────────── │              │
└────────────┘                 │  - Auth     │              └──────────────┘
                               │  - Scoping  │
                               │  - Logging  │
                               │  - Routing  │
                               └─────────────┘

With a direct MCP server, the architecture is:

┌────────────┐     stdio       ┌─────────────┐     direct   ┌──────────────┐
│  Cursor    │ ──────────────> │  MCP Server │ ──────────> │  PostgreSQL  │
│            │ <────────────── │  (local)    │ <────────── │              │
└────────────┘                 └─────────────┘              └──────────────┘

The key difference: with stdio servers, every developer machine has the connection string. With a gateway, developer machines only have an API key scoped to what that developer is allowed to do.

What a gateway adds

Authentication

Direct MCP servers have no auth. Anyone who can read the config file can access the database. That's fine when you're the only person working on the project. It's a problem when there's a team.

A gateway authenticates every request. API keys, OAuth 2.0 with PKCE, or both. You issue keys per developer or per tool. Revoke one key and that access path is gone, without changing the database password or rotating credentials across every team member's machine.

Permission scoping

This is the big one. A direct MCP server gives the AI whatever access the connection string allows. Usually that's the application user, which has read/write on everything.

A gateway lets you create multiple access scopes from a single database connection:

• Read-only for the majority of AI coding work. Schema browsing and SELECT queries only.
• Read-write on specific tables for a developer working on a particular feature.
• Full access for the tech lead who needs DDL capabilities.
• Custom scopes where table X is visible but table Y isn't. Useful for hiding PII-heavy tables from AI.

Each scope is enforced at the gateway level. The AI never sees the tables it's not allowed to see. Queries are parsed and validated before they hit the database. A blocked query gets returned to the AI with an explanation of what permission is missing, so it can adjust.

Audit trail

With a direct MCP server, there's no record of what the AI did. You won't know which developer's AI ran a DELETE on the wrong table at 3am unless you're tailing PostgreSQL query logs.

A gateway logs every interaction: query text, execution time, row count, which API key was used, whether the query was allowed or blocked, and which permission rule was involved.

This isn't just nice to have. If your team uses AI tools against a database with real customer data, you'll need this for compliance. And you'll want it the first time something goes wrong.

No credentials on developer machines

With stdio-based MCP servers, every mcp.json file contains a database connection string. That string lives in ~/.cursor/mcp.json, committed to dotfiles repos, copied across machines. If a developer's laptop is compromised, the attacker has direct database access.

With a gateway, the developer's config contains:

{
  "mcpServers": {
    "production-db": {
      "url": "https://api.datamcp.app/api/mcp/abc123",
      "headers": { "Authorization": "Bearer sk_live_dev_key" }
    }
  }
}

The API key can only do what its permission scope allows. Revokable instantly. No database password exposed.

When you don't need a gateway

Not every setup needs a gateway. You probably don't need one if:

• You're the only person working on the project
• The database is local/disposable (dev/test data you can recreate)
• You don't care about logging what the AI does
• You're comfortable with the connection string being in your config file

In these cases, a direct stdio MCP server like CrystalDBA's Postgres MCP Pro or DBHub is simpler and free. Install it, point it at your database, done.

When you need a gateway

A gateway becomes necessary when:

• Multiple developers need different access levels to the same database
• Multiple AI tools (Cursor, Claude, VS Code) each need their own permission scope
• Staging or production databases with real data are involved
• Compliance requires an audit trail of AI-executed queries
• Security policy prohibits database credentials on developer machines
• You want to revoke access without rotating credentials everywhere

The gateway landscape in 2026

The MCP gateway market is still forming. The main players:

Kong MCP Gateway is enterprise-grade and fits organizations already using Kong for API management. It's a full control plane with routing, auth, and observability.

MintMCP focuses on compliance. SOC 2 Type II certified, tamper-proof logging, transforms local MCP servers into managed endpoints.

Composio takes a broader approach with 500+ managed integrations (not just databases). Unified auth across all tool connections.

DataMCP is purpose-built for PostgreSQL. If your primary use case is "give AI tools access to our PostgreSQL databases with permission control", it's the most focused option. Per-table permissions, team roles, AI-generated schema descriptions, and a query audit trail.

The right gateway depends on your stack. If you're running 15 different MCP servers and need centralized routing, Kong or Composio. If your main concern is PostgreSQL access for a development team, DataMCP does that specific thing well.

Getting started

If you want to try the gateway approach with PostgreSQL:

1. Sign up at dashboard.datamcp.app
2. Add your PostgreSQL connection
3. Create an MCP link with read-only permissions
4. Add the URL to your Cursor/Claude/VS Code config
5. Check the Activity tab to see what your AI is doing

Free tier covers 1 connection and 1 MCP link. Enough to see whether the gateway approach makes sense for your workflow before committing to anything.