Updated MCP Docs

product/mcp-gateway/authentication/oauth.mdx

@@ -1,13 +1,13 @@
 ---
 title: OAuth
 description: Portkey's built-in OAuth 2.1 authentication for MCP Gateway.
 ---
 
 Portkey provides built-in OAuth 2.1 authentication for MCP Gateway. When users access MCP servers without an API key, Portkey acts as the OAuth provider and handles the authentication flow.
 
 ## When to use
 
 Use Portkey's OAuth when:
 
 - Building browser-based applications where users authenticate interactively
 - Using MCP clients like Claude Desktop or Cursor without API keys
@@ -29,9 +29,9 @@
 
 ## Configuration
 
 Portkey's OAuth is enabled by default. No configuration required.
 
 When a request arrives without an API key or bearer token, Portkey automatically initiates the OAuth flow.
 
 ## Client integration
 
@@ -77,7 +77,7 @@
 
 ## Token management
 
 Portkey handles token lifecycle:
 
 - **Access tokens**: Short-lived, used for MCP requests
 - **Refresh tokens**: Long-lived, used to obtain new access tokens
@@ -93,17 +93,14 @@
 
 ## Combining with external OAuth
 
 Portkey's OAuth works alongside external OAuth. Portkey determines the authentication method based on what's in the request:
 
 | Request contains | Authentication method |
 |------------------|----------------------|
 | Portkey API key | API key authentication |
 | External IdP token | External OAuth 2.0 validation |
 | Nothing | Portkey OAuth 2.1 flow |
 
-<Warning>
-When using API key authentication, only **user API keys** work with MCP Gateway. Service API keys are not supported.
-</Warning>
 
 ## Security considerations
 

product/mcp-gateway/internal-mcp-servers.mdx

@@ -1,21 +1,21 @@
 ---
 title: Add Internal MCP Servers
 description: Add your internal MCP servers to Portkey. Get enterprise-grade auth, access control, and logging without building it.
 ---
 
 Your team has built MCP servers for internal docs, proprietary APIs, databases. Now you need authentication, access control, and logging for each one. Building that infrastructure is expensive. Maintaining it is harder.
 
 **Add your internal servers to Portkey.** Get enterprise-grade infrastructure without writing a line of auth code.
 
 ---
 
 ## Why Use Portkey's MCP Gateway
 
 - **Authentication without building auth.** Every MCP server needs it. Without Portkey, you build OAuth flows, validate tokens, manage sessions—for every server. With Portkey, authentication happens once at the gateway. Your servers receive authenticated requests.
 
 - **User identity forwarding.** Your server often needs to know *who* is making a request. Portkey forwards user claims (email, team, roles) automatically. No OAuth implementation required.
 
 - **Access control without deployments.** Control who accesses which servers and tools. When someone leaves a team, revoke access in Portkey. No code changes.
 
 - **Full observability.** Every tool call logged—who called what, with what parameters, what was returned. Debug issues in minutes.
 
@@ -41,16 +41,16 @@
 
 | Layer | Purpose | Options |
 |-------|---------|---------|
 | **Gateway** | User proves identity to Portkey | API Key, OAuth, External IdP |
 | **Server** | Portkey authenticates to your server | OAuth Auto, API Key None, Headers |
 
 Users authenticate to Portkey with SSO. Portkey authenticates to your server with an API key. Users never see your server's credentials.
 
 ---
 
 ## Setup
 
 Your MCP server must be accessible over HTTP and implement MCP protocol over Streamable HTTP transport.
 
 <Note>
 Using STDIO transport? Expose it as an HTTP endpoint first.
@@ -65,7 +65,7 @@
 | **Name** | Display name (e.g., "Internal Documentation") |
 | **Slug** | URL identifier (e.g., `internal-docs`) |
 | **Server URL** | Your server's MCP endpoint |
 | **Auth Type** | How Portkey authenticates to your server |
 
 For **Auth Type**: use `None` if your server is in a private network, `Headers` for API keys, or `OAuth Auto` for servers supporting OAuth 2.1.
 
@@ -75,7 +75,7 @@
 
 <Tabs>
   <Tab title="JWT Header">
     Portkey generates a signed JWT with user claims. Your server verifies using Portkey's public keys.
 
     ```json
     {
@@ -91,7 +91,7 @@
   </Tab>
 
   <Tab title="Claims Header">
     Portkey sends user claims as JSON. Simpler, no cryptographic verification.
 
     ```json
     {
@@ -123,7 +123,7 @@
 
 ### Connect
 
 Users connect through Portkey:
 
 ```json
 {
@@ -152,9 +152,6 @@
 
 **Portkey API Key** — Create keys in **Settings → API Keys**. Keys are scoped to workspaces.
 
-<Warning>
-When using API key authentication, only **user API keys** work with MCP Gateway. Service API keys are not supported.
-</Warning>
 
 ```json
 {
@@ -201,7 +198,7 @@
 }
 ```
 
 Developers use their Portkey API key. Your server receives user identity. Every query appears in Portkey logs. Access control managed centrally—no server changes needed.
 
 ---
 

product/mcp-gateway/quickstart.mdx

@@ -1,6 +1,6 @@
 ---
 title: Quickstart
 description: Add DeepWiki to Portkey MCP Gateway and connect it to Claude.
 ---
 
 This quickstart covers:
@@ -74,7 +74,7 @@
 
 ## 3) Use the URL in Claude (Desktop / Code)
 
 Add a new MCP server that points to the Portkey URL. You have two authentication options:
 
 <Tabs>
   <Tab title="OAuth (Recommended)">
@@ -118,10 +118,6 @@
     When creating your workspace API key, ensure it has **MCP Invoke** permissions enabled.
     </Note>
 
-    <Warning>
-    Only **user API keys** work with MCP Gateway. Service API keys are not supported.
-    </Warning>
-
     <Info>
     **Best for:** CI/CD pipelines, backend services, or automated agents where interactive OAuth isn't possible.
     </Info>
@@ -129,7 +125,7 @@
 </Tabs>
 
 <Note>
 Even though DeepWiki doesn't require authentication to the upstream server, you still need to authenticate with Portkey (via OAuth or API key) to access the server through the gateway.
 </Note>
 
 ---