Describe the bug

The current Model Context Protocol (MCP) implementation introduces significant data redundancy in prompt words, particularly during multi-turn interactions. This manifests as repeated injection of structural information, such as JSON schemas, tool lists, and capability metadata, leading to context bloat. In environments with limited token windows (e.g., 128K–1M tokens), this redundancy inflates prompt size, degrades model efficiency, and restricts the viable number of tools to approximately 7–12, constraining overall system scalability.

To Reproduce

Steps to reproduce the behavior:

1. Initialize an MCP session with a set of 10+ tools, each defined with full metadata (e.g., schemas for inputs/outputs, descriptions, and capabilities).
2. Engage in a multi-turn conversation requiring incremental context updates (e.g., a query chain involving tool selection and state changes).
3. Observe the prompt payload across turns: structural elements like tool manifests and schemas are reinjected without delta updates, resulting in exponential token growth.

Expected behavior

The protocol should minimize redundancy by supporting incremental or differential context updates, ensuring that static metadata (e.g., tool schemas) is cached at the session level and only changes are transmitted. This would maintain prompt conciseness, enable handling of 50+ tools without performance degradation, and align with model-friendly designs that prioritize semantic efficiency over verbose engineering artifacts.

Logs

N/A (This issue is conceptual and reproducible in any MCP-compliant implementation; specific logs would depend on the runtime environment, such as token counts from a model API like OpenAI's GPT series).

Additional context

This redundancy stems from MCP's function-centric architecture, where tools are exposed holistically, leading to layered nesting and lack of distinction between model-cognitive needs (e.g., tool names and parameter summaries) and system-level metadata. To address this, we propose a data-centric semantic pipeline protocol (DCSPP) as an alternative:

• Core Shift: Center the system on "data entities" (e.g., structured objects like UserProfile or TradeRecord), each with a fixed schema and concise descriptive prompt. Functions become atomic operations mapped to these entities, inverting the tool-first paradigm.

• Semantic Layering: Introduce unique labels (for input entity binding) and multi-tags (for purpose classification, e.g., "search", "edit"). LLM interaction follows a staged retrieval: (1) Query operable entities; (2) Select entities to derive available tag unions; (3) Filter tags to expose relevant functions; (4) Compose entity-bridged pipelines for execution.

This approach reduces context exposure by up to 80% through progressive revelation (entities → tags → functions), supports unbounded tool extensibility via semantic indexing, and draws from RISC principles and dataflow programming for composable, stateless operations. Implementation could involve a lightweight manifest for entities/tags, with LLM-guided verification of outputs against the original query. Feedback on prototyping this as a MCP extension or standalone spec would be appreciated.