Add support for custom headers and migrate from legacy auth #751

Jeetulsamaiya · 2025-08-26T13:31:56Z

This PR solves this issue:
#756 #750 #549 #249

Introduced CustomHeaders component for managing custom headers.
Updated Sidebar to include CustomHeaders component.
Enhanced useConnection hook to handle custom headers and legacy auth migration.
Added tests for custom headers functionality.
Updated package.json and package-lock.json for new dependencies.

Motivation and Context

This change addresses the need for flexible authentication and header management in the Inspector UI. Previously, the application only supported a single bearer token with a custom header name. This enhancement allows users to configure multiple custom headers with key-value pairs, providing better support for various authentication schemes and API requirements. The implementation also maintains backward compatibility by automatically migrating existing legacy auth configurations to the new custom headers system.

How Has This Been Tested?

Added comprehensive unit tests for the custom headers functionality in useConnection.test.tsx
Tested migration from legacy bearer token authentication to custom headers
Verified that disabled headers are properly ignored
Tested both form-based and JSON-based header configuration modes
Ensured backward compatibility with existing authentication configurations
Tested the UI components for adding, editing, and removing custom headers

Breaking Changes

No breaking changes. The implementation maintains full backward compatibility with existing bearer token and header name configurations. Legacy auth settings are automatically migrated to the new custom headers format when the application loads.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

The implementation includes:

A new CustomHeaders component with both form-based and JSON editor modes
Type definitions for custom headers in customHeaders.ts
Migration utilities for backward compatibility with legacy auth
Enhanced useConnection hook to process multiple headers
Server-side support for multiple custom auth headers via x-custom-auth-headers
UI improvements with toggle switches for enabling/disabling individual headers
Password-style input fields with visibility toggles for sensitive header values

The feature supports both streamable HTTP and SSE transports, allowing users to configure authentication headers for various API endpoints and authentication schemes beyond simple bearer tokens.

Fixes #756
Fixes #750
Fixes #549
Fixes #249

ColinMcNeil · 2025-08-26T16:06:26Z

Also related to #549

Jeetulsamaiya · 2025-08-26T18:54:13Z

these are the design screenshots

alex210501 · 2025-08-28T06:44:40Z

I think it would makes sense to also add those configuration field to the mcp.json file too. I'm not strongly familiar with the code, so maybe you already did it and I just did not see it.

- Introduced CustomHeaders component for managing custom headers. - Updated Sidebar to include CustomHeaders component. - Enhanced useConnection hook to handle custom headers and legacy auth migration. - Added tests for custom headers functionality. - Updated package.json and package-lock.json for new dependencies.

…used variables

olaservo

Hi, thank you for this PR! I just had a minor comment so far. I wanted to test this locally but don't have a server ready at the moment that requires custom auth headers, so just wanted to leave a note that I'm not ignoring this one while I set up something to test with locally (unless you have a specific server you have been testing this with?)

client/src/App.tsx

…age for header management

Jeetulsamaiya · 2025-09-10T15:41:44Z

Hi, thank you for this PR! I just had a minor comment so far. I wanted to test this locally but don't have a server ready at the moment that requires custom auth headers, so just wanted to leave a note that I'm not ignoring this one while I set up something to test with locally (unless you have a specific server you have been testing this with?)

I’ve set up an MCP server at my company, but it’s not deployed to prod and is only accessible on our internal network, so I can’t share the URL for testing.

ryanchase-cohere · 2025-09-10T16:15:50Z

Hi @olaservo

Thank you for your support on this! A simple way to test this would be to host an MCP server on Google Cloud Run and make it private because Cloud Run expects a user's google identity token to be sent as the X-Serverless-Authorization header, while the MCP server itself in most cases relies on the Authorization header for custom authorization. https://cloud.google.com/run/docs/authenticating/service-to-service#acquire-token

ryanchase-cohere · 2025-09-10T18:50:18Z

Hi @olaservo

Thank you for your support on this! A simple way to test this would be to host an MCP server on Google Cloud Run and make it private because Cloud Run expects a user's google identity token to be sent as the X-Serverless-Authorization header, while the MCP server itself in most cases relies on the Authorization header for custom authorization. https://cloud.google.com/run/docs/authenticating/service-to-service#acquire-token

here's an example: https://cloud.google.com/blog/topics/developers-practitioners/build-and-deploy-a-remote-mcp-server-to-google-cloud-run-in-under-10-minutes

cliffhall · 2025-09-12T12:58:45Z

I think it would makes sense to also add those configuration field to the mcp.json file too. I'm not strongly familiar with the code, so maybe you already did it and I just did not see it.

That would be best left for a separate PR. This one is big enough already.

cliffhall · 2025-09-12T19:41:56Z

client/eslint.config.js

@@ -23,6 +23,10 @@ export default tseslint.config(
        "warn",
        { allowConstantExport: true },
      ],
+      "@typescript-eslint/no-unused-vars": [


Why is this being added?

client/src/App.tsx

client/src/components/Sidebar.tsx

client/src/components/__tests__/Sidebar.test.tsx

client/src/lib/types/customHeaders.ts

client/src/App.tsx

client/src/lib/hooks/useConnection.ts

Jeetulsamaiya · 2025-09-12T21:18:24Z

@cliffhall Thanks for the suggestion I agree — having Authorization: Bearer as the default makes sense since it’s the most common case, while still giving users the flexibility to customize or add extra headers as needed.

I’ll review the requested changes and ensure everything is addressed. I plan to push an update with this change within the next 2–3 days.

ramyres110 · 2025-09-15T13:57:03Z

Good morning, I forked and will implement this because or business rule, but, I came here to tag this PR as important, more than others, cause, this is basic for the internet and mcp transport for list with security and personalizations.
For context, my tools list return have difent schemas defined by user informations as authorization and x-locate, x-company, etc.

Thanks all for this!

- Provide "Authorization: Bearer " as default starting header - Remove legacy auth props from components - Centralize migration logic and fix localStorage cleanup - Update tests for new auth architecture

Jeetulsamaiya · 2025-09-15T14:56:41Z

@cliffhall I’ve pushed the update

Added Authorization: Bearer <token> as the default header.
Addressed the requested changes and ensured everything is correctly applied.
Users still have full flexibility to customize or add additional headers.
Verified backward compatibility through testing.

Please let me know if you spot anything I may have missed

cliffhall

Requested changes were made. Tested locally, observed request headers in browser and at the server endpoint.
LGTM! 👍

Request headers in browser

Request headers at server

cliffhall · 2025-09-15T16:13:06Z

@olaservo You don't necessarily need the server to expect the headers, as long as you can see that they are verifiably sent and received by the server. I did that in my review and everything looks good. Just temporarily added a console.log(req.headers) to the everything server's /mcp POST endpoint.

Jeetulsamaiya mentioned this pull request Aug 28, 2025

Add custom headers for HTTP/SSE transports #756

Closed

rishid mentioned this pull request Sep 8, 2025

Support adding arbitrary headers #249

Closed

Jeetul-samaiya added 3 commits September 9, 2025 13:44

refactor: improve code formatting and readability across multiple files

cb8c454

fix: update error handling in JSON parsing and add ESLint rule for un…

6f727b6

…used variables

Jeetulsamaiya force-pushed the main branch from 625767f to 6f727b6 Compare September 9, 2025 08:21

fix: standardize formatting in bug report issue template

fde55ef

olaservo reviewed Sep 10, 2025

View reviewed changes

client/src/App.tsx Show resolved Hide resolved

fix: enhance error handling for custom headers and improve test cover…

90ab419

…age for header management

Merge branch 'main' into main

743bb52

cliffhall mentioned this pull request Sep 12, 2025

feat: support custom header #549

Closed

9 tasks

cliffhall requested changes Sep 12, 2025

View reviewed changes

Jeetulsamaiya and others added 2 commits September 15, 2025 19:30

Merge branch 'main' into main

f36c649

feat: add default Authorization Bearer header and clean up legacy auth

e08ce8c

- Provide "Authorization: Bearer " as default starting header - Remove legacy auth props from components - Centralize migration logic and fix localStorage cleanup - Update tests for new auth architecture

cliffhall approved these changes Sep 15, 2025

View reviewed changes

cliffhall merged commit 4352d32 into modelcontextprotocol:main Sep 15, 2025
5 checks passed

Add support for custom headers and migrate from legacy auth #751

Add support for custom headers and migrate from legacy auth #751

Conversation

Jeetulsamaiya commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

ColinMcNeil commented Aug 26, 2025

Uh oh!

Jeetulsamaiya commented Aug 26, 2025

Uh oh!

alex210501 commented Aug 28, 2025

Uh oh!

olaservo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Jeetulsamaiya commented Sep 10, 2025

Uh oh!

ryanchase-cohere commented Sep 10, 2025

Uh oh!

ryanchase-cohere commented Sep 10, 2025

Uh oh!

cliffhall commented Sep 12, 2025

Uh oh!

cliffhall Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Jeetulsamaiya commented Sep 12, 2025

Uh oh!

ramyres110 commented Sep 15, 2025

Uh oh!

Jeetulsamaiya commented Sep 15, 2025

Uh oh!

cliffhall left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Request headers in browser

Request headers at server

Uh oh!

cliffhall commented Sep 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Jeetulsamaiya commented Aug 26, 2025 •

edited

Loading

cliffhall left a comment •

edited

Loading

cliffhall commented Sep 15, 2025 •

edited

Loading