# What Is an MCP Gateway — and Why Every AI Stack Needs One The Model Context Protocol gave AI agents a standard way to call tools. What it didn't give you was everything else: authentication, secret management, context optimization, observability, access control, and the infrastructure to run tool-calling reliably in production. That gap is what an MCP Gateway fills. An MCP Gateway sits between your AI agents and your APIs. It handles the operational layer — the things that have nothing to do with what your agent is trying to accomplish and everything to do with making it work safely and efficiently at scale. This post covers what MCP Gateways do, which problems they solve, and how [HasMCP](https://hasmcp.com/?utm_source=agentrq) implements each of them. ## The Problem MCP Gateways Solve When you connect an LLM to a set of APIs through MCP, you run into a familiar set of infrastructure problems — the same ones you faced when connecting microservices, but now with an AI in the loop. **Authentication is non-trivial.** Your APIs require credentials. You can't hand those credentials to the LLM. You need a layer that handles the auth flow, issues tokens on behalf of the user, and refreshes them without exposing secrets. **APIs return too much data.** A typical API response contains far more information than the LLM needs for the current task. Every extra field is a wasted token — which means higher costs, slower responses, and an LLM that has to work harder to find what's relevant. **Tools are not static.** APIs go down. Permissions change. New endpoints get deployed. If your agent's tool list doesn't reflect the current state of the world, it will try to use tools that no longer exist — or miss tools that just became available. **Secrets need to be stored securely.** API keys and credentials shouldn't be in environment variables or scattered across services. They need centralized, encrypted storage with controlled access. **You can't debug what you can't observe.** When an LLM calls a tool and the result is wrong, you need to see the raw request, the raw response, and what transformations happened in between. Without that, debugging is guesswork. **Enterprise teams need access control.** Who can add new tools? Who can see which secrets? Which teams are isolated from each other? These aren't optional features — they're requirements before any of this goes to production. An MCP Gateway addresses all of these at the infrastructure level so your agents don't have to. ## Core Features of an MCP Gateway ### OpenAPI-to-MCP Mapping The most common API format in the world is OpenAPI. The most common thing teams want to do when connecting APIs to LLMs is expose those APIs as MCP tools. A gateway that understands OpenAPI can automate this completely. You provide an OpenAPI 3.0 or 3.1 spec — or a Swagger file — and the gateway generates the MCP tool definitions: the endpoint descriptions, parameter schemas, return types, and documentation that LLMs use to decide how and when to call the tool. The alternative is writing this manually for every endpoint. On a non-trivial API, that means hundreds of tool definitions, each one a potential source of errors. Automated mapping eliminates that class of problem entirely. ### Authentication Without Credential Exposure The standard pattern for secure, delegated authentication is OAuth2 — the same flow behind every "Log in with Google" button. The challenge is fitting that flow into a model that doesn't have a browser. MCP's elicitation mechanism is the right primitive for this: the server pauses, asks the user for input (in this case, permission), and waits for the result. A gateway that implements native MCP elicitation auth can handle the full OAuth2 lifecycle — initiate the flow, surface the authorization URL to the user, receive the token after consent, and manage refresh — without the LLM ever touching a credential. From the user's perspective, it's the familiar "authorize this app" screen. From the agent's perspective, the tool just works. ### Context Window Optimization The context window is a finite, expensive resource. Every token an API sends to the LLM costs money and competes with the tokens that actually matter for the task. A well-designed gateway gives you two levels of control over this: **Declarative filtering with JMESPath.** JMESPath is a query language for JSON — think of it as SQL for API responses. You define an expression that specifies exactly which fields to keep. An API returning a 50-field user object becomes a 3-field object by the time the LLM sees it. Fast, no code required, and the expressions are readable. **Programmatic transformation with JavaScript.** For cases that don't fit a simple filter — combining fields, reformatting dates, applying conditional logic, enriching data from other sources — an embedded JS engine lets you write an interceptor function. The raw response goes in; the optimized payload comes out. Full flexibility, no server-side deployment required. Together, these two mechanisms let you tune the data-to-cost ratio for every tool call. ### Real-Time Dynamic Tooling The tools available to an LLM are not static. APIs change state — they go offline for maintenance, new endpoints get deployed, a user's permissions get updated. If the LLM's tool list is a snapshot taken at startup, it's wrong before the day is out. MCP has a `tool_changed` event for exactly this reason. A gateway that monitors the health and auth status of connected APIs and emits `tool_changed` when something changes ensures the LLM is always working from an accurate picture of what's available. Tools that go down disappear from the list. Tools that come online appear. Permission changes are reflected immediately. This is the difference between an agent that fails gracefully and one that confidently calls an endpoint that no longer exists. ### Secure Secret and Proxy Management API keys, database passwords, and service credentials need to live somewhere. That somewhere should not be environment variables in a dozen different services, and it absolutely should not be in any prompt or context window. A gateway with a built-in encrypted vault centralizes all secrets. When a tool call requires a credential, the gateway retrieves it, injects it into the request, and forwards the request — all without the secret appearing in any log, response, or LLM context. The LLM never knows the key exists. The proxy layer also lets you modify requests in transit: add authentication headers, inject tracking IDs, normalize URLs. Fine-grained control over what goes in and out of every API call. ### Git Connections As the number of MCP tool definitions grows, managing them manually becomes a bottleneck. The answer is the same one the industry found for infrastructure configuration: GitOps. A gateway with native Git integration connects to your GitHub or GitLab organization, scans repositories for MCP configuration files, and syncs tool definitions automatically when changes are pushed to the main branch. Every change is tracked in version history — who updated which tool definition, when, and why. If a logic change causes unexpected behavior, rolling back is a git revert. This brings the same rigor to AI tool management that CI/CD brought to application deployment. ### Observability When something goes wrong in a tool call chain, you need to see what happened. That means: - Which tools are being called, by whom, and how often - The latency and error rate of each tool - The raw request and response payloads for failed calls - The "before" and "after" of any data transformation applied - The token cost of each call, and how much optimization is saving Without this, debugging LLM-powered applications is guesswork. With it, you can identify which tools are slow, which transformations are lossy, and which users are consuming the most of your AI budget. ### Multi-Tenancy and Access Control Enterprise AI deployments need isolation. Different teams, departments, or client projects should not share secrets, tool definitions, or observability data. A gateway designed for enterprise use creates strict tenant boundaries — each organization is its own isolated environment with its own vault, tool registry, and billing configuration. Within each tenant, role-based access control determines who can do what: who can add tools, who can read secrets, who can modify configuration. Predefined roles (Owner, Admin, Developer, Viewer) cover most cases; custom groups handle the rest. Permissions can be scoped to the entire organization or down to individual MCP servers. For compliance-heavy environments — SOC2, GDPR — the audit trail this produces is not a nice-to-have. It's a requirement. --- ## HasMCP: An MCP Gateway Built for Production [HasMCP](https://hasmcp.com/?utm_source=agentrq) implements all of the above. Here's how each feature maps to the architecture described. **Automated OpenAPI Mapping** reads your OpenAPI 3.0/3.1 or Swagger spec and generates fully typed MCP tool definitions — including parameter schemas, descriptions, and return types — with no manual code. From spec to LLM-callable tool in seconds. **Native MCP Elicitation Auth** handles OAuth2 end-to-end using MCP's elicitation mechanism. HasMCP initiates the flow, surfaces the authorization URL, captures the token, and manages refresh. Credentials are never in the context window. **MCP Resource & Prompt Support** extends beyond tools to the full MCP spec. Resources expose files, API responses, and database views as URI-addressable data that LLMs can browse. Prompts let you define and version-control instruction templates for consistent agent behavior across the organization. **Context Window Optimization** with both JMESPath Pruning (declarative JSON filtering) and Goja JS Logic (programmatic transformation via embedded JavaScript engine). Define exactly what reaches the LLM, whether the case is simple or complex. **Real-time Dynamic Tooling** via `tool_changed` events. HasMCP monitors connected API health and authentication status and notifies LLM clients immediately when the tool landscape changes. **Git Connections** integrate with GitHub and GitLab. Link your organization, and HasMCP tracks MCP configuration files across your repositories, auto-syncing to production on every push to main. Full change history, instant rollback. **Secure Secret & Proxy Management** via an encrypted vault. Secrets are injected into requests automatically, never surfaced to the LLM or in logs. Request-level proxy rules let you add headers, normalize endpoints, and control traffic to backend services. **MCP Composition** lets you chain multiple MCP servers together. Build modular tool ecosystems where one server's output feeds another's input — creating complex, reusable workflows from smaller, well-scoped components. **Observability & Telemetry** covers the full stack: tool call analytics, per-user governance, token economics (showing exactly how much context optimization saves), a streaming debug console for real-time event inspection, a payload inspector showing raw vs. optimized responses, and error tracing with full stack captures for failed calls. **Multi-tenant Organization Management** gives each team or client project a fully isolated environment with its own servers, secrets, and billing. Users can belong to multiple organizations and switch between them without friction. **Advanced RBAC** with Owner, Admin, Developer, and Viewer roles, plus custom group definitions. Permissions scoped to the organization or to individual MCP servers. Built for the audit trail requirements of SOC2 and GDPR compliance. **Unified API Key Management** for programmatic access. Generate keys for backend services or CI/CD pipelines, set expiration dates, scope to specific organizations or toolsets, and monitor real-time usage and latency from the observability dashboard. **Usage-based Billing & Subscriptions** via Stripe integration. Real-time tracking of organization counts, tool call volume, and token consumption, with tiered plans and automated invoicing. --- ## The Right Layer for AI Infrastructure The Model Context Protocol standardized how agents call tools. The MCP Gateway standardizes everything around that call: how credentials are handled, how data is shaped, how tools stay current, how access is controlled, and how you know what's happening when things go wrong. These are not AI problems. They're infrastructure problems — the same ones that appeared in microservices, in API management, in every system where you needed to connect many things securely and observe what they were doing. HasMCP applies that same infrastructure thinking to the AI agent layer. The result is a gateway that handles the operational complexity so your agents can focus on the work. [Get started with HasMCP](https://hasmcp.com/?utm_source=agentrq)