Loading ToolBench
A Go-based MCP server that implements tool registration and execution with support for HTTP SSE and stdio transports. Provides logging control and tool call handling with LLM integration.
The Speelka Agent MCP server exposes only 2 tools with extremely minimal schema and description coverage. The 'test-tool' appears to be a placeholder/demo tool with a trivial single-string parameter ('arg') and generic description. The 'logging/setLevel' tool manages server logging but lacks proper constraints on its 'level' parameter. Neither tool has documented output schemas, and descriptions are too brief to guide LLM decision-making. Parameter descriptions are absent or vague. The server prioritizes internal configuration over user-facing tool quality. Code demonstrates awareness of MCP patterns (CallToolRequest handling, tool conversion utilities) but does not apply them rigorously to the exposed tools.
Tool for managing logging level on the MCP server
Main tool for the MCP server (name configurable via SPL_TOOL_NAME)
test-tool has a trivial, placeholder-like schema with only 'arg' (type string, description 'desc'). This appears to be a demo tool, not production-grade. No output schema documented.
logging/setLevel parameter 'level' lacks enum constraint or validation guidance. Description does not specify valid values (DEBUG, INFO, WARN, ERROR, etc.) or acceptable format.
No output schemas documented for either tool. LLMs cannot predict what data they will receive or plan downstream tool chains.
Tool descriptions are generic and brief (test-tool: 'Main tool...' ~40 chars; logging/setLevel: ~45 chars). Neither explains WHEN to use it, WHAT it returns, or prerequisites. Below the 50-200 char LLM-optimized range.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 34 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | - | v1 |
test-tool naming is vague. 'test-tool' does not start with an action verb and gives no hint of its actual purpose. Does not follow verb_noun convention (e.g., 'execute_test', 'run_workflow').
logging/setLevel modifies server state (changes log level), but the description does not explicitly state this is a destructive/state-mutating operation. Agents need to know which calls are safe to retry and which have side effects.
No error handling guidance in descriptions. If logging/setLevel receives an invalid level or test-tool fails, there is no hint for the LLM on what to do next (retry, ask user, etc.).