multi-agent-bridge
Related Servers
Alternatives to multi-agent-bridge
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityDmaintenanceEnables multiple LLM agents across devices to form teams, share knowledge, memory, and tasks with live status via a web dashboard and distributed-systems reliability.Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables multiple AI coding CLIs (Claude Code, Gemini/Antigravity, Codex, and OpenCode) to collaborate as a coordinated team by routing cross-agent prompts, sharing messages and review tickets, tracking tasks on a shared store, and isolating each agent in its own Git worktree with turn-budget safeguards—all inspectable and steerable from a local web dashboard.MIT
- AlicenseNot gradedqualityAmaintenanceEnables distributed teams and their AI hosts to coordinate through shared task queues, persistent memory, consensus constraints, and Feishu cloud sync, with automatic context injection and silent observation.MIT
- AlicenseNot gradedqualityAmaintenanceConnects multiple AI agents (Codex, Claude Code, Grok, etc.) into a coordinated, auditable team with shared memory, task ownership, and human oversight, enabling parallel collaboration without conflicts.241Apache 2.0
- FlicenseNot gradedqualityNot gradedmaintenanceA production-grade coordination hub that enables AI agents and human teams to work as a single organism by sharing tasks, context, decisions, and persistent memory across projects. It features two-tier agentic memory with per-agent hot caches, inter-agent messaging, and multi-agent authorship tracking for seamless collaboration.2-
- AlicenseAqualityDmaintenanceMulti-agent orchestration server that enables parallel task delegation, sequential pipelines, cron scheduling, and cross-model peer review via CLI providers like Codex, Antigravity, OpenCode, and Claude Code.4226 npm6MIT
TDQS
Scored across 63 tools
Several tools overlap in purpose: run_codex/run_claude/run_qwen/etc. duplicate agent_invoke with a name parameter; read_file/list_dir mirror worker_read_file/worker_list_dir; multiple messaging read tools (inbox_read, inbox_wait, bus_history) share retrieval semantics. Boundaries are often defined only through context (worker vs bridge), so an agent can easily misselect.
All names use snake_case, but the ordering convention is inconsistent: many tools follow domain_action (task_create, memory_search), while others use verb_noun (read_file, list_dir, run_codex). Prefixes are mostly grouped by domain, but mixed verb/noun order reduces predictability.
63 tools are far beyond the recommended 3-15 range and exceed the 50+ extreme-mismatch threshold; many tools (e.g., six run_* wrappers, duplicate file APIs, parallel memory and messaging interfaces) could be consolidated. The server’s complexity may justify breadth, but the count is excessive and burdens selection.
The surface covers task lifecycle, agent management, workflows, messaging, vector memory, file ops, checkpoints, and stats, leaving few functional gaps. Minor missing operations like task update/edit or bridge-side file write are workable via agents or task forking.