Loading ToolBench
MCP server for WeGene Assistant, using LLM to analyze a user's WeGene genetic testing report.
This server exhibits foundational deficiencies across naming, parameter descriptions, and output documentation. All four tools lack input parameter descriptions despite having required parameters. Three tools have empty input schemas (wegene-oauth, wegene-get-profiles, wegene-get-report-info), violating the requirement that all parameters must have descriptions. wegene-get-report is the only tool with explicit parameters, but even those descriptions are minimal (10-25 chars, below the 20-char floor). No tool includes an output schema or describes the structure of returned data. Tool descriptions are generic and lack context about prerequisites, return types, or when to use each tool vs. alternatives. Error handling is absent from all tool definitions, there is no guidance on what the LLM should do if auth fails, profiles cannot be retrieved, or an invalid report_id is passed. The server uses stateful external systems (Redis for tokens, Flask OAuth callback) but does not document this dependency or how state transitions affect tool behavior.
Retrieve all the profiles under the current account
Get a specific genetic test report from a profile
Get all available report information
Authorizing a user's account using WeGene Open API with oAuth2 protocol and retrieve a valid access token for further use
LLMs cannot determine what these tools accept or require.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract chained data (e.g., profile_id needed for wegene-get-report). Violates requirement: 'Document the output schema' (pattern:tool).
E.g., 'The endpoint of the report' lacks context about expected format, constraints, or valid values. Description score capped at 20-40 for tools with underdescribed params.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No error handling guidance in any tool definition. If wegene-oauth fails (user denies consent, timeout expires), the definition does not tell the LLM what to do next. If wegene-get-report receives an invalid report_id, there is no recovery hint. Violates pattern:recovery-guide.
Tool descriptions lack context about prerequisites and sequencing. wegene-get-profiles and wegene-get-report both require a valid access token from wegene-oauth, but this dependency is not documented in the tool description. An LLM may attempt calls in wrong order.
OAuth flow uses polling with 120-second timeout (src/wegene_assistant/tools/oauth_tool.py). Tool definition does not document this timeout, the polling behavior, or what happens if timeout is reached. LLMs cannot reason about retry strategy or expected latency.
wegene-get-profiles returns a tuple (TextContent, List[Profile]) in code but tool definition does not document this structure. LLMs cannot extract profile_id from the response to pass to wegene-get-report. Response format is opaque.
wegene-get-report-info reads from a static config file (config/reports.json) but tool definition does not document this, the expected schema of reports, or when this tool should be called vs. alternatives. LLMs have no context.
Access token is stored in Redis with key 'wegene_access_token' but this state management is not documented in tool definitions. If token expires or is revoked, tools fail silently with no guidance on re-authorization. Violates pattern:idempotent-operation and state management clarity.