Portkey MCP server: a gateway, not a server

What Portkey's MCP Gateway does, why that is not the same as a Portkey connector, and what the tooling in its organization is actually for.

Last verified 1 September 2026 · from Portkey's MCP Gateway documentation, its GitHub organization and the MCP registry

This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.

What is the Portkey MCP server, and is it usable?

Portkey is an AI gateway: it sits in front of model providers and adds routing, caching, guardrails, virtual keys and observability. Its MCP role follows the same shape, standing between agents and the tools they call.

The gateway registers MCP servers and agents connect to Portkey rather than to each server. Portkey's governance then covers tool calls as well as model calls.

mcp-tool-filter is worth naming separately, because it addresses something this guide measures on every page: the tool list an agent receives costs context whether used or not, and a filter cuts it down.

Every one of the 90 vendors in this directory gets the same four checks. Portkey passes 0 of them.

Portkey operates in AI cost management as a gateway to other people's tools, and exposes nothing of its own to an agent.

Portkey's MCP support faces outward. An agent gains controlled access to other people's tools; it gains no view of Portkey itself. If you want an agent that can read what your gateway spent, that is an API call rather than a connector.

What can an AI agent do with Portkey?

The confusion here is between governing tools and exposing data.

How to configure Portkey MCP for agents

1. 1

   Decide who registers servers and who uses them

   Portkey documents that MCP integrations are added by org admins and members, while the resulting server is used by workspace admins, managers and members.

2. 2

   Pick the auth type when you register, not later

   The Add Server form takes Name, Short Description, URL, Slug, Server Type and Auth Type. A public server such as DeepWiki is registered with Auth Type None.

3. 3

   Know that the slug becomes the URL

   Every connection URL is https://mcp.portkey.ai/{server-slug}/mcp, so the slug you choose is the address your agents will carry.

4. 4

   Choose OAuth or an API key per client

   OAuth 2.1 needs only the URL and prompts on first use. An API key needs a workspace user key with mcp invoke permission.

5. 5

   Trim capabilities before provisioning

   The Capabilities tab lists every tool, resource and prompt a server exposes, and disabled ones are hidden and error if called directly.

Paste this into your agent’s instructions

Portkey filters what an agent sees twice: workspace provisioning decides which servers appear, and the Capabilities tab decides which tools within them appear. A tool can therefore be absent because it was disabled rather than because it does not exist.

When you answer through the Portkey MCP Gateway, state:
- Which registered server the tool you called belongs to.
- That an administrator can disable individual tools, so a
  tool may exist upstream and be hidden from this workspace.
Never state that data does not exist. State which servers
this workspace can reach, and that others may be hidden.
Write your answer in ASD-STE100 Simplified Technical
English. Use short sentences with one idea in each.

Do you need the MCP server at all?

There is no Portkey server to need. For governance, the gateway is the product and it does the job: virtual keys, budgets and guardrails applied to tool calls as well as model calls.

For reading Portkey's own data from an agent, use its REST API with the same credentials. There is no connector to wait for.

mcp-tool-filter is worth knowing about independently. Every page in this guide measures what tool definitions cost at connection, and filtering the list is the direct remedy.

Use Portkey as the gateway it is, and its API for anything you need read back into a conversation.

Portkey MCP server setup

Nothing here installs a Portkey server, because there is none. This is how a third-party server is registered with the gateway and then reached from an agent.

The order matters. An org admin adds the server to the MCP Registry and provisions it to a workspace; only then does a connection URL appear on the workspace MCP page.

Even when the upstream server needs no authentication, you still authenticate to Portkey to reach it through the gateway. Portkey states this plainly.

Name         deepwiki-test-mcp-server
URL          https://mcp.deepwiki.com/mcp
Slug         deepwiki-test-mcp-server
Server Type  Http
Auth Type    None

{"mcpServers":{"deepwiki":{
  "url":"https://mcp.portkey.ai/deepwiki-test-mcp-server/mcp"}}}

{"mcpServers":{"linear":{
  "url":"https://mcp.portkey.ai/linear/mcp",
  "headers":{
    "x-portkey-api-key":"YOUR_PORTKEY_API_KEY"}}}}

{"mcp.servers":{"linear":{
  "url":"https://mcp.portkey.ai/linear/mcp",
  "headers":{
    "x-portkey-api-key":"YOUR_PORTKEY_API_KEY"}}}}

Every other client

Each block below is the configuration for one client, with the file path and the key that client expects.

url = "https://mcp.portkey.ai/linear/mcp"
headers = {"x-portkey-api-key": "YOUR_PORTKEY_API_KEY"}

Org:       MCP Registry -> Server -> Access Control -> workspaces
Workspace: MCP -> Server -> User Access -> users

Server -> Capabilities -> toggle tools, resources, prompts

https://<your-gateway>/{server-slug}/mcp

Read-only access, permissions and security

• You authenticate to Portkey even when the upstream server is public

  Portkey states this directly for DeepWiki, which needs no credential of its own and still requires OAuth or an API key at the gateway.

• API keys carry workspace scope

  A key determines which MCP servers an agent can reach, and Portkey requires the MCP Invoke permission on it before any tool call succeeds.

• Disabled capabilities fail closed

  Portkey documents that disabled tools, resources and prompts are hidden and return errors if called directly, which makes the Capabilities tab a real control rather than a display filter.

• Server access can be gated on JWT claims

  JWT validation supports requiredClaims and claimValues, with exact, contains, containsAll and regex match types against an external identity provider.

• Tool-level authorization is not available yet

  Portkey's own table marks workspace and MCP-server levels as Available and the tool level as Coming soon.

• Most guardrails are not available yet

  Rate limiting is available now. Portkey lists pre-execution checks, content filtering, approval workflows and budget controls as coming soon.

• Every call is logged without setup

  Each request records the tool, parameters, response, user, team, timestamp, latency, status and upstream server.

• Sessions are ephemeral

  Each request is independent, with no session persistence between requests, which removes the need for sticky sessions.

Troubleshooting

You cannot find a Portkey MCP server to install

There is not one exposing Portkey's own data. The MCP Gateway registers and governs other people's servers. To read virtual keys, budgets or logs, call Portkey's REST API.

No connection URL appears in the workspace

The server has not been provisioned to that workspace yet. An org admin or owner toggles it under MCP Registry, Server, Access Control before the URL appears on the workspace MCP page.

The gateway rejects the key even though the upstream server is public

That is expected. Portkey documents that you still authenticate to Portkey through OAuth or an API key, whatever the upstream server requires.

Tool calls fail with an authorization error on a valid key

Check the key's permissions. It must be a workspace user API key with MCP Invoke enabled, and its workspace scope must include that server.

A tool you can see upstream returns an error through the gateway

It has probably been disabled. Portkey documents that disabled capabilities are hidden and return errors if called directly, set either organization-wide or per workspace.

The first tool call on an OAuth server fails with a URL in the message

That is the consent step. Portkey returns an error carrying an authorization URL; send the user there, then retry. Tokens are stored and refreshed automatically afterwards.

A user is blocked despite the workspace having access

Workspace access and user access are separate toggles. A workspace manager or admin enables individual users on the User Access tab of that server.

Portkey MCP server: Reference

What engineers report

There is no first-party server to review, so this section records what the organization actually ships.

Portkey's documentation, its GitHub organization and the official MCP registry checked on 24 August 2026.

Should you connect an agent to Portkey?

There is nothing to connect: this is the agent side of MCP. Best for gateway use, with Portkey's REST API for reading gateway data back.

Strongest fit

Teams already routing model calls through Portkey who want the same controls over tool calls.

Main advantage

Governance in front of servers you do not own, plus a tool filter that addresses context cost directly.

Main weakness

Nothing exposes Portkey's own data to an agent.

Operational risk

Low, because there is no server to misconfigure. The gateway's own credentials remain the sensitive part.

Frequently asked questions