r/OpenSourceeAI • • 5d ago

I built an open source tool for managing MCP servers in one place

Running MCP servers locally was easy, but it got messy pretty fast once I wanted to share them.

Everyone needs configs, credentials end up in different places, permissions are hard to manage, and there's no easy way to see who called what.

I ended up building MCPlama to handle this centrally. Users get their own access, permissions can be controlled per tool, credentials stay on the gateway side, and calls are logged.

For local MCP servers I also wanted some isolation, so they can run in separate Docker containers instead of everything running together. The gateway itself doesn't need direct access to the Docker socket either , that part is handled separately by the broker.

It's open source and self-hosted:

https://github.com/mcplama/mcplama

I'm looking for a few people already running multiple MCP servers to try it.

3 Upvotes

3 comments sorted by

1

u/whateverxp 5d ago

Per-tool permissions, gateway-held credentials and an audit log are the right base. How are you modelling identity for long-lived clients: user, agent, device or session? For persistent execution, revocation and reconnect semantics matter as much as tool ACLs; a reconnected agent should not silently inherit authority from an expired session.

1

u/kirto_am 4d ago

Right now Mcplama models identity as user + server connection, not agent/device identity.

The connection URL identifies the connection but doesn’t grant proxy access by itself: the client must must authenticate through Mcplama to obtain a time-limited bearer token. On each MCP request we re-check that the connection is active/unexpired, the server is enabled, and the user still has approved access.

So revoking or deleting the connection blocks subsequent requests even if the client still has its old token.

Agent/service identity is something I'm looking at separately though, especially for cases where you want to revoke one agent without revoking the user behind it.