Added passthroughAuth option, --passthrough-auth on the commandline.#40
Added passthroughAuth option, --passthrough-auth on the commandline.#40iwyrkore wants to merge 5 commits intoharsha-iiiv:mainfrom
Conversation
If passthroughAuth is true, auth headers in MCP call tool requests are passed through to the API requests as specified by the OpenAPI spec. Scheme types http (bearer or basic), apiKey (header, query param, or cookie), and openIdConnect bearer tokens (passed through) as supported.
WalkthroughAdds a CLI flag and type, threads an optional passthroughAuth option through the generator into generated server and transport code, extends generated executeApiTool/security logic to accept session headers for credential sourcing, updates docs and examples, and bumps SDK dependency ranges. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Client
participant SSE as SSETransport
participant Handler as GeneratedServerHandler
participant Exec as executeApiTool
participant API as ExternalAPI
Client->>SSE: JSON-RPC tool.call
SSE->>Handler: onmessage(message, extra{requestInfo:{headers}})
alt passthroughAuth enabled
Handler->>Exec: executeApiTool(..., sessionHeaders=headers)
Note right of Handler #a8d0e6: forwards session headers
else passthroughAuth disabled
Handler->>Exec: executeApiTool(..., sessionHeaders=undefined)
end
rect rgba(220,235,255,0.4)
Exec->>Exec: Apply security from env OR sessionHeaders
end
Exec->>API: HTTP request with applied auth
API-->>Exec: Response
Exec-->>Handler: Tool result
Handler-->>SSE: JSON-RPC response
SSE-->>Client: SSE message
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. 📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
README.md (1)
51-63: Polish the CLI table entry and tighten terminology.Capitalize “OpenAPI,” start the sentence with a capital letter, and be explicit that headers are forwarded to the downstream API per the spec. Consider a brief safety note about trust boundaries.
Apply:
-| `--passthrough-auth` | | pass through auth info in MCP request headers to the API, as specified by the openapi spec. | `false` | +| `--passthrough-auth` | | Pass through authentication headers from incoming MCP requests to the downstream API, as specified by the OpenAPI spec. | `false` |Optional follow-up (outside the table): add a short note such as “Only enable when the MCP client and server share a trust boundary; forwarded headers may contain credentials.”
src/types/index.ts (1)
38-39: DocumentpassthroughAuthdefault and applicable transportsPlease update the JSDoc for
passthroughAuthto reflect its default behavior and where it applies:• File: src/types/index.ts
Lines: 38–39- /** Whether to pass through authentication headers to the API */ + /** Whether to pass through authentication headers to the API. Default: false. + * Applies only to transports that forward session/request headers + * (web, streamable-http). */ passthroughAuth?: boolean;• Consider normalizing this default at parse time as well (e.g. in your CLI options loader), so that
options.passthroughAuthis explicitly set tofalsewhen the flag is omitted—similar to howdefaultIncludeusesoptions.defaultInclude ?? true—for consistency across your codebase.CHANGELOG.md (1)
8-11: Follow “Keep a Changelog” heading levels and expand the entry for clarity.Introduce an “Unreleased” header to avoid jumping from H1 to H3, and capture the scope of the feature (schemes, transports, SDK bump).
-### Added - -- passthrough-auth option to pass through auth info in MCP request headers to the API, as specified by the openapi spec. +## [Unreleased] +### Added +- `--passthrough-auth` CLI option to forward authentication headers from MCP requests to the downstream API, per the OpenAPI security scheme. + Supports http (bearer/basic), apiKey (header/query/cookie), and OpenID Connect bearer tokens. + Works for SSE and StreamableHTTP transports. + Requires `@modelcontextprotocol/sdk` ^1.17.4.src/utils/security.ts (1)
277-277: Consider using nullish coalescing for cleaner logicThe current implementation uses logical OR which could potentially cause issues with empty string API keys.
Consider using nullish coalescing for more precise handling:
-const apiKey = (process.env[\`API_KEY_\${schemeName.replace(/[^a-zA-Z0-9]/g, '_').toUpperCase()}\`] || getHeaderValue(sessionHeaders,scheme.name.toLowerCase())); +const apiKey = process.env[\`API_KEY_\${schemeName.replace(/[^a-zA-Z0-9]/g, '_').toUpperCase()}\`] ?? getHeaderValue(sessionHeaders,scheme.name.toLowerCase());
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (10)
CHANGELOG.md(1 hunks)README.md(1 hunks)package.json(1 hunks)src/generator/package-json.ts(1 hunks)src/generator/server-code.ts(2 hunks)src/generator/web-server.ts(3 hunks)src/index.ts(1 hunks)src/types/index.ts(1 hunks)src/utils/code-gen.ts(1 hunks)src/utils/security.ts(8 hunks)
🧰 Additional context used
🧬 Code graph analysis (4)
src/generator/server-code.ts (1)
src/utils/code-gen.ts (1)
generateCallToolHandler(90-103)
src/generator/web-server.ts (1)
examples/pet-store-sse/src/web-server.ts (9)
SSETransport(21-137)handlePostMessage(81-115)message(181-188)c(162-201)stream(163-200)constructor(30-40)send(127-136)console(174-177)c(204-218)
src/utils/code-gen.ts (2)
examples/pet-store-streamable-http/src/index.ts (2)
executeApiTool(730-1048)request(593-601)examples/pet-store-sse/src/index.ts (1)
executeApiTool(730-1048)
src/utils/security.ts (1)
examples/pet-store-sse/src/index.ts (2)
acquireOAuth2Token(626-719)executeApiTool(730-1048)
🪛 LanguageTool
README.md
[grammar] ~57-~57: There might be a mistake here.
Context: ... | Auto-detected if possible | | --transport | -t | Transpor...
(QB_NEW_EN)
[grammar] ~58-~58: There might be a mistake here.
Context: ... | "stdio" | | --port | -p | Port fo...
(QB_NEW_EN)
[grammar] ~59-~59: There might be a mistake here.
Context: ... | 3000 | | --default-include | | Default...
(QB_NEW_EN)
[grammar] ~60-~60: There might be a mistake here.
Context: ...t. | true | | --force | | Overwri...
(QB_NEW_EN)
[grammar] ~61-~61: There might be a mistake here.
Context: ... | false | | --passthrough-auth | | pass th...
(QB_NEW_EN)
🪛 markdownlint-cli2 (0.17.2)
CHANGELOG.md
8-8: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
🔇 Additional comments (12)
src/generator/package-json.ts (1)
34-34: Generated servers depend on the updated SDK — good alignment.This keeps generated projects compatible with the new passthrough-auth plumbing and newer types (e.g., headers/extra info). 👍
src/generator/web-server.ts (3)
22-22: Import statement looks goodThe addition of
MessageExtraInfoto the imports from the SDK types is appropriate for supporting the passthrough authentication feature.
40-40: Update to onmessage signature is correctThe optional
extraparameter addition to the transport'sonmessagehandler signature properly aligns with the SDK's extended interface for header passthrough.
108-108: Headers properly extracted and forwardedThe implementation correctly extracts all request headers via
c.req.header()and passes them through theMessageExtraInfostructure. This enables downstream security handlers to access authentication headers from the incoming HTTP request.src/utils/code-gen.ts (1)
90-103: Well-structured handler signature updateThe function properly accepts the
passthroughAuthparameter and generates appropriate code based on its value. The conditional logic forsessionHeadersis clean and the implementation correctly threads headers through toexecuteApiTool.src/utils/security.ts (4)
211-214: Helper function implementation is robustThe
getHeaderValuefunction properly handles both string and string array header values, which is important for compatibility with different header representations in the IsomorphicHeaders type.
226-226: Security scheme evaluation correctly considers session headersThe security requirement evaluation logic properly checks for credentials from both environment variables and session headers, providing a good fallback mechanism. The implementation covers all supported authentication types (API Key, Bearer, Basic, OpenID Connect).
Also applies to: 232-237, 262-262
301-304: Session header fallback implementation looks goodThe implementation properly falls back to session headers when environment variables are not available, with appropriate logging to indicate the source of credentials.
Also applies to: 312-315, 353-356
393-399: Function signature update is correctThe addition of the
sessionHeadersparameter toexecuteApiToolproperly extends the function to support header passthrough while maintaining backward compatibility through the optional parameter.src/index.ts (1)
89-89: CLI option properly integratedThe
--passthrough-authflag is appropriately placed and has a clear description. The option correctly flows through to the generator via the options object.src/generator/server-code.ts (2)
42-42: Passthrough auth properly propagated to handler generationThe
passthroughAuthoption is correctly passed togenerateCallToolHandler.
102-107: Import additions are appropriateThe new imports for
CallToolRequest,ServerRequest,ServerNotification,IsomorphicHeaders, andRequestHandlerExtraare necessary for the passthrough authentication implementation.
| }, | ||
| "peerDependencies": { | ||
| "@modelcontextprotocol/sdk": "^1.10.2", | ||
| "@modelcontextprotocol/sdk": "^1.17.4", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
SDK peer bump looks good; ensure version consistency across the repo and generated projects.
Upgrading the peer dependency to @modelcontextprotocol/sdk ^1.17.4 aligns with the passthrough-auth changes that rely on newer SDK types. No issues spotted here.
Run this to verify all references now target ^1.17.4 and avoid mixed versions:
🏁 Script executed:
#!/bin/bash
# Find all occurrences of modelcontextprotocol/sdk versions
rg -nP "@modelcontextprotocol/sdk[^\\n]*" -S -C2Length of output: 12152
Ensure example projects also bump to @modelcontextprotocol/sdk ^1.17.4
The root package.json and generator’s package-json.ts correctly use ^1.17.4, but several example projects still depend on older versions (v1.9.0 and v1.10.0). To maintain consistency across the repo and avoid confusing version drift, please update the following:
• examples/pet-store-streamable-http/package.json
– Change "@modelcontextprotocol/sdk": "^1.10.0" to "^1.17.4"
• examples/pet-store-sse/package.json
– Change "@modelcontextprotocol/sdk": "^1.10.0" to "^1.17.4"
• examples/petstore-mcp/package.json
– Change "@modelcontextprotocol/sdk": "^1.9.0" to "^1.17.4"
After bumping, regenerate or commit updated lockfiles in each example directory to ensure that all transitive references align with SDK v1.17.4.
🤖 Prompt for AI Agents
In package.json (around line 65) and the three example package.json files
(examples/pet-store-streamable-http/package.json,
examples/pet-store-sse/package.json, examples/petstore-mcp/package.json), update
the @modelcontextprotocol/sdk dependency from the older versions (^1.10.0 and
^1.9.0) to "^1.17.4"; then run the package manager in each example directory
(npm install / pnpm install / yarn install as appropriate) to regenerate the
lockfile and commit the updated package.json and corresponding lockfile(s) so
transitive dependencies align with SDK v1.17.4.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (7)
examples/petstore-mcp/package.json (3)
12-17: Add a passthrough-auth demo script so users can discover the new flag.Providing a ready-to-run script helps validate/authenticate header forwarding without digging into docs.
"scripts": { "start": "node build/index.js", "build": "tsc && chmod 755 build/index.js", "typecheck": "tsc --noEmit", - "prestart": "npm run build" + "prestart": "npm run build", + "start:passthrough": "node build/index.js --passthrough-auth" },
21-26: Consider aligning axios version across examples for consistency.Other examples use axios ^1.9.0; this one uses ^1.8.4. Not a blocker, but version drift across templates can confuse users.
If you want to align, bump here to match the others and install once to ensure no breaking changes in generated codepaths.
22-22: SDK bump validated; engines compatibility confirmed
- @modelcontextprotocol/sdk@^1.17.4 (v1.17.4) declares
engines.node >=18.- examples/petstore-mcp/package.json now correctly specifies
"@modelcontextprotocol/sdk": "^1.17.4".- Generator template (
src/generator/package-json.ts) emits the same"@modelcontextprotocol/sdk": "^1.17.4"and definesengines.node = '>=20.0.0'.Generated projects will therefore require Node.js ≥20.0.0, which is stricter than the SDK’s minimum of ≥18.0.0. If you intend generated servers to run on Node 18–19, consider relaxing the engine range in the template; otherwise, these changes are safe to merge.
examples/pet-store-sse/package.json (2)
23-23: SDK upgrade LGTM; expose a passthrough run script for SSE.Good move to ^1.17.4. Add a script to exercise header passthrough over web transport so users can verify Authorization propagation end-to-end.
"scripts": { "start": "node build/index.js", "build": "tsc && chmod 755 build/index.js", "typecheck": "tsc --noEmit", "prestart": "npm run build", - "start:web": "node build/index.js --transport=web" + "start:web": "node build/index.js --transport=web", + "start:web:passthrough": "node build/index.js --transport=web --passthrough-auth" },
19-21: Confirm Node >=20 requirement is deliberate (vs. Node 18).This example targets Node >=20 while another template targets >=18. If Node 18 is sufficient for the SDK + Hono stack here, consider harmonizing; otherwise, a brief rationale in README would help.
You can validate quickly by running typecheck and a smoke start under Node 18.19 and Node 20.x in CI matrix.
examples/pet-store-streamable-http/package.json (2)
25-25: Version bump is fine; add a streamable-http passthrough script.Expose a convenience script to verify passthrough-auth with the StreamableHTTP transport.
"scripts": { "start": "node build/index.js", "build": "tsc && chmod 755 build/index.js", "format.check": "prettier --check .", "format.write": "prettier --write .", "typecheck": "tsc --noEmit", "prestart": "npm run build", - "start:http": "node build/index.js --transport=streamable-http" + "start:http": "node build/index.js --transport=streamable-http", + "start:http:passthrough": "node build/index.js --transport=streamable-http --passthrough-auth" },
21-23: Double-check Node >=20 necessity here as well.If StreamableHTTP doesn’t require Node 20-specific features, you might align the engines field across examples; otherwise, consider documenting why Node 20 is required.
Add a CI matrix with Node 18.19 and 20.x to quickly validate build and a smoke run for this template.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (2)
examples/pet-store-sse/package-lock.jsonis excluded by!**/package-lock.jsonexamples/pet-store-streamable-http/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (3)
examples/pet-store-sse/package.json(1 hunks)examples/pet-store-streamable-http/package.json(1 hunks)examples/petstore-mcp/package.json(1 hunks)
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
README.md (4)
51-63: Clarify what “auth headers” are forwarded and in which transports.Be explicit about supported schemes and transports to avoid ambiguity at the CLI surface. Recommended wording below keeps it tight while capturing behavior.
Apply this diff to tighten the description:
-| `--passthrough-auth` | | Forward auth headers in MCP requests to the downstream API, as specified by the OpenAPI spec. | `false` | +| `--passthrough-auth` | | Forward credentials from MCP requests to the downstream API per your OpenAPI securitySchemes. Supported: http (Bearer/Basic), apiKey (header/query/cookie), and OpenID Connect (Bearer). Works with `web` (SSE) and `streamable-http`. | `false` |
36-47: Usage: include an example that uses --passthrough-auth.Quick example helps discovery and sets the expectation that passthrough is relevant to web and StreamableHTTP.
Apply this diff to extend the Usage examples:
@@ # Generate an MCP web server with SSE openapi-mcp-generator --input path/to/openapi.json --output path/to/output/dir --transport=web --port=3000 # Generate an MCP StreamableHTTP server openapi-mcp-generator --input path/to/openapi.json --output path/to/output/dir --transport=streamable-http --port=3000 + +# Forward client-supplied credentials to the downstream API (SSE or StreamableHTTP) +openapi-mcp-generator --input path/to/openapi.json --output path/to/output/dir --transport=web --passthrough-auth +openapi-mcp-generator --input path/to/openapi.json --output path/to/output/dir --transport=streamable-http --passthrough-auth
142-156: Transport comparison: reflect new headers behavior.Since SSE can now forward session headers when passthrough is on, “Headers: Limited” is underselling it and may confuse readers.
Apply this diff to clarify:
-| Headers | No | Limited | Full HTTP headers | +| Headers | No | Limited (passthrough supported) | Full HTTP headers (passthrough supported) |
49-63: Minor copy/consistency polish for the CLI table.Optional cleanup to improve consistency and readability.
Apply this diff to normalize style (drop quotes around enum-like values and defaults, match tone of other rows):
-| `--transport` | `-t` | Transport mode: `"stdio"` (default), `"web"`, or `"streamable-http"` | `"stdio"` | +| `--transport` | `-t` | Transport mode: stdio (default), web, or streamable-http | stdio |
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (4)
CHANGELOG.md(1 hunks)README.md(1 hunks)src/types/index.ts(1 hunks)src/utils/security.ts(8 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/types/index.ts
- CHANGELOG.md
- src/utils/security.ts
🧰 Additional context used
🪛 LanguageTool
README.md
[grammar] ~57-~57: There might be a mistake here.
Context: ... | Auto-detected if possible | | --transport | -t | Transpor...
(QB_NEW_EN)
[grammar] ~58-~58: There might be a mistake here.
Context: ... | "stdio" | | --port | -p | Port fo...
(QB_NEW_EN)
[grammar] ~59-~59: There might be a mistake here.
Context: ... | 3000 | | --default-include | | Default...
(QB_NEW_EN)
🔇 Additional comments (2)
README.md (2)
51-63: Docs: New --passthrough-auth flag is clearly introduced.Row is added with a sensible default (false) and concise description. Nice.
159-169: Document credential sourcing precedence (passthrough vs env).README should state which source “wins” when both are present, to prevent surprises. Based on the PR summary, session headers can be used when available, but precedence isn’t documented here.
Proposed subsection; please confirm the actual precedence in code (session headers first vs env first), then merge:
@@ ## 🔐 Environment Variables for Authentication Configure auth credentials in your environment: @@ | OAuth2 | `OAUTH_CLIENT_ID_<SCHEME_NAME>`, `OAUTH_CLIENT_SECRET_<SCHEME_NAME>`, `OAUTH_SCOPES_<SCHEME_NAME>` | +### Credential sourcing precedence + +When `--passthrough-auth` is enabled: + +1. If the MCP request provides credentials that satisfy a declared `securitySchemes` requirement (e.g., `Authorization: Bearer …`, API key header/query/cookie), those are used for that request. +2. Otherwise, the generator falls back to environment variables (if configured) for that scheme. + +When `--passthrough-auth` is disabled: + +- Only environment variables (and any configured static credentials) are used. + +Note: Only the headers/params required by the active operation’s `security` are read/forwarded.If the actual behavior differs, I can update the text accordingly.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
README.md (1)
51-63: Make the passthrough-auth doc explicit and add a prominent security note right under the options table.The current one-liner undersells scope and risk. Clarify supported schemes and transports, and add an unmistakable warning right after the table. This mirrors prior feedback and keeps users from missing critical context.
Apply this diff to improve the row and add the security note:
@@ -| `--passthrough-auth` | | Forward auth headers in MCP requests to the downstream API, as specified by the OpenAPI spec. | `false` | +| `--passthrough-auth` | | Forward client-supplied credentials from MCP requests to the downstream API per your OpenAPI `securitySchemes`. Supported: `http` (Bearer/Basic), `apiKey` (header/query/cookie), and OpenID Connect (Bearer). Works with `web` (SSE) and `streamable-http`; not applicable to `stdio`. See “Pass-through Headers for Authentication” below. | `false` | + +> Security note +> +> - Only the credentials required by declared `securitySchemes` are forwarded (e.g., `Authorization`, a custom API key header, a query parameter, or `Cookie`). +> - Do not enable in untrusted or multi‑tenant contexts unless you intend clients to supply their own credentials; passthrough shifts the trust boundary to the client. +> - Avoid logging full request headers or cookies when passthrough is enabled. +> - `stdio` transport does not carry HTTP headers; passthrough is ineffective there by design.
🧹 Nitpick comments (5)
README.md (5)
129-129: Clarify when pass-through applies in the Web/SSE section.Add the flag name so readers know it’s gated by the CLI option.
-- Optional pass-through auth headers +- Optional: pass-through auth headers (enable with `--passthrough-auth`)
142-142: Mirror the clarification for StreamableHTTP.-- Optional pass-through auth headers +- Optional: pass-through auth headers (enable with `--passthrough-auth`)
157-157: Disambiguate “Optional” in Transport Comparison.Make it clear that it’s controlled by the CLI flag.
-| Pass-through Auth | No | Optional | Optional | +| Pass-through Auth | No | Optional (via `--passthrough-auth`) | Optional (via `--passthrough-auth`) |
175-179: Tighten wording and fix proper nouns.
- Use “OpenID Connect” (proper capitalization).
- Prefer “query parameter” over “query param.”
- Consider explicitly stating that only request-provided credentials are forwarded; server-side env vars remain supported separately.
-Use the CLI option `--passthrough-auth` to have the server pass-through client auth headers to the downstream API. The headers forwarded are for the auth schemes defined in the OpenAPI spec. Scheme types http (bearer or basic), apiKey (header, query param, or cookie), and openIdConnect bearer tokens are supported. +Use the CLI option `--passthrough-auth` to have the server pass through client auth headers to the downstream API. Only credentials corresponding to auth schemes defined in the OpenAPI spec are forwarded. Supported scheme types: `http` (Bearer or Basic), `apiKey` (header, query parameter, or cookie), and OpenID Connect (Bearer tokens).
181-198: Add a language to the fenced code block and verify transport identifiers/casing.
- markdownlint MD040: specify a language (json fits this example).
- The example uses
transport: "HTTP" and "Streamable-HTTP". Elsewhere you refer toweb(SSE) andstreamable-http. Please align these identifiers with the actual client configuration values supported by target MCP clients or add a note explaining the differences.Apply this diff to fix the fenced code block and unify transport labels to match the rest of the README (adjust if your target client expects different strings):
-``` +```json "mcpServers": { "my-api": { - "transport": "HTTP", + "transport": "web", "url": "http://localhost:3000/sse", "headers": { "Authorization": "Bearer MY_TOKEN" } }, "my-other-api": { - "transport": "Streamable-HTTP", + "transport": "streamable-http", "url": "http://localhost:4000/mcp", "headers": { "X-API-Key": "MY_API_KEY" } }, }If your intended audience configures a different client that expects
"HTTP"or a different casing/hyphenation, add a short note right under the snippet clarifying accepted values by common clients.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
README.md(5 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
README.md (1)
src/generator/server-code.ts (1)
generateMcpServerCode(21-243)
🪛 LanguageTool
README.md
[grammar] ~57-~57: There might be a mistake here.
Context: ... | Auto-detected if possible | | --transport | -t | Transpor...
(QB_NEW_EN)
[grammar] ~58-~58: There might be a mistake here.
Context: ... | "stdio" | | --port | -p | Port fo...
(QB_NEW_EN)
[grammar] ~59-~59: There might be a mistake here.
Context: ... | 3000 | | --default-include | | Default...
(QB_NEW_EN)
[grammar] ~175-~175: There might be a mistake here.
Context: ... Pass-through Headers for Authentication Use the CLI option --passthrough-auth ...
(QB_NEW_EN)
🪛 markdownlint-cli2 (0.17.2)
README.md
181-181: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (1)
README.md (1)
175-201: Document precedence/merging behavior between passthrough credentials and environment-based credentials.Users need to know which source wins if both are present for the same scheme (e.g., a Bearer token in request headers and a BEARER_TOKEN_<SCHEME_NAME> in env). Please confirm actual behavior and document it here.
Proposed text to add after the first paragraph of this section (adjust once verified):
+By default, when both client-supplied credentials and environment variables are available for the same `securityScheme`, the server will prefer: +1) client-supplied credentials from the request (when `--passthrough-auth` is enabled), +2) otherwise fall back to environment variables. +This allows operators to keep a baseline credential while permitting clients to override with their own where appropriate.To verify, please review the code path in your security handling (executeApiTool/session headers) and update the text accordingly.
|
Actually, I updated the code so that the auth in headers take precedence over the env vars. |
1 participant
If
--passthrough-authis true, auth headers in MCP call tool requests are passed through to the API requests as specified by the OpenAPI spec. Scheme types http (bearer or basic), apiKey (header, query param, or cookie), and openIdConnect bearer tokens (passed through) as supported.This works for SSE and StreamableHTTP.
Updated to
modelcontextprotocol/sdkv 1.17.4MCP Configuration in Cursor (for example):
Summary by CodeRabbit
New Features
Documentation
Chores