llama.cpp Web UI Gains MCP Proxy for Tools

The web interface that ships with llama.cpp’s llama-server can now connect to Model Context Protocol (MCP) servers and expose their tools to a running model. The functionality is gated behind a command-line flag, --webui-mcp-proxy, which turns the browser-based UI into a proxy between MCP servers and the model.

How the Proxy Works

Browsers cannot talk to local processes over stdio, the transport many MCP servers use. To work around this, the llama.cpp web UI routes requests through a built-in CORS proxy served by llama-server, using a URL pattern such as http://localhost:8080/cors-proxy?url=.... That arrangement lets the browser reach cross-origin MCP servers, discover the tools they offer, and execute queries against them.

According to a pull request that fixed the transport handling (https://github.com/ggml-org/llama.cpp/pull/24500), the UI relies on HTTP-based transports because of the browser constraint. The supported options are WebSocket, StreamableHTTP, and Server-Sent Events (SSE). The PR corrected how SSE connections were detected and routed, since the earlier logic checked only for WebSocket URLs and otherwise defaulted to StreamableHTTP, so the SSE path was never taken. It also fixed a case where a relative message endpoint returned by an MCP server was resolved against the proxy URL, hitting the local origin and producing 404 errors instead of reaching the intended server.

Once a server is connected, its tool definitions are passed to the model as a JSON-RPC block. Reported tool names in one configuration included read_file, edit_file, build_project, execute_terminal_command, and web_search, which gives a sense of the file, build, shell, and search capabilities an MCP server can present.

A Known Multi-Server Bug

The MCP proxy is still maturing. An open bug report (https://github.com/ggml-org/llama.cpp/issues/24761), labeled bug-unconfirmed, describes a problem when more than one MCP server is connected at the same time. The reporter found that with two servers attached, the model could only see and use tools from the second server and had no awareness of the first server’s tools, such as web_search.

The reporter confirmed both servers worked individually. After disabling the second server, the model could call web_search again, which pointed to an invalid prompt being sent to the model rather than a broken server connection. The report notes the regression appeared recently, within roughly the prior week of the filing, on build version: 9686 (1a2dea29b9).

Practical Notes for Setup

Because the UI needs an HTTP-based transport, stdio-only MCP servers require a bridge. In one example from the SSE pull request, the author wrapped a stdio search tool using mcp-proxy, which spawns the underlying command as a subprocess and exposes it over SSE at an address like http://127.0.0.1:8000/sse. Another commenter encountered a 405 error pointing a different SSE server at the proxy, a reminder that individual MCP servers vary in how they implement the transport.

The overall picture is that llama.cpp’s browser UI can act as an MCP client, surfacing external tools to a locally hosted model, but the feature is recent and being actively debugged. Users running multiple servers or non-WebSocket transports should expect rough edges and may want to track the linked issues for fixes.