Loading ToolBench
An MCP Server that acts as an agent and that can spawn more Agents, by using MCP.. MCP Inception!
Skynet-MCP has two tools with basic schema definitions but significant quality gaps. Tool naming is generic ('Invoke', 'DelayedResponse') without clear action verbs that reflect the semantic purpose. Descriptions exist but are brief (under 50 chars) and lack detail about when to use each tool, prerequisites, or recovery guidance. Parameter descriptions are present but minimal. Input schemas are defined with Zod but lack comprehensive output documentation. Error handling is minimal, UserError is thrown but no recovery guidance is provided. The server uses HTTP (SSE) transport, which is acceptable but deprecated. Overall, this is a functional but below-average MCP server that would not pass production code review.
Check the status of a delayed agent task or retrieve its result
Invoke the MCP-server's Agent implementation to handle a task
Tool names lack action verbs and semantic clarity. 'Invoke' and 'DelayedResponse' do not clearly communicate the action. LLMs expect names like 'execute_agent_task' or 'get_task_status' to infer intent before reading descriptions.
Tool descriptions are too brief (<50 chars). 'Invoke the MCP-server's Agent implementation...' lacks detail about WHEN to use it (vs other agent patterns), WHAT it returns, and prerequisites (e.g., must mcpConfig be pre-validated?). Descriptions should be 10 - 1024 chars with complete context.
No output schema documentation. The Invoke tool returns { content: [{ type: 'text', text: JSON.stringify(...) }] }, but the response structure is not formally documented. LLMs cannot plan downstream calls without knowing the return type (e.g., is it a string, an object, or raw JSON?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Error handling is minimal and non-actionable. When Invoke fails, it throws UserError('Failed to execute agent: ...'), which gives the LLM no recovery path. Should categorize as retryable, user-fixable, or fatal, and suggest next steps (e.g., 'Check mcpConfig syntax or retry with a simpler prompt').
Parameter descriptions are minimal and lack constraints. 'mcpConfig' is described as 'MCP-server config, tools for the agent to use' but does not specify the expected structure, required fields, validation rules, or examples of valid configs. 'llmConfig.provider' and 'llmConfig.model' lack enums of supported providers/models.
Delayed execution task storage is in-memory (Map<string, DelayedTask>). Tasks are lost on server restart. For production use, tasks must be persisted to a database with TTL, retry logic, and recovery guarantees.
No pagination or result limits documented. DelayedResponse returns an opaque 'response' field. If the agent task generates large output, the entire result is dumped into the response. Should cap result size and document limits in tool descriptions.
Credentials and LLM provider keys are passed as tool parameters (llmConfig.provider, llmConfig.model imply credentials). LangChain agent setup likely requires API keys, these must never appear in tool parameters. Use server-side secret injection via environment variables.
No permission checks. Any caller can invoke arbitrary agents with arbitrary LLM configs and prompts. Add scope declarations (e.g., 'write:agent') and verify caller authority before execution.
No input validation. mcpConfig is accepted as z.record(z.any()), no schema validation. prompt is a bare string with no length limits, injection checks, or sanitization. Untrusted input should be validated and sanitized.