Loading ToolBench
This MCP server provides a tRPC-to-MCP bridge with 2 tools. Both tools have critical definition gaps: missing or minimal descriptions, incomplete parameter documentation, and no output schema declarations. Tool 1 (give_feedback) has a description but lacks parameter descriptions. Tool 2 (userInfo__get) lacks any description entirely and has no parameter documentation. Neither tool documents what it returns. The framework elegantly auto-generates tools from tRPC routers, but the metadata extraction layer does not enforce description completeness or output schema documentation. Average tool score: 32 (give_feedback: 45, userInfo__get: 20).
Give feedback to the tool provider
userInfo__get tool has NO description. This tool is unselectable by LLMs without knowing what it does.
give_feedback lacks parameter-level descriptions. The 'message' parameter has no description explaining what kind of feedback is expected, max length, format, or how it will be used. LLMs cannot optimize the message content.
No tool documents its output schema or return type. LLMs have no visibility into what fields to expect from tool responses, blocking downstream chaining and data extraction planning.
userInfo__get uses flat naming (userInfo__get) rather than verb-first naming (get_user_info). This makes tool intent less obvious to LLMs scanning a tool list.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 18 | - | v1 |
give_feedback description (35 chars) is below the 50-char minimum for production. It states WHAT but not WHEN or WHY to call it, or what happens with the feedback.
The framework auto-generates tool registration from tRPC metadata but does not enforce output schema documentation. The McpMeta type only covers enabled/name/description, not output schema or error handling guidance.
Error handling in server.ts is minimal: a generic 'Could not find tool' response with no recovery guidance. If a tool call fails, the LLM receives no actionable error, only a text blob.
Tool procedures return unvalidated responses directly to the LLM. No filtering or shaping occurs (e.g., userInfo__get returns all fields including 'age' and 'email' that may not be necessary). High token cost, increased hallucination risk.