Not all mcp servers are relevant for all clients

[technicalpickles]

There are tons of MCP out there that assume they are being run from the directory the MCP client is.

For example, ast-grep-mcp will run in the directory it’s started from, or take an explicit directory to run from.

If a user is running a single mcpproxy (which is encouraged by having things like a menu bar to manage), it could get confusing to add ast-grep-mcp to use in one project, but then another project ends up trying to call it and gets results for the wront project.

Another example is having a private mcp server for your work, that simply doesn’t apply to projects not in your company’s github org.

I have a few ideas, but wanted to try to describe the general problem I’d like to solve.

[Dumbris]

@technicalpickles Thanks for raising this important issue!

My understanding of the issue (please correct me if I'm wrong): When running mcpproxy as a global daemon, MCP servers that operate on files/directories (like ast-grep-mcp, filesystem, git servers) run from mcpproxy's working directory instead of your actual project directories. This causes servers to search/operate in the wrong location and creates issues when working across multiple projects.

Potential solution: We'll add a working_dir field to the server configuration, allowing you to specify exactly where each MCP server should run from:

  {
    "mcpServers": [
      {
        "name": "ast-grep-project-a",
        "command": "uv",
        "args": ["run", "ast-grep-mcp"],
        "working_dir": "/home/user/projects/project-a",
        "enabled": true
      },
      {
        "name": "ast-grep-work",
        "command": "uv",
        "args": ["run", "ast-grep-mcp"],
        "working_dir": "/home/user/work/company-repo",
        "enabled": true
      }
    ]
  }

And this is already available for Docker isolation: If you're using Docker isolation, working directory support is already partially implemented:

  {
    "docker_isolation": {
      "enabled": true,
      "memory_limit": "512m",
      "cpu_limit": "1.0"
    },
    "mcpServers": [
      {
        "name": "ast-grep-secure",
        "command": "npx",
        "args": ["ast-grep-mcp"],
        "isolation": {
          "enabled": true,
          "working_dir": "/home/user/projects/secure-project"
        },
        "enabled": true
      }
    ]
  }

With Docker isolation, the specified working_dir is mounted into the container and set as the working directory, providing both security isolation and correct directory context.

You can also use different names for the same MCP server type (like ast-grep-personal vs ast-grep-work) and instruct your LLM in the prompt which context to use: "Use ast-grep-work for analyzing the codebase".

[technicalpickles]

• Thanks! I started writing some ideas, but it disappeared on me. Having a working directory for isolation makes a lot of sense.

Some other ideas I was thinking through:

Different groups of mcp servers. Profile and group are names that come to mind, or maybe tagging? I could imagine either having different "mcpServers", or adding metadata to the existing ones.

Separate endpoints for different clients. It could be different processes/ports, or query parameters. Maybe that indicates the profile/group/tag to expose?

add group/profile/tags parameters to search/call/etc. Instead of having different mcp servers endpoints/url parameters, clients can specify it as parameters.

templates servers. If you want to run ast-grep-mcp, I could imagine having a template, and then varying the parameters, env variables, working directory based on.

I realize some of these are mutually exclusive, but wanted to get the ideas out there!

[Dumbris]

Now I got it.
My proposal: In-Proxy Profiles + Permanent URLs

We can add named profiles that scope tool discovery and calls.
New endpoints:

• http://localhost:8080/mcp/{profile} (session-pinned)
• Default: http://localhost:8080/mcp (switchable)

Rough Plan:

1. Config: add

"profiles": [
  {
    "name": "work",
    "servers": ["ast-grep-mcp"]  // reference to mcpServers.name
  }
]

(We need to migrate existing setups into a single default profile.)
2. Routing: /mcp uses the current active profile (switchable); /mcp/{slug} pins the session to {slug}.
3. Index/Discovery: single index with a profile field; retrieve_tools filters by profile.
4. Enforcement: call_tool validates the tool’s profile; out-of-profile calls suggest switching.
5. Switching: tray selector; optional MCP tool set_profile changes the active profile for /mcp.

This keeps one proxy process, offers simple UX, and avoids cross-project confusion while still allowing power users to bookmark stable URLs per profile.

Regarding “template servers”: in the current version you can say to the LLM, for example, “Add upstream server ast-grep-mcp-project1, copy all parameters from server ast-grep-mcp-work, but use /tmp/files as the working directory.”
Usually, this works well for me because mcpproxy has tools to manage upstream servers. Did you try it?

[technicalpickles]

That makes a lot of sense to me 👍🏻

Regarding “template servers”: in the current version you can say to the LLM, for example, “Add upstream server ast-grep-mcp-project1, copy all parameters from server ast-grep-mcp-work, but use /tmp/files as the working directory.”
Usually, this works well for me because mcpproxy has tools to manage upstream servers. Did you try it?

I actually haven't actually, mostly because I'm managing my own MCPs running in docker as streamable-http servers. A big reason for that is #58 I wrote up

[Melodeiro]

Very good idea. I'm thinking about profiles when i want to enable different set of tools for different agents. I would add 2 cents here, that being able to specify exact tool list is even better. Maybe even in a combined list like:
["full-server-1", "partial-server-2:tool-1", "partial-server-2:tool-2"].

+1 for the "In-Proxy Profiles + Permanent URLs"

As for working directory, another idea that comes to mind is to add required parameter to the tool schema, and let the LLM to specify it dynamically. Thats how some tools function already, for example, Jetbrains MCP. Often this is useful, especially when you are working in a multi-project environment from a single session, or when you LLM want to narrow down the working area. But as everything that comes with LLMs, here comes fallibility, so hardcoding a path is also a good option