Loading ToolBench
MCP server for bidirectional AI agent collaboration — spawn and communicate with any AI coding agent CLI
Agent Link MCP demonstrates solid tool naming and composition patterns but has inconsistencies in parameter descriptions and output schema documentation. All 6 tools are explicitly registered with verb-starting names (spawn_agent, spawn_agents, reply, kill_agent, list_agents, get_status), which is strong. However, parameter descriptions vary significantly in quality and completeness. spawn_agent and spawn_agents have comprehensive nested schemas with good context parameters, but output schemas are not documented in the source code provided. The tool descriptions themselves are clear and actionable (10-150 chars, within ideal range), but several parameters lack sufficient constraint documentation (e.g., 'thinking' parameter should enumerate valid values rather than just saying 'e.g. "low", "medium"'). Error handling is present but recovery guidance is minimal. Security considerations around agent spawning and session management are not explicitly documented in tool descriptions.
Get the status of all active agent sessions.
Terminate an active agent session and clean up its resources.
List all known agents and their availability on this system.
Reply to an agent that is waiting for clarification. Continues the conversation until the agent returns a result or asks another question.
Spawn an AI agent to work on a task. Returns a question if the agent needs clarification, or a result when done.
Spawn multiple AI agents in parallel. Each agent runs independently and results are returned together. Great for getting multiple opinions, parallel code reviews, or distributing subtasks.
Output schemas not documented in tool definitions. LLMs cannot plan downstream operations without knowing what fields are returned (e.g., does spawn_agent return agentId, result, question, metadata?).
'thinking' parameter in spawn_agent and spawn_agents accepts free-form strings (described as 'e.g. "low", "medium", "high", "max"') but should be an enum to prevent hallucinated values like 'extreme' or 'deeper'.
'agent' parameter in spawn_agent/spawn_agents described as free-form string (e.g. 'claude', 'codex', 'gemini', 'aider') without enum constraint. Should enumerate supported agents to prevent invalid agent names and force LLM to call list_agents first for discovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
No recovery guidance in error responses. If spawn_agent fails, the tool description doesn't tell LLM whether to retry, escalate thinking, call list_agents, or give up. Error handling lacks decision logic.
Idempotency not documented. Tools like 'reply' and 'kill_agent' are state-mutating but descriptions don't clarify whether they are idempotent (safe to retry) or if retries risk duplicate effects.
No permission/scope documentation. Tools that spawn agents and manage sessions don't describe what authorization checks apply. Should declare required scopes (e.g., 'spawn:agent', 'manage:sessions') for audit and least-privilege configuration.
'model' parameter described as 'Passed via --model flag' but doesn't enumerate valid models. Examples like 'o3', 'gpt-5.4', 'claude-sonnet-4', 'gemini-2.5-pro' suggest future/unreleased models. Should use enum with actually supported models or link to dynamic discovery tool.
list_agents and get_status descriptions are generic (70 chars). They should clarify what distinguishes 'known agents' from 'active sessions' and when to call each. Example: 'Lists all agents detected on this system and their availability status (reachable/unavailable).'