Loading ToolBench
A Model Context Protocol server implementation in C that exposes C functions as MCP tools through JSON-RPC over stdio
This MCP server has critical gaps in definition quality. Only 5 tools are registered, and most lack proper documentation. The server is a C-language MCP framework implementation that exposes 3 protocol-level tools (initialize, notifications/initialized, tools/list) and 2 domain tools (get_flag, get_scores). Tool descriptions are minimal or generic, parameter descriptions are sparse, input schemas are incomplete or missing for most tools, and output schemas are not documented. The codebase shows substantial C++ AST analysis infrastructure but does not translate to well-defined agent-facing tools. STDIO-only transport further limits production readiness.
Returns a flag for authenticated users
Returns the current scores
Handles the 'initialize' JSON-RPC request. Constructs the server's response containing its capabilities and info.
Handles the 'notifications/initialized' JSON-RPC notification. Processes initialization completion.
Returns all available function signatures in JSON format
Tool naming violates verb_noun convention. 'notifications/initialized' is a path-like identifier, not a verb_noun pair (e.g., should be 'handle_initialized' or 'confirm_init'). 'initialize' is a verb but does not follow the action_object pattern. LLM cannot infer intent.
Descriptions are critically insufficient. 'initialize' has 100+ chars but is generic MCP protocol documentation, not agent guidance. 'notifications/initialized' has no description explaining WHEN or WHY to call it. 'get_flag' and 'get_scores' have 25-30 char descriptions (below 34-char p10 baseline) and lack context for agent selection.
Input schemas are incomplete or absent. 'initialize' schema includes client capabilities and info but lacks descriptions on nested object properties (what is 'roots.listChanged'? what is 'sampling.maxTokens'?). 'notifications/initialized' has empty input (correct) but no explanation of side effects. 'get_flag' requires auth_token (security risk, see separate issue) but does not document token format, lifetime, or source. 'get_scores' accepts no input but does not document filtering/pagination options.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 36 | 2026-07-28+ | v2 |
Output schemas are not documented anywhere. Tools return data but agents have no structured definition of what fields to expect. 'tools/list' presumably returns available tools but the schema is not visible in the provided code. 'get_flag' and 'get_scores' results are undocumented, agents cannot plan downstream calls or extract fields reliably.
Security: 'get_flag' exposes 'auth_token' as a tool parameter. Credentials must NEVER appear in tool parameters, agent logs, traces, and prompt history will capture them. Use server-side secret injection (environment variables, vault) instead.
Protocol-level tools should not be exposed as agent-facing tools. 'initialize', 'notifications/initialized', and 'tools/list' are MCP infrastructure calls, the server should handle them internally, not advertise them as callable tools. Domain tools ('get_flag', 'get_scores') are not tied to any domain model or use case.
Parameter descriptions are missing or trivial. 'auth_token' has description 'Authentication token' but does not specify: format (JWT? opaque? API key?), where to get it, expiration, required scopes. This forces agents to guess or fail.
No error handling guidance. Tools do not document error conditions (e.g., what if auth_token is invalid? expired? missing?), recovery paths, or retryability. Per the rubric, error responses must tell the LLM what to do next, these tools provide none.