Loading ToolBench
MCP proxy and fallback tool server with support for multiple transport modes (STDIO, HTTP Streamable, SSE, WebSocket)
Broxy is a test/demo MCP server that exposes transport-agnostic tool definitions across STDIO, HTTP, SSE, and WebSocket. All 20 tools have adequate naming (verb-based: add_, subtract_, multiply_, divide_, prompt_hello_, resource_) and descriptions (10-50 chars, which is SHORT per the 10-1024 char baseline). However, parameter descriptions are MINIMAL (1-2 words: 'First operand', 'Name to greet', 'Resource ID parameter') rather than the baseline 72 chars. No error handling guidance is visible in the definitions. Output schemas are NOT documented, we see only input schemas with basic type/description pairs. Tool definitions are inferred from test code rather than directly from tool registration source (TestServerProfiles.kt), which caps visibility. While schemas are present and valid JSON Schema, they lack richness (no constraints, no pagination details, no chaining IDs in outputs). This is a pedagogical server demonstrating transport capabilities, not a production-grade tool suite.
Adds two numbers via STDIO
Divides two numbers via WebSocket
Multiplies two numbers via HTTP SSE
Says hello via Streamable HTTP
Says hello without arguments via Streamable HTTP
Says hello via HTTP SSE
Says hello without arguments via HTTP SSE
Says hello via STDIO
Parameter descriptions are critically short (1-2 words: 'First operand', 'Name to greet'). Baseline is 72 chars average. LLMs cannot infer parameter semantics from 'First operand' alone, e.g., does 'a' accept floats, decimals, or only integers?
Tool descriptions are SHORT (10-50 chars vs baseline 194 chars). 'Adds two numbers via STDIO' lacks context on when to use this tool vs alternatives, what it returns, or whether it modifies state. Descriptions should be 50-200 chars for optimal LLM selection.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Says hello without arguments via STDIO
Says hello via WebSocket
Says hello without arguments via WebSocket
HTTP sample text
HTTP template text
SSE sample text
SSE template text
STDIO sample text
STDIO template text
WebSocket sample text
WebSocket template text
Subtracts two numbers via Streamable HTTP
Output schemas are NOT documented. Tool definitions show input schemas only. LLMs cannot plan downstream calls or extract chaining IDs (e.g., if a resource tool returns an ID, what field name is it?). All tools must document return types.
No error handling guidance in tool descriptions. If divide_ws gets 0 as divisor, what happens? Can the LLM retry? Should it ask the user? Descriptions must clarify error conditions and recovery steps.
Arith tools (add_stdio, subtract_http, etc.) have no constraints on numeric inputs. Can 'a' and 'b' be negative? Large numbers? Decimals? Unbounded parameters let LLMs pass absurd values.
Resource tool naming is ambiguous. 'resource_test://resource/stdio' does not convey WHAT the resource contains or what it represents. Names like 'get_system_config', 'fetch_doc_content' are clearer. Current names force LLMs to guess intent.
Tool definitions appear to be inferred from test code (TestServerProfiles.kt) rather than directly visible in production tool registration. Code review cannot fully verify implementation details, constraint enforcement, or actual runtime behavior.