This config also works with llama-cpp server…
Start a local proxy with uvx and point it to Tomo’s config…
uvx mcp-proxy --named-server-config mcp-config.json --allow-origin "*" --port 8001 --stateless
You can install uvx with homebrew if you don’t already have it.
Then, start llama-cpp server with the --webui-mcp-proxy flag.
My launch line currently looks like this…
nohup llama-server \
--models-dir ./models/ \
--jinja -c 0 \
--host 127.0.0.1 --port 8033 \
--offline \
--models-max 1 \
--webui-mcp-proxy \
> "logs/llama-server.$(date +%Y%m%d_%H%M%S).log" 2>&1 &
Then in the llama-cpp server web ui, add the mcp server as…
http://127.0.0.1:8001/servers/devonthink/mcp
Now your local chats with local models should be able to connect to your local proxy and talk to your local DEVONthink MCP server. Local.
Side note: you’ll see I’ve got concurrent models loaded set to 1 because I’m substantially poorer than Sam and Dario and can’t afford more than 32Gb of unified right now. I comfortably switch between gpt-oss-20b-mxfp4 for general purpose (MoE model, actually really good given its size) and then qwen3.5-9b-mxfp4 for tight-context coding (small blocks / functions, not entire workspaces / repos).
I can actually run both of those at the same time if I up --models-max to 2. But my mbp starts to sound like an aircraft carrier and there’s nothing left in the memory bank for anything else.
I’ve tried working those models on larger contexts and with agentic workflows using pi. I don’t think they’re smart enough (although I think you can probably do a lot more than most realise by working on the harness, adding skills and mcp hooks).
Ideally though, you’d want one of the qwen 30b models or larger. (I can actually get that to run at a squeeze… but it’s far too slow for any practical use.)