mcp-mesh
Related Servers
Alternatives to mcp-mesh
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityAmaintenanceEnables clients of tool-heavy MCP aggregators to find and use upstream tools on demand through four fixed bridge tools (search, describe, call, refresh), cutting per-turn tool context from ~180k tokens to ~2–3k. It merges multiple upstream servers behind sticky sessions and a local lexical BM25 index, so only the schemas actually needed are retrieved.9MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to connect to multiple upstream MCP servers while dynamically returning only semantically relevant tools, with lazy schema loading, session-aware boosting, and rule-based gating to reduce token bloat and improve performance.MIT
- AlicenseNot gradedqualityAmaintenanceAggregates tools from multiple upstream MCP servers and exposes them through 4 meta-tools, enabling LLMs to discover and use hundreds of tools without loading all schemas upfront.153 PyPI3Apache 2.0
- FlicenseAqualityAmaintenanceA multiplexing gateway that aggregates multiple MCP servers into a single port, significantly reducing context token usage through a Meta-MCP discovery system. It enables dynamic tool discovery and invocation across various transport protocols including stdio, HTTP, and SSE.1585-
- AlicenseNot gradedqualityDmaintenanceActs as a proxy for multiple MCP servers, reducing context window usage from 15,000+ tokens to ~500 tokens by dynamically loading servers on-demand and exposing only 3 tools instead of all tool definitions.5GPL 3.0
- FlicenseNot gradedqualityBmaintenanceSingle gateway that aggregates dozens of upstream MCP servers, enabling AI clients to connect once and access all tools.-
TDQS
Scored across 4 tools
Each tool targets a distinct stage of the gateway workflow: search (discovery), describe (schema inspection), invoke (execution), and status (monitoring). There is no meaningful overlap, and boundaries are reinforced by clear verb choices.
All tools share a consistent 'mesh_' prefix with snake_case, and three follow a verb_noun pattern (describe_tool, invoke_tool, search_tools). mesh_status is a noun-style name, a minor deviation from the otherwise predictable convention.
Four tools is tightly scoped to the meta-server/gateway purpose: discover, inspect, invoke, and monitor. Each tool earns its place with no redundancy or filler.
The search -> describe -> invoke lifecycle is fully covered, with status for observability. Minor gaps exist, such as listing connected servers or refreshing the tool index explicitly, but agents can work around these via status and search.