Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Hi all,

I'm working on a solution to mitigate the degraded reliability performance that occurs when a large number of MCP-exposed tools are available to an LLM. When too many tools are exposed to a single agent, the LLM's ability to choose the right one deteriorates, resulting in less effective behavior.

I'm exploring whether an AI orchestration framework behind an MCP server is a valid way to handle this—both from a protocol compatibility standpoint and in terms of long-term maintainability.

🧠 The Problem: LLM Confusion with Large Tool Libraries

In setups where an MCP client interacts with a single agent that has access to many MCP-backed tools, LLM performance drops. With too many options, the model becomes less consistent and often makes poor tool selection choices.

The goal is to keep the tool context lean and focused, while still supporting a broad range of capabilities.

⚙️ The Architecture: Orchestrator + Sub-Agent Model

• The MCP client connects to an MCP server that exposes a small number of composite tools—each representing a task that may require calling other MCP servers.
• These composite tools are actually wrappers around AI workflows, implemented using any orchestration framework (LangGraph, AutoGen, CrewAI, or custom).
• The orchestrator workflow is composed of multiple sub-agents, each configured as an MCP client connected to a single MCP server with a minimal toolset.
• This allows agents to remain focused, reducing tool overload and improving LLM reliability.

🔁 The Challenge: Approval Propagation

Here's where things get tricky: the client only sees a single high-level tool call (to the orchestrator). That orchestrator may call other MCP-backed tools through sub-agents—but if one of those calls requires user approval, there's no clear mechanism in MCP to propagate that approval request back to the original client.

Ideally, I'd like to:

1. Surface approval requests back to the originating MCP client,
2. Let the client approve or reject the request, and
3. Resume orchestration with the result of that decision.

This keeps the agent chain in control, while allowing the user to stay in the loop on sensitive or consequential decisions.

❓ The Questions:

1. Is this a valid architectural pattern?
   This seems like a clean way to balance tool breadth with clarity, but MCP doesn't appear to support approval forwarding natively. Is this just an unsupported use case—or a misapplication of the protocol?

2. If viable, what's the best way to implement this?

   • Using custom MCP messages to proxy approval requests?
   • Stubbing tool calls until approval is received?
   • Manual pause/resume flow inside the orchestrator?

3. Are there other approaches to reduce tool confusion without fragmenting execution this much?

I'd love to hear from anyone who's explored similar agent-based orchestration models with MCP—or who's run into and solved LLM confusion issues in large tool contexts.

Thanks for any insight you can offer!