Loading ToolBench
REST + OpenAPI facade over the Robinhood MCP server
This server exposes 3 meta-tools for managing a REST facade over an upstream MCP server. All three tools lack input parameter schemas entirely, no JSON Schema definitions visible in the code. Tool descriptions are present but minimal (10-50 chars). The server is a proxy/gateway pattern, not a domain-specific tool collection, which limits applicability of standard tool quality rubrics. However, by MCP standards, even meta-tools require proper schema documentation for LLM consumption.
Health check endpoint returning server status, upstream connection, tool count, and feature flags
List all available upstream tools with their metadata, access levels, HTTP methods, and schemas
Re-read the upstream tool list. New tools need a restart to get routes.
No input schemas defined for any tool. healthz, list_tools, and refresh have no visible JSON Schema parameter definitions. LLMs cannot validate inputs or understand what parameters are accepted.
Tool descriptions are too brief (10-50 chars). 'Health check endpoint...' and 'List all available...' lack context on WHEN to call these tools or what the LLM should do with results. Baseline is 194 chars; these are 30-40% of that.
refresh tool description does not explain the consequence of calling it ('Re-read the upstream tool list'). It is a WRITE operation that modifies server state, but the description does not warn the LLM of this or explain when it is safe to call.
No output schemas documented. Callers cannot know what fields healthz or list_tools return without reading the code. LLMs need documented return types to plan downstream actions.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2025-06-18+ | v2 |
No error handling guidance. If refresh fails or healthz reports 'disconnected', the tool provides no recovery hints. Error responses should guide the LLM on what to do next.