Support URL parameters for server URL and Transport Type in MCP Inspector for easier system integration
Is your feature request related to a problem? Please describe. I'm trying to use the MCP Inspector with a local development server, but I'm unsure if the current implementation supports connecting to a local SSE endpoint.
Describe the solution you'd like I would like to confirm if the MCP Inspector supports connecting to a local Server-Sent Events (SSE) endpoint, specifically using a URL structure like: http://localhost:5173/#resources?server=http://localhost:8000/sse If it's not currently supported, I'd appreciate if this functionality could be added to allow easier local development and testing.
Describe alternatives you've considered I've considered setting up a proxy to redirect local traffic to a supported endpoint structure, but direct support for local SSE endpoints would be more convenient and efficient for development workflows.
Additional context This feature would greatly enhance the development experience when working with MCP servers locally. It would allow developers to test their implementations more easily without the need for additional configuration or workarounds. Is this something that's currently supported or planned for future implementation? If not, what would be the best way to work with local MCP server instances using the MCP Inspector?
Will this work https://github.com/modelcontextprotocol/inspector/pull/177 for your use case ?
Will this work #177 for your use case ?
Enter it into the browser http://{mcp.inspector.host}:5173/#?url=http://{target.sse}:8000/&transport=sse , then mcp.inspector will fill in the parameters such as url, transport, etc., into the form. Similarly, for the stdio method, can you provide support?
I really need this feature. I’m working on an internal mcp market and want to use inspector as a debugging tool.
I really need this feature. I’m working on an internal mcp market and want to use inspector as a debugging tool.
@pulkitsharma07 Please support this feature, it's very helpful.
I think this request makes sense, but once we start supporting more settings in both the URL params and other places like localStorage, the order of what should override what gets a little more complicated.
My assumption would be that these URL params should take precedence in the case where both are set (which I don't think would happen often in practice, since if you're going through the trouble of setting URL params, you are probably not using this tool in your local browser)?
BTW, looks like this PR might address this issue? https://github.com/modelcontextprotocol/inspector/pull/333
Closing since I think this was covered by this PR but please re-open if needed.