Ways to reduce tool context overload

[duaraghav8]

Problem

When a user adds multiple MCPs to mcpjungle, they end up with potentially 100s of tools being exposed via the global MCP endpoint.
This means every LLM interaction includes the basic metadata about all these tools, causing unnecessary context overload and token costs, reducing LLM accuracy.

This is a widely faced & discussed problem.

Current Solutions

MCPJungle currently already provides Tool Groups to allow you to cherry-pick specific tools and create a new MCP endpoint that only exposes those tools. User can point the agent to this special endpoint and the LLM only sees the select few tools, reducing context burden.
This is great for specialized agents in whose case, user knows upfront the limited set of tools that are relevant.

Proposed Ideas

I'd like to propose multiple ideas on how else mcpjungle could better serve its users on this issues.

Here are some ideas from me and I'm open to hearing feedback on them / more ideas:

1. mcpjungle could introduce a new mode in which it only exposes 3 tools - list_mcp_tools, describe_tools, call_tool
   When the LLM starts the interaction, it can decide whether it needs to explore the tools available. If yes, it calls list_mcp_tools which then returns 2 pieces of info for each tool - name & description. LLM can then choose to get full info about 1 or more tools using describe_tools and finally, use call_tool and pass it tool name + payload to invoke the desired tool(s).

This removes the 100s of tools in the context upfront but increases the back-and-forth between agent & mcpjungle.

2. Expose a search_tools tool.
   The LLM describes what kind of tool(s) it is looking for (what it wants to achieve) and mcpjungle could return best results for tools. Then the LLM could call the call_tool like I described above.

3. Explore how we can work with Skills

4. Some people are experimenting with Code mode, ie, LLM writes code that orchestrates all the tools rather than being directly exposed to them.

[devilankur18]

this will be very helpful. One of the next level changes, that i have faced is that apis responses are not optimised for MCP, so claude context get populated very fast, if there is way one can control tool response easily via a config, think of graphql for MCP, that would be really powerfull, this will save a lot of time and effort to change existing endpoints. this is a huge pain.

[duaraghav8]

great point, and something I've personally faced.

1 good way is for mcpjungle to introduce "middlewares" - you can write custom code which mcpjungle can run after getting response from mcp tool, before returning it to the agent.
the middleware can perform extra processing on the response data - like making it more LLM-friendly, removing unnecessary info, etc.

But yeah, some graphql for mcp would be an ideal solution here.

[ankittk]

After reading skills, I think it solves different problem
It solve "how to use tools effectively", not "how to reduce tool context".

Lets say: "When doing code review, first read the PR diff, then check for security issues, then..." - it's a sequential knowledge, not tool reduction.

Even with Skills, if we have 100 tools, the agent still sees 100 tools. Skills tell the agent which tools to use and how but the tools are still all there in context.

It is best when

• The LLM doesn't know our workflow: Package your team's procedures
• We want reusable agent capabilities: Build once, use across agents
• We need domain expertise: Legal review, data analysis pipelines
• We want version-controlled agent knowledge: Skills are just folders in git

The first idea could solve this better
Meta-tools (solve the immediate token/context problem), It has the tool metadata. We need to just changing when it's exposed, not what have to store. This is exactly how large APIs work (discovery > describe > call).
OpenAPI has /paths for discovery, then call specific endpoints.

So instead of exposing 100 tools, just 3 is fine

• list_mcp_tools: Returns name + description of all available tools
• describe_tools: Returns full schema for specific tool by name
• call_tool: Invokes any tool by name + payload

[duaraghav8]

you're right, skills don't limit the tools LLM sees.
This would require the MCP protocol itself to somehow integrate well with tools.
Maybe like "These 20 tools will only be exposed if LLM loads skill X".

So I agree that until MCP as a protocol introduces some skill integration, there's not much we can do in this direction.

[MitulShah1]

I really like the Dynamic Discovery (Option 1) with the 3 meta-tools. It's exactly the right approach instead of dumping 100+ tool schemas upfront, let the LLM discover what it needs.

But I want to echo @devilankur18's point about response bloat. Even if we fix the input side, a single tool call returning 50KB of JSON still destroys the context window on the output side.

Idea: Add JSONPath Projection to call_tool

What if we extend call_tool to accept an optional projection parameter using JSONPath

Instead of:

call_tool("github__list_repos", {})  // returns 50KB of data

The LLM could do:

call_tool("github__list_repos", {}, projection="$.repositories[*].name")  // returns just names

How it works:

1. LLM calls tool with projection parameter
2. MCPJungle executes the actual tool on the MCP server
3. Server returns full response (50KB)
4. MCPJungle applies JSONPath filter server-side
5. Returns tiny filtered result to LLM (1KB)

This way MCPJungle acts as a smart proxy—MCP servers don't need to change, they keep returning full responses. MCPJungle just filters before sending to the LLM.

Token Savings Example

Getting list of registered servers:

Approach	Input	Output	Total
Current (100 tools pre-loaded)	20K	12K	32K
Meta-tools + Projection	800	200	1K

That's 97% less context used.

Why This Works

• Solves both input bloat (meta-tools) AND output bloat (projection)
• Backward compatible—no MCP protocol changes needed
• MCPJungle controls everything, servers unchanged
• Basically "GraphQL for MCP"

for skills and search_tools idea

Skills - Agreed with @ankittk, they solve workflow problems not context reduction. Until MCP protocol lets Skills conditionally expose tools, they won't help here.

search_tools - Could work but semantic search is tricky. Meta-tools + projection is more deterministic.