/v1/responses requires server_url and appears to ignore mcp.json MCP config; chat UI MCP works (LM Studio 0.3.29)

[ZebraBeer]

Which version of LM Studio?
LM Studio 0.3.29 (0.3.29)

Which operating system?
macOS (Apple Silicon, Mac Studio) MacOS 26 Tahoe

⸻

What is the bug?

Calling the REST API /v1/responses with an MCP tool by server_label returns an error that a non-empty server_url is required, even though the same MCP server is configured in ~/.lmstudio/mcp.json and works in the chat UI.

Additionally, the error message says to “set the LM Studio server’s MCP mode to ‘all’”, but in 0.3.29 there is no “All” setting in the Developer → Settings UI (there’s just a toggle for allowing remote MCP). This makes the guidance impossible to follow.

I’ve reproduced this with both:
• stdio/command MCP (mcp-proxy with env),
• remote (url + headers) MCP (SSE with Authorization header in mcp.json).

⸻
Logs

API error response:

{
"error": {
"message": "Tool for MCP server 'home-assistant' requires a non-empty 'server_url' for a remote MCP server connection to be attempted. To use this MCP server via a locally running LM Studio plugin, add this MCP server to your mcp.json configuration with a "url" field and set the LM Studio server's MCP mode to "all".",
"type": "external_connector_error",
"param": "tools",
"code": "http_error"
}
}

(Happy to attach lms server logs from lms log stream --source server on request.)

⸻

To Reproduce
1. Ensure LM Studio server is running locally (http://localhost:1234).
2. In Developer → Settings, enable Allow remote MCP. Restart the server.
3. Create ~/.lmstudio/mcp.json with either of the following:

A) stdio/command (mcp-proxy)

{
"mcpServers": {
"home-assistant": {
"command": "/Users//.local/bin/mcp-proxy",
"env": {
"SSE_URL": "http://192.168.68.200:8123/mcp_server/sse",
"API_ACCESS_TOKEN": ""
}
}
}
}

B) remote SSE (url + headers)

{
"mcpServers": {
"home-assistant": {
"url": "http://192.168.68.200:8123/mcp_server/sse",
"headers": { "Authorization": "Bearer " }
}
}
}

4.	Restart the LM Studio server to reload MCP config.
5.	Call /v1/responses by label (no server_url in the payload):

curl -sS http://localhost:1234/v1/responses
-H "Content-Type: application/json"
-d '{
"model": "oss-gpt-20b",
"input": "Using Home Assistant MCP, list climate entity IDs only.",
"tools": [{ "type": "mcp", "server_label": "home-assistant" }],
"stream": false
}'

Actual

Returns the error above requiring server_url (and/or fails to connect), despite the label existing in mcp.json. The chat UI can use the same MCP successfully.

Expected
• The server should resolve server_label using mcp.json:
• If the entry has "command", use stdio MCP (no server_url needed).
• If the entry has "url" (and "headers"), use remote SSE with those headers (no server_url needed).
• The error text should not reference a non-existent “All” setting in 0.3.29.

⸻

Additional context
• The mismatch seems specific to the REST server resolving MCP labels; the chat UI works with the same configuration.
• The error messaging references an “All” server mode that is not present in the 0.3.29 UI, which may be outdated guidance.

[yagil]

Thanks for the bug report. At this moment, /v1/responses only supports remote MCPs. The error message “set the LM Studio server’s MCP mode to ‘all’” is misleading and should be fixed. Very soon (likely in 0.3.31) this will be possible. Will update in this issue

[ZebraBeer]

Thanks for the update—two quick clarifications: in 0.3.31, will the change simply fix the misleading error text (“set MCP mode to ‘all’”), or will /v1/responses also add support for local/stdio MCPs defined in mcp.json? And regarding current behavior, does “remote MCP” mean any SSE endpoint reachable by the LM Studio server, including private LAN/RFC1918 addresses (e.g., 192.168.x.x), or is it limited to publicly routable endpoints?

[An-m1654]

It seems that /v1/responses still either doesn't support local mcps or is not documented so that people would know how to do so. The annoying part is that lm studio clearly stated that it is, as of this comment, supported in the api endpoint comparison chart, but the responses page doesn't seem to document that.