Finding MCPProxy MCP servers efficiently

[aolin480]

I have been using MCPProxy for a few months now. I like the idea of it, but it's really eating away at tokens just trying to find a MCP server that is inside MCPProxy. Since these MCP servers are not at the top level, it takes about 3 - 4 responses from the agent just trying to find a MCP server, and it has to try in multiple different ways.

Have you ever thought of registering top level tools for each MCP server, so that maybe the agent has visibility into something like MCPProxy:codebase_context.find_code_references? I think this would make it easier for the agent to find, and I've used a similar app for macOS that does this, it was just that the app itself was garbage and unstable.

If there are any good tricks or tips or even configuration I can use to use this efficiently?

Thank you!

[armorer-labs]

One pattern that usually helps is to split discovery into two layers: a small top-level router surface and a detailed per-server manifest.

If every nested MCP server is only discoverable by asking the proxy to introspect itself, the model burns context just mapping the control plane. I would expose top-level tools or resources for:

• list available server namespaces with short capability summaries
• search tools across servers by intent and side-effect class
• return a compact schema/contract for one selected server/tool
• bind or pin a server for the current run so later calls do not rediscover it
• include policy hints like read/write, external network, credentialed, destructive

I would avoid registering every underlying tool as a flat top-level tool if the fleet can get large, because that can just move token cost into the initial tool list. A good compromise is stable namespace entrypoints like mcpproxy.search_tools, mcpproxy.describe_server, and mcpproxy.call(server, tool, args) plus aliases for the common servers you use daily.

The other thing I would want is a run receipt: which server/tool the proxy resolved, what contract/version it saw, and why that target was selected. That gives you a way to debug mistaken routing without making the agent explain it after the fact.

Disclosure: I work on Armorer Labs.

[aolin480]

Thanks @armorer-labs, and yes, that is a good point, and something that was brought up to do when I was researching this, to make a small top-level router surface. I think that would be a great addition too, and I could make that modification, but getting something more solidified and recognized by the repo author would be great. I could make a pull request for it. I am trying some other MCP proxy providers right now, just to see how they're working out of the box, vs having to add detailed global mcpproxy instructions for how to use it.

Obviously I have a small layer in my global AGENTS.md which says to look for mcp servers in MCPProxy before the top-level mcp servers, and that works, but it's just the query trying to find the MCP servers then.

Thanks for your suggestion. Depending on the success of these other vendors, if I decide to stick with MCPProxy, I can look into creating some kind of small layer for MCP discovery.

[armorer-labs]

That is exactly the tradeoff I would test: whether the proxy can give the model a small discovery surface without forcing a giant flat tool list.

If you make a PR, I would keep the first version intentionally boring:

• list_servers with short names, one-line capability summaries, and policy hints
• search_tools(query) returning only the top few matching tools with server namespace and side-effect class
• describe_tool(server, tool) returning the full schema only after the model has selected a candidate
• a resolved-call receipt in logs so you can see when routing chose the wrong server

That would let MCPProxy stay generic while still making the agent path shorter than “read global instructions, ask the proxy what exists, ask again for schemas, then finally call something.” The receipt/log part matters because otherwise a proxy can feel better in the happy path while making wrong routing harder to debug.

Disclosure: I work on Armorer Labs.

[S4GU4R0]

I built my own agent harness. I wrap the proxy tools and use the proxy to swap permissions depending on the mode the agent harness is in. it's kind of overkill, but it offers separation of concerns for me a bit.