Consuming or Providing MCP Servers: Why A Gateway Matters for Both

Model Context Protocol (MCP) has quickly become the reigning standard protocol for connecting AI agents with data, tools, and APIs.

Software developers and business users alike are integrating these MCP servers into their daily work, providing large language model (LLM) based AI agents with unprecedented access and control over everything from devops tools to team collaboration platforms, customer databases, and more.

Of course, teams are also on the builder’s side: designing, developing, and distributing MCP servers for others to use. These are often delivered in the form of remote servers that require secure authentication for access, and are hosted, monitored, and even metered for business purposes.

Due to the interest in agentic AI and the need to make more actionable AI, MCP servers have proliferated. There are over 26,000 unique servers in the official MCP registry, and 56% of them expose a remote-hosted server, according to a recent audit by Abanoub Rodolf Boctor.

Regardless of whether you’re using MCP servers, hosting them, or doing a combination of both, they come with similar governance needs. This centers around everything from tool discovery, to authentication and authorization for tool access, routing and monitoring calls, and more.

Below, we’ll explore the nuances of consuming versus building MCP servers. We’ll see how using an MCP gateway can kill two birds with one stone, operationalizing MCP usage and securing access for both MCP server consumers and providers.

Consuming MCP Servers

What is an ‘MCP consumer’? We can think of an MCP consumer as the host application that has been configured with access to various internal or third-party MCP tools.

This is usually an AI coding assistant, like Claude Code, Cursor, OpenAI Codex, or Windsurf. But MCP is also being utilized in business workflows, from Workato Enterprise MCP to Salesforce Agentforce and elsewhere.

This client might be talking to many MCP servers at once, depending on the prompt. It might loop in local MCP servers to access the file system or Terminal, and make calls to official remote servers from popular developer tools, like GitHub, Slack, or Notion.

The agent might also access unofficial servers or private MCP servers that you’ve developed internally.

Considerations For MCP Consumers

The thing is, using a bunch of MCP servers without guardrails carries some security concerns.

For one, MCP servers can be subject to classic supply chain issues, which can result in tool poisoning and prompt injection attacks being used for malicious actions, like leaking customer data, as in the case of a WhatsApp exploit.

It’s also incredibly easy to configure an MCP server and automatically give it many permissions. This can be tricky, since LLMs are nondeterministic, and the agents can cause unpredictable actions if they have unrestricted access to sensitive functions and data.

A sea of individual MCP tool permissions is hard to govern at scale, leading to shadow MCP servers with overpermissioned access and privilege drift, especially within multi-agent systems.

Providing MCP Servers

On the other hand, ‘providing MCP servers’ can be thought of as the act of exposing APIs, tools, and internal services through remote MCP servers for others to consume.

These MCP servers might be built for customers, partners, or other employees. These MCP servers often wrap underlying API platform endpoints, which may even be monetized.

In this scenario, you typically want to authenticate and monitor requests, associating usage on a per-API-key basis. This may be necessary to enforce subscription tiers, or different account-based roles, for instance.

Considerations for Providing MCP Servers

Similar to MCP server consumers, MCP server providers must consider various security implications. For one, injection-based attacks could use an MCP server as a means to conduct malicious actions on remote servers.

LLM-based agentic misalignment and intent errors could expose business logic gaps or security gaps in a highly automated fashion, such as enumerating URL lookups to discover broken access control, or field-level authorization gaps.

For MCP server providers, typical API provider security concerns also apply. For instance, you don’t want any sort of unauthorized access — especially for multi-tenant public platforms that deal with various user account data. This raises the need for OAuth-based authorization flows that often incorporate OpenID Connect.

As a server provider, you’ll probably also want to avoid unrestricted resource consumption to avoid cost runoffs. You may even want to gate MCP server access behind a subscription tier add-on, or charge per tool call within an agentic platform setup. Both require a way to monitor, meter, and associate usage-based billing with specific accounts.

Using the Same MCP Gateway For Both

Whether you are consuming many MCP servers or serving up your own, both situations call for some form of governance at scale. This is where a flexible MCP gateway, which can cater to both east-west and north-south traffic, can assist.

An MCP gateway is a new architectural layer devised as an abstraction layer between agentic platforms and MCP. It’s built to solve many of the common issues around MCP, including authentication, authorization, routing, limiting, request monitoring, configuring and enforcing tool-level policies, and more.

Benefits of Using an MCP Gateway for Both

Depending on the MCP gateway used, it could grant many benefits for MCP server consumers:

• Acts as the unifying layer to govern access to MCP servers
• Spin up virtualized instances of curated MCP tools that match internal roles
• Ensure consistent, standards-based authentication across a disparate MCP server catalog
• Monitor your use of MCP tools to inform auditing, compliance, costs, and debugging

For MCP builders, an MCP gateway can assist in a number of particular areas as well:

• Abstract direct access to backend systems, which is standard security practice for APIs
• Enforce authentication and additional policies
• Monitor external requests
• Tie requests to specific accounts to authorize access or meter usage
• Deny or allow requests based on API key and origin
• Turn on billing if necessary to monetize access

The same gateway can cater to both MCP users and MCP builders. By doing so, you incur less duplication, and administrators and superadmins are comfortable using the same platform.

Since MCP blurs the lines between external and internal facing services, repurposing an MCP gateway in this fashion arguably affords more control. By using the same for both, you reuse similar functionality and provide a consistent degree of control.

Possible Drawbacks of Using an MCP Gateway For Both

However, to be fair, there are possible drawbacks of using an MCP gateway for both use cases, or using one at all, for that matter.

For instance, an MCP gateway adds an additional software infrastructure expense. Therefore, before committing, it’s a good idea to weigh the pros and cons of building versus buying an MCP gateway to determine if it’s really necessary for your scale of use.

Whether it’s worth it will also hinge on the nuances of pre-existing software infrastructure and tooling setups. Some organizations may want to completely separate platforms due to continuity or compatibility with governance frameworks and pre-existing technologies.

Alternatively, using the same technology for east-west and north-south access might not transfer over 100% of the time for other reasons. For instance, MCP creators versus consumers may sit within highly separated domains or departments. In these cases, keeping the two sides separate may simply make more sense operationally.

Gateways Aid Diverse MCP Adoption

Microsoft’s 2026 Work Trend Index reported 15x year-over-year growth in active agents within Microsoft 365, rising to 18x in large enterprises. With this growth also comes the need for agents to interact with external data sources and APIs, and thus, greater potential demand for MCP.

At the same time, “MCP is growing up,” says Agentic AI Foundation VP Angie Jones, referring to its switch to stateless at the protocol layer and other improvements making it easier to run in production agentic systems.

The growing maturity of MCP signals that the industry will continue to coalesce around MCP as a standard of choice for some time. It also signals more MCP adoption in two ways: more people will be creating servers, and more will be integrating them.

Given MCP is the reigning standard for agent-to-tool integration, as MCP adoption rises, it will increasingly become an enterprise decision point to enforce policies around how these servers are accessed and used in practice.

A gateway can satisfy the needs of governing both MCP use and MCP distribution. Gateways are already the most common way to expose an MCP server, according to Zuplo’s State of MCP Report.

No matter which side you’re on — consuming MCPs, providing them, or a combination of both — MCP gateways stand as a helpful tool for governing an increasingly fragmented agentic AI tooling ecosystem. To try it on your own servers, start with the MCP Gateway quickstart.