Loading ToolBench
A full-stack MCP server for user profile management and vault game functionality with OAuth 2.1 authentication
Four tools defined in src/server/mcp/tools/index.ts with minimal quality. All tools have short, generic descriptions (14 - 49 chars) well below the 50 - 200 char LLM-optimized baseline. Input schemas are present but sparse: two tools have empty input objects (no parameters), two have single parameters with descriptions. Tool names are action-verb-based (get_, update_, submit_) and follow basic conventions, but descriptions lack context on WHY to use each tool, WHEN to call it, and actionable guidance on output. No documented output schemas for any tool. No error handling guidance. No pagination, composition hints, or downstream chaining information. Overall, the tools are functional but under-specified for LLM planning and error recovery.
This tool gets the user profile.
This tool gets the current vault game information.
This tool submits a combination to try to unlock the vault game.
This tool updates the user profile.
All tool descriptions are under 20 characters (range: 14 - 49 chars). Baseline is 50 - 200 chars for LLM-optimized descriptions. Descriptions must explain WHAT the tool does, WHEN to use it (vs. similar tools), and any output/context. Current descriptions are too terse for LLMs to reason about tool selection.
No output schemas documented for any tool. LLMs cannot infer what fields to expect, breaking downstream tool composition. For example, after calling get-profile, the LLM cannot chain to other tools because it does not know what fields the response contains.
Input parameter descriptions are generic or missing semantic detail. 'User profile context' (update-profile) does not explain what 'context' means, what format it expects, or what values are valid. 'The combination number to submit' does not specify numeric range, allowed values, or retry semantics.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
No error handling guidance. Tools do not describe failure modes, recovery paths, or actionable error messages. For example, submit-vault-combination does not explain whether repeated calls are idempotent, how many attempts are allowed, or what to do if the combination is invalid.
Parameter naming is inconsistent with type hints. 'combination' in submit-vault-combination is typed as 'number' but not suffixed with '_code' or other semantic marker. If multiple numeric parameters exist, ambiguity increases.
get-profile and get-vault accept no input parameters, yet no documentation explains whether they operate on the current user, a session context, or a default resource. Implicit dependencies on server-side state are not documented.