This is nice! I was thinking of writing something like this myself. One thing I ran into though is that Claude Desktop can't connect to the server-everything with the command you listed. This is in the server logs:
2025-03-11T16:29:00.168Z [@modelcontextprotocol/server-everything] [info] Client transport closed
› Error: Nonexistent flag: --tools echo,add
› See more help with --help
USAGE
$ god run [-t <value>]
FLAGS
-t, --tools=<value> Comma separated list of approved tools
Also, there's no logs for ~/mcpgod for me (that folder doesn't even exist)
I have seen a few of these tools and yet to see usefulness further than not having to edit config manually for each client. Wishlist for something I would use:
- Always run MCP in a sandbox
- If I am gonna browse open source MCP and try them out casually, I need to control permission better than approving tool calling blindly. I prefer to auto approve all calls but control permission for directory access (if run outside of sandbox), or network calls based on configurable criteria
most of the MCP tools use Python env (uvx) or Node or even Java to run ANY CODE on your machine, so even the python virtual env is a sandbox but it's to isolate the dependencies not the file/network access. If you are unlucky, you can still install a malware mcp server to clean up your disk or send your photos to somewhere. MCP servers are just local scripts. There are some permission control from deno but this is not the only runtime engine for MCP server. It'll be cool to have something like Chrome extension permission or iOS/Android permission ask, but I highly doubt this will be available since on your local server, there are just too many ways to run scripts.
Running a mcp tool is expected to be lightweight. Starting a docker container is not impossible but will make this process a bit heavy. Maybe in the future the MCP client can provide python/nodejs runtime and also have extra flag to allow the users to confirm the requested permissions for certain mcp tools. Today running MCP servers with whatever executable available locally is too risky
Hrm, re that error: What does “god --version” say?
The log might not show up until you get a successful connection. I’ll look into that.
Thanks for trying it out!
- Always run MCP in a sandbox
- If I am gonna browse open source MCP and try them out casually, I need to control permission better than approving tool calling blindly. I prefer to auto approve all calls but control permission for directory access (if run outside of sandbox), or network calls based on configurable criteria
- An UI for tracking of calls
That's not what a sandbox means. PATH enhancement for dependency management is... dependency management, has nothing for security.
> Too many ways to run scripts.
Which is why you need a tool, and not "just" run MCP. Not that hard to run in docker and configure volume mount/ports though.
The sandbox is spot on; Control what the server can do. Especially important when running locally