Loading ToolBench
An MCP Server for Wasm Components that serves tools/list and tools/call over Streamable HTTP, with support for component-backed tools and channel-backed tools
This server has critical definition quality issues. It exposes only 2 tools with minimal, generic descriptions. The 'tools/call' tool accepts arbitrary arguments without schema validation or guidance. The 'tools/list' tool lacks pagination details. No parameter descriptions are present. No output schemas are documented. The server is essentially a passthrough MCP gateway without proper tool wrapping or composition patterns. Tools are meta-tools (list/call) rather than domain-specific implementations, which violates the fundamental pattern of creating specialized, composable tools.
Call a tool with the specified arguments
List all available tools from components
Meta-tools instead of domain-specific tools. The server implements generic 'tools/list' and 'tools/call' handlers rather than wrapping actual business logic into named, purposeful tools. This violates the composition pattern, agents cannot discover or reason about what actual capabilities exist.
No parameter descriptions. The 'tools/call' tool accepts 'name' and 'arguments' but provides no guidance on what arguments are valid, their types, constraints, or format. The 'cursor' parameter in 'tools/list' lacks explanation.
No output schemas documented. Neither tool describes what structure it returns, what fields are included, or how pagination works. LLMs cannot plan downstream operations without knowing the response structure.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Generic, uninformative descriptions. 'List all available tools from components' and 'Call a tool with the specified arguments' are too vague. They do not explain WHEN to use these tools, what prerequisites exist, or what the agent should expect in the response.
No error handling guidance. No descriptions indicate what errors can occur, how to recover, or what the LLM should do if a tool call fails. E.g., what if a tool name does not exist? What if arguments are malformed?
Dangerous pattern: 'tools/call' accepts arbitrary 'arguments' (untyped object) with no validation. LLMs can pass any JSON; there is no schema enforcement, no per-tool validation, no guardrails against injection or misuse.
No pagination details in 'tools/list'. The cursor parameter is mentioned but not explained. Is it opaque? Base64-encoded? What does an empty cursor mean? Without clarity, LLMs cannot properly paginate results.
No tool-specific schema validation in 'arguments' parameter. The 'arguments' object in 'tools/call' is an untyped JSON object. The server does not document what keys are expected, their types, or valid ranges. This forces downstream validation inside the component layer.