Manage MCP context with Postman Fabric Gateway

The Model Context Protocol (MCP) helps agentic systems act on and retrieve information from external tools. As applications grow, agents may need to work across many MCP servers and large tool catalogs, making context management harder.

Loading every tool definition upfront wastes tokens on irrelevant schemas and leaves less room for instructions, history, and task data. At enterprise scale, teams need a deliberate way for agents to discover relevant tools while controlling access, credentials, and tool execution.

In this tutorial, we’ll show how to use Postman Fabric Gateway to connect multiple MCP servers through a single endpoint and enable progressive tool search so agents can retrieve tool schemas only when needed.

Prefer to watch? This tutorial is also available as a video walkthrough:

What You’ll Learn

By the end of this tutorial, you’ll know how to:

• Connect multiple MCP servers to Postman Fabric Gateway and manage their upstream credentials securely.
• Create individual and combined routes so clients can access multiple tool catalogs through a single MCP endpoint.
• Enable progressive tool discovery so agents can search for relevant tools, retrieve schemas on demand, and execute tools without loading the full catalog upfront.

Pre-requisites

You’ll need the following before you start:

• A Fabric Gateway account
• A Postman account with access to the workspace where you’ll test the integration.
• A basic understanding of MCP

In this tutorial, we are going to work with two MCP servers. A support MCP server and a banking MCP server. These MCP servers are used by a support agent to manage customer transaction disputes. We won’t go into the technicalities of the agent or the tools that the MCP server exposes.

Step 1: Connect the MCP servers and configure their credentials

In Fabric Gateway, click on MCP servers in the left navigation menu, and select Create connection.

Name the connection banking-mcp and enter the below URL as the banking server’s full MCP endpoint.

In the Upstream auth requirement, select Bearer auth type and toggle the radio box.

Next, you need to provide the required authorization credential to Fabric Gateway.

Copy and paste banking-mcp-demo-key as the API key into the token input box.

This will create a service level credential for the connection. This credential will be stored in a secure vault.

This setup screen allows you to create a connection, and expose that connection on a newly created route in one go. Fill in a preferred name for the new route, and provide a path that you want it exposed on. Toggle the “Gateway Key” option and select “No gateway key”.

Save the connection by clicking on Create Connection.

Repeat this process for the support-mcp connection.

Connection Name	Upstream URL	Credential/API Key
banking-mcp	https://intergalacticbanking-mcp-production.up.railway.app/mcp	Banking MCP Key: banking-mcp-demo-key
support-mcp	https://intergalacticsupport-mcp-production.up.railway.app/mcp	Support MCP Key: support-mcp-demo-key

Step 2: Create a route to combine the tool catalogs

Creating a connection tells Fabric where a service lives. A route gives clients an endpoint through which to use it. You’ve created a route for each service so you can test them independently.

Route path	Connected service
/banking/mcp	Banking MCP
/support/mcp	Support MCP

Navigate to MCP Servers on the left sidebar. Switch to the routes tab and click on the Copy DP URL icon to the right of any of the routes.

In Postman, create an MCP request, and paste the DP URL you just copied. Test any of the MCP tools in the tool list.

Repeat this process for both MCP servers.

Next, we want to be able to combine these two MCP server tools on a single route. Still on the routes tab, click on “Create Route” to create a third route.

Name this route all-mcp, give it a path such as /banking/all, and select both services.

Copy the DP URL, and send an MCP request to it in Postman.

The client now lists tools from both servers through one endpoint. Fabric prefixes and namespaces the tool names so you can identify each tool’s originating service; in this setup, the combined list contains 103 tools.

We’ve consolidated the connection, but the client still receives the full catalog. The next step changes that.

Step 3: Enable progressive tool discovery

Open Plugin, scroll down, and click on Use on the Tool Search option. Give this plugin a name and scope it to the all-mcp route you just created.

Click on the Edit as JSON button and paste the below JSON. Switch back to form mode and confirm that the openai service is indeed selected, then save.

NOTE: You can use any embedding model or service of your choosing here

This plugin introduces an embedding service that makes it possible to search a tool catalog semantically. This means a request such as “list transactions” can return relevant tools without requiring their exact names. This is explained in more detail shortly.

Disconnect and reconnect the combined MCP request in Postman to refresh its tool listing.

Instead of 103 tool definitions, you should now see three tools that perform these jobs:

Capability	Purpose
Search tools	Find relevant tools across the catalog using a natural-language query. This uses the added embedded service in tool search.
Get tool	Retrieve the selected tool’s definition, including its input schema.
Execute tool	Invoke the selected tool with the required arguments.

This means that the Agent can now progressively discover tools rather than load the entire tool schema upfront. The upstream tools have not been deleted or merged into three operations. Instead, the gateway has changed how the client discovers and invokes them.

Test discovery with a simple query: “list transactions.” Run the search tool and review the returned matches. You should see candidates relevant to transaction lookup, rather than the complete banking and support tool catalog.

Copy the name of one of the returned tools e.g ban__banking_list_transactions, and paste that name into the get_tool tool to retrieve the schema definitions of that tool. Then use the execute-tool capability with that tool’s identifier and arguments.

This is the sequence an agent will follow: find a relevant capability, learn how to call it, then act. In the Postman MCP Client, you just walked through each stage manually.

Step 4: Monitor Traces and telemetry

Fabric Gateway automatically collects telemetry across all services and routes. You can view the traces on the Gateway’s dashboard. Click on traces in the left sidebar. This should show you a list of all the requests that have been routed by the Gateway, and you can click on any of them to view the end-to-end trace.

Traces let you examine route matching, plugin execution, and upstream activity where applicable.

This is useful when a call fails: you can investigate what happened at the gateway instead of relying only on the error shown by the client.

What changes for the agent

In this tutorial, we showed how to expose multiple MCP servers through a single MCP endpoint, reduce an agent’s tool surface area, and provide a focused set of tools that are easier for an agent to discover and use.

The result is one MCP endpoint backed by two services, with three tools initially listed instead of 103. That gives a smaller starting point for an application that would otherwise pass the complete catalog to its model. It is not a measured percentage reduction in tokens or cost: search results, retrieved schemas, and tool responses still consume context, and discovery adds requests. Measure the full workflow when comparing performance.

The practical benefit is control over when tool definitions enter the conversation. The agent can request the capability it needs, while the gateway manages credentials, enforces access policies, and inspects traffic.

Resources

• Sign in to Fabric Gateway and configure MCP services, routes, credentials, plugins, and traces.
• Read the Fabric Gateway documentation.
• Learn how to create and test MCP requests in Postman.

 

This was originally posted on fabricgateway.ai/blog