Loading ToolBench
MCP server for neural speech codec full-duplex dialogue with bidirectional audio streaming and simultaneous listen/talk capabilities
The server defines only one tool, 'execute_skill_action', with minimal implementation. The tool has a brief description but NO visible input schema, no parameter definitions, and no documented output structure. The entire MCP server implementation is a stub: it prints a JSON status message but does not actually implement the MCP protocol (no stdin/stdout message loop, no tool invocation handling). The tool definition is inferred from a string in the status output, not explicitly registered with a proper schema. This fails nearly all 54 patterns: no constrained inputs, no error recovery guidance, no composition support, and no actionable documentation for LLM tool selection.
Execute a skill action for the neural speech codec full-duplex dialogue engine
No input schema visible for execute_skill_action. Tool definition appears as a string in a print statement, not as a proper tool registration.
Tool description is 111 characters but extremely generic ('Execute a skill action for the neural speech codec full-duplex dialogue engine'). Does not explain WHEN to use it, WHAT it modifies, or what parameters it accepts. Fails pattern:tool-description requirement: 'Write descriptions as if prompt-engineering. State WHAT the tool does, WHEN to use it, and any prerequisites.'
No parameter documentation. execute_skill_action must accept some input (the client takes 'incoming_audio_chunk_bytes' and 'sample_rate_hz'), but the MCP server source shows no parameter schema, type definitions, enums, or descriptions. Agents cannot infer valid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 18 | 2026-07-28+ | v2 |
No output schema documented. The client.py shows the tool should return fields like 'duplex_turn_id', 'codec_framerate_hz', 'bidirectional_latency_ms', etc., but the MCP server implementation contains no documentation of these fields, their types, or availability. LLMs cannot plan downstream calls without knowing the response structure.
MCP server is not actually implemented. mcp_server.py prints a status message once and exits. No stdin/stdout message loop, no handling of tool invocation requests, no response formatting. The code is a stub that does not follow the MCP protocol specification for STDIO transport (must continuously read JSON-RPC messages from stdin and write responses to stdout).
No error handling or recovery guidance. No documentation of failure modes, retryability, or what the LLM should do if the tool fails. Violates pattern:recovery-guide.
Tool name 'execute_skill_action' is vague and generic. Does not follow verb_noun convention clearly (it is verb_noun but the action is unclear). 'execute' is too abstract. Does not disambiguate what the skill action does or what domain it serves. Pattern baseline: 90% of A+ tools start with a specific action verb (get, create, send, update, search), this one uses 'execute' which is ambiguous.
No security declarations. No documentation of permissions required (does this tool write to external services? Does it need authentication tokens?). Tool has WRITE risk but no scope declaration or audit trail guidance. Violates pattern:scope-declaration and pattern:secret-injection.