Giving Your Local AI Real Tools with MCP

What MCP actually adds

Everything else in this pillar gives you a model that answers from what it already knows - its training data, plus whatever you've pasted into the chat or uploaded to a Knowledge collection. That's genuinely useful, but it's still a closed box. The model has no way to reach out and check something for itself.

Model Context Protocol - MCP - is an open standard that gives your model a way to actually do things: read a real file, fetch a live web page, query a database, on demand, at the moment you ask.

It's become the standard way local AI tools expose capabilities to models, for one practical reason: build a filesystem tool once, and it works with any MCP-compatible client - Open WebUI, Claude Desktop, VS Code, your own scripts. Before MCP, every tool integration was custom-built and incompatible with the next one.

Open WebUI's native support

Open WebUI added native MCP support directly in its admin settings. This works out of the box for MCP servers that speak Streamable HTTP - a newer transport built for exactly this kind of web-based, multi-user setup:

1. Go to Admin Settings → External Tools
2. Click + (Add Server)
3. Set Type to MCP (Streamable HTTP)
4. Enter the server's URL and any auth it needs (none, a bearer token, or OAuth)
5. Save

Once added, enable it per chat: click + → Integrations → Tools in the message box and turn the tool on. Only admins can add servers - this isn't something individual users configure for themselves, which is a deliberate safety boundary.

The catch: most servers need a bridge

Here's the part that trips people up: most of the popular, ready-made MCP servers - filesystem access, web fetching, SQLite - don't use Streamable HTTP. They use an older transport called stdio, built for local desktop tools like Claude Desktop, not a web app like Open WebUI.

The fix is mcpo, a small proxy built by the Open WebUI team specifically for this. It runs a stdio-based MCP server and exposes it as a normal REST API that Open WebUI can talk to:

uvx mcpo --port 8000 --api-key "top-secret" -- npx -y @modelcontextprotocol/server-filesystem /home/youruser/Documents

That one command starts the official filesystem MCP server and wraps it in a local API at http://localhost:8000, with interactive docs at http://localhost:8000/docs so you can see exactly what it exposes before wiring it up.

A real example

With the filesystem server running through mcpo and enabled in a chat, try asking about a real file sitting in that folder:

Summarize the PDF called Q3-report.pdf in my Documents folder.
What's in the notes.txt file from earlier this week?

The model doesn't guess or hallucinate the contents - it actually calls the tool, reads the real file, and answers from what's genuinely there. That's the whole point: the gap between "an AI that answers questions" and "an AI that does work."

What actually goes wrong

The tool doesn't show up in Open WebUI

Confirm you're actually logged in as an admin - regular accounts can't add or see External Tools configuration, by design. Also double check the Type was set correctly: a plain MCP server needs "MCP (Streamable HTTP)," while an mcpo-wrapped server is really just a normal API endpoint.

"Connection refused" when Open WebUI tries to reach mcpo

mcpo has to actually be running in a terminal for Open WebUI to reach it - it's not a background service by default. If you closed the terminal it was running in, it stopped. Start it again, or set it up as a proper background service if you want it to survive a reboot.

The model doesn't use the tool even though it's enabled

Confirm the tool is actually toggled on for that specific chat via + → Integrations → Tools - it doesn't carry over automatically between conversations. Also worth trying a more direct prompt ("check the file" rather than a vague question) - some smaller models need a clearer nudge to reach for a tool instead of just answering from general knowledge.

Common questions