flowing env vars to the client app for inspector #258

aaronpowell · 2025-04-03T05:27:03Z

This allows you to set the SERVER_PORT or MCP_PROXY_FULL_ADDRESS as an environment variable and the value will be injected into the static app when it's run. Also making the transport type provided by the config.

Fixes #256 and #255

Motivation and Context

How Has This Been Tested?

I've tested this by setting the SERVER_PORT env var before running and verifying that that is passed through correctly to the client app:

$> SERVER_PORT=12354 npm start -- npx -y @modelcontextprotocol/server-everything

> @modelcontextprotocol/[email protected] start
> node client/bin/start.js npx -y @modelcontextprotocol/server-everything

Starting MCP inspector...
⚙️ Proxy server listening on port 12354
🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀

I can then connect and run successfully:

When started without an env var it starts on the default port:

$> npm start

> @modelcontextprotocol/[email protected] start
> node client/bin/start.js

Starting MCP inspector...
⚙️ Proxy server listening on port 6277
🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀

And the browser reflects that:

Breaking Changes

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

This allows you to set the SERVER_PORT or MCP_PROXY_FULL_ADDRESS as an environment variable and the value will be injected into the static app when it's run. Fixes modelcontextprotocol#256

pulkitsharma07 · 2025-04-03T06:32:10Z

client/bin/cli.js

 import http from "http";
+import { dirname, join } from "path";
+import handler from "serve-handler";
+import { fileURLToPath } from "url";

 const __dirname = dirname(fileURLToPath(import.meta.url));
 const distPath = join(__dirname, "../dist");

 const server = http.createServer((request, response) => {


Would a better approach be to expose an endpoint in this server to return the config ? That would simplify this part of the code (and not have to deal with runtime injection).

Something like that is being done here (although it contacts the proxy server):

inspector/client/src/App.tsx

Line 228 in ce1a9d3

fetch(`${getMCPProxyAddress(config)}/config`)

The runtime config stuff further down in the client code definitely would be simpler.

As in, create an API in the client/bin/cli.js that provides an endpoint in which you load the config file? It would but doesn't that add overhead to the startup of the app in that you have to make an API call to get the config, then make an API call to get the config from the server.

Maybe they could be combined, make the /config exist on the client app, which then proxies the SERVER/config.

@aaronpowell Could we get a mermaid sequence diagram showing how this is intended to work? That would give us a better starting point for understanding how best to plumb this.

sequenceDiagram participant SPA participant ClientHost participant ProxyServer Note over SPA: Application starts SPA->>ClientHost: GET /config activate ClientHost ClientHost->>ProxyServer: GET /config activate ProxyServer ProxyServer-->>ClientHost: Return configuration data deactivate ProxyServer ClientHost-->>SPA: Return configuration data deactivate ClientHost Note over SPA: Process configuration

Loading

With this we can simplify the "Client Host" (the server run from client/bin/cli.js to not have to worry about much heavy lifting other than "where is the server endpoint" and pass through the request.

Isn't the proxy server address part of the config?

cliffhall

Reimplementing as an endpoint that the app calls rather than the runtime injection scheme into the window seems simpler.

bin/cli.js

cliffhall · 2025-04-03T20:16:57Z

client/src/App.tsx

+      : DEFAULT_INSPECTOR_CONFIG;
+
+    // Override with runtime injected values if available
+    if (runtimeConfig.MCP_PROXY_FULL_ADDRESS) {


Shouldn't this be more like:

if (runtimeConfig.MCP_PROXY_FULL_ADDRESS) { configFromStorage = { ...configFromStorage, MCP_PROXY_FULL_ADDRESS: { value: runtimeConfig.MCP_PROXY_FULL_ADDRESS, }, };

are there properties other than value on MCP_PROXY_FULL_ADDRESS that are important?

It is a ConfigItem.

client/src/utils/configUtils.ts

cliffhall · 2025-04-03T20:22:40Z

client/bin/cli.js

 import http from "http";
+import { dirname, join } from "path";
+import handler from "serve-handler";
+import { fileURLToPath } from "url";

 const __dirname = dirname(fileURLToPath(import.meta.url));
 const distPath = join(__dirname, "../dist");

 const server = http.createServer((request, response) => {


The runtime config stuff further down in the client code definitely would be simpler.

bin/cli.js

aaronpowell · 2025-04-03T22:43:30Z

client/bin/cli.js

 import http from "http";
+import { dirname, join } from "path";
+import handler from "serve-handler";
+import { fileURLToPath } from "url";

 const __dirname = dirname(fileURLToPath(import.meta.url));
 const distPath = join(__dirname, "../dist");

 const server = http.createServer((request, response) => {


As in, create an API in the client/bin/cli.js that provides an endpoint in which you load the config file? It would but doesn't that add overhead to the startup of the app in that you have to make an API call to get the config, then make an API call to get the config from the server.

Maybe they could be combined, make the /config exist on the client app, which then proxies the SERVER/config.

aaronpowell · 2025-04-03T22:44:14Z

client/src/App.tsx

+      : DEFAULT_INSPECTOR_CONFIG;
+
+    // Override with runtime injected values if available
+    if (runtimeConfig.MCP_PROXY_FULL_ADDRESS) {


are there properties other than value on MCP_PROXY_FULL_ADDRESS that are important?

client/src/utils/configUtils.ts

cliffhall · 2025-04-07T15:38:08Z

client/bin/cli.js

+
+      // Create a runtime config object with environment variables
+      const runtimeConfig = {
+        MCP_PROXY_FULL_ADDRESS: process.env.MCP_PROXY_FULL_ADDRESS || "",


MCP_PROXY_FULL_ADDRESS and MCP_PROXY_PORT should be ConfigItems.

This means that when you set environment variables we read them on the server and add them to the config info obtained by the proxy, resulting in the proxy server being the 'winner' in terms of what the config should look like.

Fixes modelcontextprotocol#255

cliffhall

Please include detailed steps for testing in the PR header.

aaronpowell · 2025-04-24T06:26:52Z

Please include detailed steps for testing in the PR header.

Updated with how I've tested so far. Let me know if there are more scenarios you'd like me to test against.

cliffhall

Reviewed again and had a few observations.

cliffhall · 2025-04-24T19:47:40Z

client/bin/client.js

+  // Use current host with custom port if specified
+  const port = process.env.SERVER_PORT || "6277";
+  // Default to http://localhost:port
+  return `http://localhost:${port}`;


Should be 127.0.0.1 instead of localhost. The are generally interchangeable, however the OAuth spec recommends to use 127.0.0.1 instead of localhost:

While redirect URIs using localhost (i.e., "http://localhost:{port}/{path}") function similarly to loopback IP redirects described in Section 7.3, the use of localhost is NOT RECOMMENDED. Specifying a redirect URI with the loopback IP literal rather than localhost avoids inadvertently listening on network interfaces other than the loopback interface. It is also less susceptible to client-side firewalls and misconfigured host name resolution on the user's device.

cliffhall · 2025-04-24T20:09:45Z

client/bin/client.js

+
+            // Add the MCP_PROXY_FULL_ADDRESS to the response
+            jsonResponse.config = {
+              MCP_PROXY_FULL_ADDRESS: { value: mcpServerUrl },


Shouldn't this contain all the env vars that the client is interested in, i.e;

MCP_SERVER_REQUEST_TIMEOUT

MCP_REQUEST_TIMEOUT_RESET_ON_PROGRESS

MCP_REQUEST_MAX_TOTAL_TIMEOUT

MCP_PROXY_FULL_ADDRESS

Can they all be set an environment variables? If so, I'll update here.

client/bin/start.js

client/bin/client.js

client/src/lib/hooks/useConnection.ts

aaronpowell

Thanks for the review, just some clarifications before I make the changes (I'll admit I have gotten a little lost across some of the merges, given there's been a few releases since I started the PR 🤣)

client/bin/client.js

aaronpowell · 2025-04-25T03:02:14Z

client/bin/client.js

+
+            // Add the MCP_PROXY_FULL_ADDRESS to the response
+            jsonResponse.config = {
+              MCP_PROXY_FULL_ADDRESS: { value: mcpServerUrl },


Can they all be set an environment variables? If so, I'll update here.

client/bin/start.js

client/src/lib/hooks/useConnection.ts

flowing env vars to the client app for inspector

d290758

This allows you to set the SERVER_PORT or MCP_PROXY_FULL_ADDRESS as an environment variable and the value will be injected into the static app when it's run. Fixes modelcontextprotocol#256

pulkitsharma07 reviewed Apr 3, 2025

View reviewed changes

cliffhall requested changes Apr 3, 2025

View reviewed changes

cliffhall added enhancement New feature or request waiting on submitter Waiting for the submitter to provide more info labels Apr 3, 2025

aaronpowell commented Apr 3, 2025

View reviewed changes

Apply suggestions from code review

8c911d5

aaronpowell mentioned this pull request Apr 7, 2025

Specify transport type on startup #255

Open

cliffhall reviewed Apr 7, 2025

View reviewed changes

aaronpowell added 2 commits April 8, 2025 11:08

Making the server provide info on what transport to delete by default

d76a79a

Fixes modelcontextprotocol#255

aaronpowell force-pushed the aaronpowell/issue-256 branch from e041581 to d76a79a Compare April 8, 2025 01:20

aaronpowell requested a review from cliffhall April 8, 2025 01:21

Merge branch 'main' into aaronpowell/issue-256

3e89930

cliffhall requested changes Apr 8, 2025

View reviewed changes

aaronpowell added 3 commits April 24, 2025 16:05

Merge branch 'main' into aaronpowell/issue-256

0cfd10c

Fixing bad merge

b6b30d6

Unpacking value

71fb6bc

Merge branch 'main' into aaronpowell/issue-256

9c2a89c

cliffhall requested changes Apr 24, 2025

View reviewed changes

aaronpowell commented Apr 25, 2025

View reviewed changes

flowing env vars to the client app for inspector #258

Are you sure you want to change the base?

flowing env vars to the client app for inspector #258

Uh oh!

Conversation

aaronpowell commented Apr 3, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cliffhall left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cliffhall left a comment

Choose a reason for hiding this comment

Uh oh!

aaronpowell commented Apr 24, 2025

Uh oh!

cliffhall left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aaronpowell left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aaronpowell commented Apr 3, 2025 •

edited

Loading