Loading ToolBench
A bridge server that converts MCP (Model Context Protocol) requests into REST API calls. Supports multiple transport modes (stdio, SSE) and handles authentication for downstream APIs via OpenAPI specifications.
MCP2REST has critical structural issues. Tools are inferred from code references rather than explicitly registered with complete schemas. Of 4 listed tools, only 'toolCall' has visible implementation in server.go; 'initialize' and 'notifications/initialized' appear to be MCP protocol lifecycle messages, not actual tools; 'tools/list' is referenced but not found in provided source. Input schemas are either missing or incomplete. Descriptions exist but are too generic to guide LLM selection. The 'toolCall' tool lacks output schema documentation entirely. No parameter descriptions exist for the 'parameters' field in toolCall. The server exhibits protocol-level confusion, mixing protocol-lifecycle events with actual tools.
Initializes the MCP connection with the client, exchanging protocol version and capability information.
Client notification indicating that initialization is complete and the server can now accept tool calls.
Generic tool call handler that accepts a tool name and parameters, looks up the corresponding OpenAPI operation, constructs and executes an HTTP request, and returns the result.
Returns the list of available tools derived from the OpenAPI specification. Each tool corresponds to an operation in the OpenAPI spec.
No input schemas visible for 'tools/list' and 'notifications/initialized'.
toolCall parameter 'parameters' has no description. Clients cannot understand what this object should contain or how it maps to OpenAPI operations. Parameter descriptions are required.
No output/return schema documented for any tool. LLMs cannot predict what fields will be returned or plan downstream tool calls. Pattern requires documented return types.
Tool definitions appear inferred rather than explicitly registered. No @tool decorators, registration calls, or explicit schema definitions visible in the provided source.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 33 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 16 | - | v1 |
initialize and notifications/initialized appear to be MCP protocol lifecycle messages, not user-facing tools. Conflating protocol events with actionable tools confuses tool discovery and LLM selection.
toolCall description (93 chars) lacks WHEN to use guidance. It describes the generic mechanism but not which scenarios require this tool vs others. Description should answer: when should the LLM call this instead of alternatives?
No error handling documented. The toolCall tool may fail due to invalid OpenAPI operation names, malformed parameters, or HTTP errors. No guidance provided for how an LLM should recover.
No parameter validation constraints visible. The 'name' parameter in toolCall has no enum of valid operation names, no pattern, no length limits. The 'parameters' object has no schema. Free-form input invites hallucinated values.