Most active commenters
  • gavinuhma(4)

Show HN: MCPGod: Fine-grained control over MCP clients, servers, and tools

(github.com)
37 points gavinuhma | 12 comments | 11 Mar 25 12:58 UTC | HN request time: 1.264s | source | bottom

Hey everyone, I've wanted an easy way to control which mcp server tools are available to clients. So for example, I might want a gmail server to only expose the read tool (but not send, delete etc).

I figured if I create a cli for spawning mcp servers, I could intercept the stdin, stdout, stderr etc and modify what the clients see when they are making calls to list tools, resources, and prompts.

Well it worked!

In the initial version you can easily add a server to claude with a safe list of tools:

npx -y mcpgod add @modelcontextprotocol/server-everything --client claude --tools=echo,add

Now when you load Claude Desktop, it will only discover the echo and add tools from that server. It's a nice way to keep the agents in line :)

You can check it out here: https://github.com/mcpgod/cli

It will also log everything that a client is doing to ~/mcpgod/logs.

Currently it only has support for claude, but it will be easy to add cursor, cline, windsurf, etc.

With the `tools` command you can list all of a servers tools, and even call a tool directly from the command line, which is pretty fun.

I was thinking it would be nice to create a UI for it to easily enable/disable servers and tools for each client, inspect logs, view analytics, etc.

Thanks for reading!

1. nbbaier ◴[11 Mar 25 16:33 UTC] No.43334200[source]▶
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)
replies(1): >>43337770 #
2. gavinuhma ◴[11 Mar 25 22:26 UTC] No.43337770[source]▶
Thanks!!

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!

replies(2): >>43337797 #>>43338705 #
3. gavinuhma ◴[11 Mar 25 22:29 UTC] No.43337797{3}[source]▶
I’ve made the mistake of typing “--tools echo” before instead of “--tools=echo”, just in case that was your error too.
replies(1): >>43362413 #
4. nbbaier ◴[12 Mar 25 00:32 UTC] No.43338705{3}[source]▶
I removed the original config and ran the following:

  19:28:36 ~ $ npx -y mcpgod --version
  mcpgod/0.0.2 darwin-arm64 node-v23.9.0

  19:28:47 ~ $ npx -y mcpgod add @modelcontextprotocol/server-everything --client 
  claude --tools=echo,add
Same error and log occured
5. nsonha ◴[12 Mar 25 07:36 UTC] No.43340718[source]▶
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

- An UI for tracking of calls

replies(2): >>43344597 #>>43368379 #
6. gavinuhma ◴[12 Mar 25 15:58 UTC] No.43344597[source]▶
Awesome feedback. I’ll think through this.

The sandbox is spot on; Control what the server can do. Especially important when running locally

7. therealpygon ◴[14 Mar 25 13:22 UTC] No.43362413{4}[source]▶
What a polite way to point out that their error was a typo.
8. Prosammer ◴[14 Mar 25 16:38 UTC] No.43364334[source]▶
Looks cool! Do you see this as something that should be handled by the MCP spec in the future? I'm surprised this isn't built in already.
9. jovezhong ◴[14 Mar 25 23:23 UTC] No.43368379[source]▶
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.
replies(1): >>43368985 #
10. nsonha ◴[15 Mar 25 01:02 UTC] No.43368985{3}[source]▶
> virtual env is a sandbox

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.

replies(1): >>43370231 #
11. jovezhong ◴[15 Mar 25 05:32 UTC] No.43370231{4}[source]▶
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