Loading ToolBench
A full-stack application for syncing Douban (books, movies) and other platform data to Notion. Includes a Python scraper microservice, Go backend API, and Next.js frontend.
This MCP server exhibits significant definition quality gaps across multiple dimensions. Tool names are inconsistent (duplicate 'bind' and 'sync' tools with overlapping purposes), descriptions lack depth and clarity for LLM selection, and parameter schemas are present but minimally documented. Critical issues include missing input validation guidance, no documented output schemas, inconsistent naming conventions, and missing error handling patterns. Only 5 of 22 tools have descriptions exceeding 50 characters. Parameter descriptions are sparse or generic (e.g., 'Platform to bind: douban, weread, or flomo' without explaining what binding does or when to call it vs sync). No tool demonstrates the complete pattern of actionable error guidance, recovery steps, or idempotency guarantees. The server conflates authentication, data synchronization, and chat management tools without clear composition patterns.
Delete multiple chat sessions.
Start platform binding process (status, start, refresh, or delete).
Start platform binding (QR login + initial sync). Returns SSE stream.
Change user password.
Get synchronized community data for all platforms.
Delete user account (soft delete).
Delete a specific chat session.
Get messages from a specific chat session.
Duplicate tool names with overlapping semantics: 'bind' appears twice (scraper and auth variants), 'sync' appears twice (scraper and auth variants). This violates the single-responsibility principle and will confuse LLM tool selection. The two 'bind' tools have different signatures (one includes platform/user_id/channel, the other uses action enum with 'status'/'start'/'refresh'/'delete' operations), making it unclear which to invoke for platform binding.
No documented output schemas for any tool. Tool descriptions state 'Returns SSE stream' or 'Returns...' but never specify the JSON structure, field names, or types of returned data. LLMs cannot plan subsequent tool calls or extract necessary IDs (e.g., session_id, user_id) without knowing the response shape.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Health check endpoint.
List all chat sessions for the authenticated user.
Login with email and password.
Logout current user and revoke access token.
Get current authenticated user profile.
Refresh profile for bound platform.
Register a new user account with email and send verification code.
Rename a chat session.
Send a chat message and receive streaming LLM response via SSE.
Start data synchronization for a platform.
Data sync for bound platform. Returns SSE stream.
Logout from platform before unbinding.
Update user profile information.
Verify email with code and create user account.
Parameter descriptions lack actionable constraints and validation guidance. Examples: 'Platform to bind: douban, weread, or flomo' (does not explain what binding does, when to use it, or prerequisites); 'Serialized session state' (no format, encoding, or source specified); 'List of existing book URLs to skip duplicates' (no format, encoding, or max length). Per the rubric, descriptions should include expected format, range, allowed values, and examples.
Missing error handling and recovery guidance. No tool description explains failure modes, retryability, or what the LLM should do if a call fails. E.g., bind() with SSE streaming could fail mid-stream, is it retryable? Should the agent ask the user? How does it know the session is partially initialized?
Inconsistent parameter naming conventions. Some tools use snake_case (session_state_json, user_id, existing_book_urls), others use camelCase (session_id). Tool descriptions do not clarify which parameters are required vs optional, or state dependencies (e.g., 'If you have existing_book_urls, sync() will skip those, call refresh() first to populate the list').
Destructive operations (delete, deleteSession, batchDeleteSessions) lack confirmation or dry-run mechanisms. Descriptions do not warn that these are irreversible or offer a recovery path. Per the rubric, agents make mistakes, a confirm_before_execute pattern or explicit warning is required.
Tool composition is unclear. The 'bind' → 'sync' → 'refresh' workflow is not documented. A user intent like 'Sync my Douban data to Notion' requires calling multiple tools in sequence, but descriptions do not guide the LLM through the steps or explain dependencies (e.g., 'Call bind() first to authenticate; sync() will fail if binding is incomplete').
Credential/session handling is unclear. 'session_state_json' parameter appears in multiple tools but is never defined, no format, encoding, source, or lifetime is documented. Is it opaque to the LLM? Should it be refreshed on every call? Can it expire? This violates the secret-injection pattern and creates security ambiguity.
Tool descriptions for auth operations are generic. 'Login with email and password', 'Register a new user account', 'Verify email with code' are minimal (under 60 chars). Per the rubric baseline, tool descriptions should average 194 chars and answer: What does it do? When to use it? What does it return? How does it integrate with other tools?
No indication of tool state or idempotency. Calling sync() twice with the same parameters, does it duplicate records, skip duplicates, or fail? Calling send() twice, does it create two messages? Agents retry on ambiguous failures; non-idempotent tools risk side effects.