MCP server to MCP server chaining, proxying

[little0inker]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

MPC Architecture document describes the relationship and communication flow between a MCP client (the AI application) and MCP server (the tool/data/function provider).
Me being involved in IT world mostly arround network infrastructures, them in a role as platform provides. I feel there is another step towards further exposing AI to existing ecosystem the proposed MCP protocol can take. Perhaps the people are already aware of the potential and its just not written on the papper if that is the case, I am sory and please disregard the duplicate idea.

If not, and you see the potential your company can benefit from idea please pm me and send me some money :D

Consider having a network of MCP servers each having the ability of:

I # chaining or proxying. Ability to act both as MCP server and MCP client to another MCP server.

this example should demostrate the potential it could have:

    1. Initial Request: An AI application (MCP client or agent) needs to perform a complex task: 
    "Analyze our latest sales data from Salesforce and compare it against market trends from the Bloomberg API."

    2. The First Hop (Internal MCP Server): The AI client connects to company's internal MCP server (mcp.idontknow.com).
    3. The internal server receives the request. It looks at the required tools.
    - It has a tool called salesforce/query. It can handle that part.
    - it does not have a tool for bloomberg/market_trends.
    4. The Second Hop (Server-to-Server Communication): Instead of failing, the internal server has been configured to know about a trusted partner's MCP server (mcp.partner.com) that specializes in financial data.

    5. "mcp.idontknow.com" now acts as an MCP client. It opens a secure, authenticated connection to "mcp.partner.com."
    It forwards the part of the request related to market trends, essentially making a tools/call request for bloomberg/market_trends to the partner server.
    6. "mcp.partner.com" receives the request, authenticates it, executes the call to the Bloomberg API (using its own secure credentials), and returns the formatted result to mcp.idontknow.com.
    7. "mcp.idontknow.com" receives the market data, combines it with the Salesforce data it retrieved, and sends the final, complete answer back to the original AI client.

from the AI client's perspective, this entire complex chain was invisible. It simply made one request to one server and got one complete answer back.

II # Dynamic Exchange of Capabilities: Service Discovery

accomplished through a Service Discovery or Registry layer.

    - MCP Server Registry: Imagine a central (or decentralized) registry where MCP servers can register themselves and the tools they provide (e.g., using their tools/list response).
    - Dynamic Lookup: When mcp.idontknow.com. realizes it lacks a capability, instead of having a hardcoded address for the partner server, it would query the registry: "Who can provide the bloomberg/market_trends tool?"
    - Connection and Execution: The registry returns the address of a trusted, available server (mcp.partner.com), and the connection is made.

This would create a dynamic network where new servers with new capabilities can join at any time, and their tools become instantly discoverable and usable by the entire network. Each server can be highly specialized. You can have Finance MCP Server, Healthcare Data MCP Server, Security MCP server, Infrastructure tools MCP server,... each maintained by expert teams.

III # Secure Inter-Organizational Collaboration

Company A can grant Company B's AI access to a specific dataset or tool without sharing APIs, database credentials, or complex access policies. They simply authorize Company B's MCP server to talk to their own.

IV # Enhanced Security and Control

company can route all external tool requests through a single, heavily audited gateway MCP server, which then connects to third-party servers. This gives them a single point of control for logging, security scanning, and policy enforcement for all outbound AI interactions.

V # Resilience and Scalability

If one provider's server goes down, the registry could dynamically reroute requests to a backup or alternative provider, creating a more resilient system.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[scottslewis]

You might be interested in the 'remote' examples in the MCPToolGroups work:

https://github.com/ECF/MCPToolGroups

See specifically this mcp server implementation which uses a remote service proxy (remoteExampleToolGroup member variable) to dynamically create MCP Server tool specifications and add them to a running MCP Server.

These examples show the use of the OSGi Service Registry and the Remote Service Admin specification to define a dynamic 'services' layer that allows pluggable discovery protocols (e.g. etcd, multicast, etc) and pluggable distribution providers (e.g. MCP, https/rest, grpc, etc). The pluggable discovery and distribution allows the creation and use of 'service proxies' in the enhancement of MCP Servers without specifying a binding to a particular discovery or distribution protocol(s).

Such a service/proxy layer, combined with the work on dynamically (runtime) building and adding 'ToolGroups' to MCP servers allows the flexible use of use-case specific discovery and distribution protocols (including but not limited to MCP protocol).

The service layer/RSA work...although originated in Java via OSGi, also exists in Python and can/could easily exist in other languages.

[little0inker]

Hello, I apologize, but this ideas were raised as to be kept in mind or perhaps consider extending. It was not raised as a specific problem a person can subjectively understood and respond to, in specific way and close the threat. Thank you

[scottslewis]

Hello, I apologize, but this ideas were raised as to be kept in mind or perhaps consider extending. It was not raised as a specific problem a person can subjectively understood and respond to, in specific way and close the threat. Thank you

What? Are you saying the issue was raised to remain irrelevant to protocol migration/standardization?

What I'm doing as described above is already extending this idea.

Bonus: There is actually working code showing how this can/could work. In the real world, working code is generally considered a good thing, since the steps between 'vague idea' and 'working system' are usually not trivial.

If you don't want any actual community input, then I suggest you close this discussion.

[scottslewis]

Another point: I think that proxying/server chaining can/should be protocol and distribution system agnostic. MCP tools can/should be implemented (on mcp server-side) using protocols other than mcp (e.g. grpc, https/rest of whatever flavor, tcp, new protocols, etc). My guess is that many of the existing mcp servers are already doing this, by accessing existing (public and/or private) services via existing apis using existing protocols and existing security mechanisms.

I do think it would great to have mcp be a protocol that could be proxied also, but not in exclusion to the existing rpc distribution systems.