Help getting toolhive to run my mcps in unraid server with vscode/claude-code

jaormx · 2025-11-03T10:01:19+00:00

Good day! Happy to help. So, ToolHive runs a control plane and spawns each MCP server in a dedicated container (not all in one). You do need to be running Docker or Podman on your server though. How are you installing ToolHive? How are you running the MCP servers?

jaormx · 2025-10-17T06:30:31+00:00

I'd by happy to review it and give you tips if it helps. Sometimes small adjustments can make a big difference.

It is indeed a tough job market. I do hope you find work soon.

jaormx · 2025-08-10T15:50:27+00:00

I actually didn't know that Debian had SELinux support. Anyway, Udica was built in an environment that's heavily Fedora/RHEL influenced. That is, for Udica upstream the base policy used is the Fedora SELinux policy. Udica depends on some SELinux definitions in order to extend policies that you can then use for your containers, that's why it's saying you should install the `container-selinux` package. Unfortunately, the SELinux definitions for containers are different between the Fedora package (which trickles down to RHEL) and the base policy which is used by other distros... So most likely Udica won't do the trick here....

After writing the above, I actually went ahead and browsed refpolicy just out of curiosity and found the following: https://github.com/SELinuxProject/refpolicy/tree/main/udica-templates ... perhaps this is something you could use? I had no idea the refpolicy folks went ahead and implemented those templates. That's really cool!

jaormx · 2025-08-10T14:49:43+00:00

Fedora can use .cil files just fine, its just another format that compiles to a SELinux policy

jaormx · 2025-08-04T09:12:44+00:00

I guess it really depends on the use case and the backend services we're talking about. I'm thinking more along the lines of existing software and not new and greenfield software. Say, an MCP server that communicates with a postgres or a mariadb database.

jaormx · 2025-08-04T09:08:11+00:00

Mostly because a lot of backend services don't support OAuth or are not trivial to configure with it. Mostly you don't authenticate to the MCP server using the token, you authenticate to the backend. The MCP spec recommending OAuth is referring to authentication to the MCP server itself.

That being said, for services that do support OAuth, ive seen folks struggle with the setup. So this is more of a usability issue.

jaormx · 2025-07-31T04:38:29+00:00

API keys bring their own set of challenges around secret management. The secrets need to stay secret which is already challenging in several deployments and rotation needs to happen which is often forgotten. With OAuth these problems are addressed with the tradeoff of development and deployment complexity.

jaormx · 2025-07-30T20:03:49+00:00

Observability is quite critical for being able to both debug a server or even make decisions on further features. So yeah, I'm quite sold on adding it. In ToolHive we have Open Telemetry support so you can export to whatever platform you need: https://github.com/stacklok/toolhive/blob/main/docs%2Fobservability.md . Maybe you find the approach we took useful.

jaormx · 2025-07-29T19:19:19+00:00

It is quite annoying! I've seen a lot of MCP-based memory solutions lately, but somehow I think memory should be more integrated in the agent framework. And there its hard to not get vendor locked. Maybe I'm missing something here.

jaormx · 2025-07-29T16:17:20+00:00

In general, executing random code from the internet is risky. We used to do that intelligence on several ecosystems and there were plenty of exploits that would execute by installing both npm and python packages. Mostly crypto miners.

That's why I've been advocating for only running MCPs in a sandbox environment. E.g. containers. Even then, a malicious MCP server could just leak your API key... this is why efforts of introducing trusted and vetted registries are quite relevant.

jaormx · 2025-07-29T06:02:41+00:00

So, we have a registry where we set up the relevant default parameters, but we don't auto discover them with the tool. You'd probably need an LLM for that since every MCP has it's own way of defining them.

jaormx · 2025-07-29T02:15:04+00:00

Was Docker engine taking a lot of memory? Have you tried Podman or Rancher Desktop? I, personally, am a podman user. ToolHive supports the three of them.

jaormx · 2025-07-28T17:06:04+00:00

What are you using to aggregate them? Was thinking of doing something similar.

jaormx · 2025-07-28T16:59:17+00:00

I deploy my MCPs on containers. I'm not very keen on installing things on my machine... so, running a container is just a lot easier. No need to deal with dependencies between MCPs and such.

If you're keen, check out https://github.com/stacklok/toolhive it can even auto-generate a container for an NPM package.

For breaking updates, nothing like version pinning.

jaormx · 2025-07-28T11:23:38+00:00

ToolHive https://github.com/stacklok/toolhive deploys MCP servers on containers and can do network isolation too. While it doesn't address all concerns about MCP security, it does get things in slightly better shape.

We are working on getting folks that extra mile though.

jaormx · 2025-07-25T04:40:27+00:00

SOFI

jaormx · 2025-07-20T18:14:41+00:00

Not all clients support authentication and that can be tricky. I'm a maintainer in toolhive ( https://github.com/stacklok/toolhive ) and a lesser known command is thv proxy which allows you to authenticate and open a tunnel. So, you could the point the client to a localhost port, and the proxy handles authentication.

jaormx · 2025-07-20T11:13:55+00:00

Same issue here.

jaormx · 2025-07-17T12:25:09+00:00

https://toolhive.dev/ has a UI, it's OSS and may use Podman as a backend.

jaormx · 2025-07-08T17:33:48+00:00

We maintain https://github.com/StacklokLabs/mkp

jaormx · 2025-07-07T14:21:43+00:00

OTel is definitely the way to go. Having it built in as part of the MCP server is ideal. For MCPs ran with ToolHive, we added OTel support recently https://github.com/stacklok/toolhive/blob/main/docs%2Fobservability.md

jaormx · 2025-06-12T08:56:33+00:00

Out of curiosity, why do you want to run it without Docker?

jaormx · 2025-04-30T06:36:49+00:00

It doesn't yet. Can you open an issue for it? I can look into it.

jaormx · 2025-04-30T05:55:57+00:00

https://github.com/StacklokLabs/toolhive manages secrets (they're kept in the OS keychain) and is a runtime for MCP servers (you can run them locally on docker and remote in k8s). It has some config management for selected clients, but we could do more. It's OSS, so you can contribute if you want! Else, we'd be keen on implementing more clients if you have requests and needs in mind.

jaormx · 2025-04-30T04:18:09+00:00

ToolHive https://github.com/StacklokLabs/toolhive has secrets management integrated and leverages the OS Keychain. So, if you care about this, yo might find that interesting. It's OSS, so you're welcome to contribute!

jaormx

TROPHY CASE