MCP Gateway vs MCP Server: Central Control Is Not the Tool Endpoint

Every MCP deployment needs a server to expose capabilities, but it needs a gateway only when several client-server paths require a shared route for identity, policy, discovery, or observability.

TL;DR: Use servers to implement tools, resources, and prompts; add a gateway when centralized control is needed, then verify that direct, local, and alternate paths cannot bypass the intended policy.

Draw the actual connection graph

Start with connections, not product boxes. A gateway can govern only the paths that traverse it, while each server still owns the capability implementation behind that route.

Map every client, transport, gateway, server, credential exchange, and target. Include local process connections and direct server endpoints. The diagram is only a hypothesis until each route produces an observed result and a responsible owner.

Separate capability and route ownership

The client, gateway, server, and target participate in one operation, but they do not own the same decision. Separating their responsibilities prevents “the gateway handles it” from hiding weak server validation or downstream authorization.

The server owns capability behavior

The Model Context Protocol specification defines servers as providers of protocol capabilities. A server exposes tools, resources, or prompts and implements or delegates their behavior. It owns capability definitions, descriptions, schemas, server-side validation, downstream credentials, target calls, errors, and returned results.

Server ownership includes source, dependencies, build, deployment, configuration, descriptions, schemas, and downstream permissions. A gateway may inspect declared metadata, but it cannot prove that an implementation has not changed its destination or added a side effect behind the same schema.

The target system receives the real read or write: database, repository, ticket system, browser, cloud API, filesystem, or another service. Target-side authorization must enforce tenant, object, action, and data scope. A gateway record that says “allowed” does not prove the target received only the intended change.

Servers also own result content. A compromised target or server can return indirect instructions or sensitive data that influence the agent's next step. Label provenance, restrict returned data, and reevaluate policy before later side effects.

The gateway owns routed coordination

The Kong guide to MCP gateways describes a gateway as a centralized intermediary for MCP access and policy. Depending on the product and deployment, a gateway can centralize routing, server discovery, identity exchange, tool exposure, quotas, approvals, protocol translation, and trace collection for paths that traverse it.

Routing can hide server topology and support controlled migration. Tool filtering can expose only capabilities allowed for a user, tenant, or workflow. Rate limits can constrain loops and fan-out. Central logs can connect clients, servers, tools, and decisions when the routed traffic carries stable identity.

Identity brokering can reduce credentials distributed to clients. The buyer must verify which user or workload the server and target actually receive. A shared gateway credential can erase accountability if delegation is not preserved.

Aggregation has a security tradeoff. Combining many servers behind one endpoint simplifies discovery while enlarging the capability set visible to an agent. Apply least privilege to tool exposure, not only connection access. Test whether one client or prompt can enumerate or invoke tools outside its task.

Decide whether the gateway route is enforceable

A gateway becomes a control only when required traffic cannot silently avoid it. Inventory direct server configuration, local process transports, cached endpoints, alternate clients, emergency routes, and direct target API access. Mark each path as mandatory, optional, denied, invisible, or protected by a separate control.

Local servers are a distinct boundary. A client may launch a process with filesystem, environment, and user permissions without crossing a network gateway. Record allowed executables, arguments, working directories, environment variables, child processes, and local destinations.

Policy quality depends on trustworthy context. Ask whether user identity, workload identity, server identity, tool, arguments, target, data class, and action are independently verified or merely asserted by the client. High-impact actions can require approval or target-side authorization beyond the route decision.

The gateway cannot prove user intent. A model can choose a valid tool because of an indirect instruction. Preserve the initiating user, trusted and untrusted sources, proposed action, approval, and policy outcome. Authenticated traffic is not automatically authorized intent.

Availability is part of enforcement. Test gateway timeout, malformed policy response, identity-provider failure, server timeout, and target failure. Document fail-open, fail-closed, retry, fallback, and duplicate-side-effect behavior. A direct fallback can convert an outage into a policy bypass.

Centralization also increases operational impact. A bad policy, expired certificate, routing error, or compromised gateway can affect many clients and servers. Separate administration, stage policy changes, preserve rollback, and monitor abnormal discovery and invocation patterns.

Route exceptions need owners, approved scope, expiry, and a regression test. Gateway and server records should join on connection, server version, tool, user delegation, policy decision, downstream identity, target request, and side effect.

Apply the LLM agent exploit vectors to both route and capability boundaries: descriptions and results can carry indirect instructions, while delegated identities, target data, and side effects determine impact beyond the gateway decision.

Where AgentGuard fits

AgentGuard can add evidence before and during a bounded MCP path. Deep Scan evaluates documented MCP servers and adjacent agent components; Runtime Guard can decide selected high-risk actions on supported integrations. Neither function turns AgentGuard into the gateway, server implementation, or target authorization layer.

Public evidence does not show every direct, local, gateway-routed, or alternate MCP call passing through AgentGuard. Test the exact client host, server version, identity, tool, target, and effect. Retain gateway, server, downstream authorization, network, and bypass controls for the rest of the path.

Evaluate Deep Scan against the exact server package, configuration, descriptions, schemas, and version. Evaluate Runtime Guard against the exact action path. Connect those results with stable component and trace identifiers, but do not describe them as complete gateway coverage.

The enterprise AI agent security best practices ownership map helps split client configuration, gateway operations, server code, downstream identity, and incident response.

Compare purchase evidence by layer

Fix the proof fields before comparing feature lists. A client or gateway record should identify authenticated actor, delegated identity, exposed capability set, route, policy version, decision, reason, transformed request, and trace. A server record should add component version, schema validation, selected implementation, downstream credential scope, target request, error, and result. A final-state record should show the actual side effect.

Compare route coverage as an inventory. List clients, hosts, transports, gateway endpoints, server endpoints, local processes, fallback routes, and direct target access. A gateway cannot receive complete coverage credit because one client was successfully configured.

Compare capability coverage separately. List tools, resources, prompts, server versions, target systems, data classes, and read or write effects. Ask which functions the gateway can discover, filter, transform, approve, block, or merely log, and which remain server- or target-owned.

Identity evidence must survive the route. Verify client authentication, user delegation, workload identity, gateway credentials, server identity, downstream token scope, target principal, and revocation behavior. Require one trace that proves who initiated an action and which identity changed the target.

Request current protocol versions, transports, client hosts, deployment modes, identity providers, policy fields, enforcement actions, regions, and availability commitments. Separate generally available support from previews, plugins, and roadmap items. Verify whether a configuration change requires client restart, server redeploy, or gateway policy propagation.

Review data handling for prompts, descriptions, arguments, results, identities, traces, and target data. Confirm collection, redaction, encryption, regional processing, retention, deletion, access control, and export. Central visibility can create a sensitive shared telemetry store.

Use matched price units: gateway instances, requests, tokens, connections, clients, servers, tools, protected actions, traces, retained data, or operator seats. Include route migration, server onboarding, policy maintenance, incident analysis, and availability costs.

Do not combine route coverage, server correctness, efficacy, latency, false positives, availability, and price into one score. Unknown matched results remain unknown. The purchase record should name the layer, owned decision, supported route, failure behavior, evidence fields, uncovered paths, and compensating owner.

Test one capability across every route

Select one versioned server and one reversible target operation. The same capability must be exercised over every claimed route so gateway evidence can be distinguished from server and target evidence.

Exercise the route matrix

Record client and host, transport, gateway route, server source and build, description and schema hashes, user and workload identities, downstream credential, policy versions, target, and expected result. Run a benign baseline through the gateway and verify discovery, least-privilege exposure, identity propagation, argument validation, downstream authorization, intended effect, and a joined trace.

Then run a prohibited tool, changed arguments, an unauthorized target, indirect instructions in a server result, a changed implementation behind the same schema, a direct connection, a local server path, and an alternate client. Change one variable at a time and record which layer sees and controls it.

Make the gateway, identity provider, server, policy service, and target unavailable separately. Test retries and idempotency so a timeout cannot create duplicate writes. Confirm revoked access stops existing and new sessions according to the documented boundary.

Use the MCP security tools guide to widen the shortlist only after this route matrix is fixed. Book an AgentGuard demo with the same server, routed call, direct bypass, local transport, identity change, component drift, and failure cases.

Apply acceptance criteria

For each case, capture discovery state, route, server version, authenticated actor, delegated identity, exposed tool set, proposed arguments, gateway decision, server validation, downstream request, resulting effect, latency, trace, disposition, and retest state.

Accept gateway enforcement only when every required route traverses it, prohibited direct and fallback paths fail as expected, delegated identity reaches the server and target, and unavailable-control behavior matches the fail-open or fail-closed contract. A deployment diagram is not evidence that the route cannot be bypassed.

Accept server control only when descriptions and schemas match behavior, arguments are validated, downstream credentials are scoped, target authorization holds, errors do not trigger duplicate effects, and results preserve the required provenance. Gateway approval cannot substitute for those checks.

Accept end-to-end evidence only when an operator can reconstruct one allowed operation and one blocked operation from client discovery through target state without vendor assistance. Then change a server version, description, policy, identity, and route and rerun the affected cases.

The final decision should state whether a gateway is required, which routes are enforceable, which capabilities and effects remain server- or target-owned, what happens during failure, and which paths remain uncovered. If clients can still connect directly, fix route governance before calling the gateway a control plane.