Strong tool definitions with comprehensive schemas and descriptions. All 15 tools have clear names following verb_noun pattern (request_*, response_*, reasoning_*, account_*, server_*). Descriptions are detailed (100-300 chars typical), exceeding the 10-1024 baseline. Input schemas are fully specified with Zod validation, enums for constrained inputs, and parameter descriptions. However, output schemas are not documented in the source code, LLMs cannot see what fields to expect from responses. Error handling is present but recovery guidance is minimal. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata.

• Document output schemas for all tools. For request_list, specify: returns {requests: [{id, title, status, createdAt, updatedAt}], total, offset}. For response_read: {content, model, usage, cost}. This enables LLMs to plan downstream calls.
• Add tool annotations via MCP protocol. Mark request_create, request_update, request_append, request_submit, request_batch with destructiveHint=true. Mark request_list, request_read, response_read, reasoning_read with readOnlyHint=true. Mark request_submit, request_batch with idempotentHint=false (not safe to retry if already submitted).
• Enhance error messages with recovery guidance. When request not found, return: 'Request id "xyz" not found. Call request_list() to see active requests.' When API rate limit hit, return: 'DeepSeek API rate limit exceeded. Retry in 60 seconds or reduce batch size.'
• Clarify HTTP transport in MCP initialization. Dockerfile exposes port 8799 with HTTP, but STDIO is detected. Ensure server advertises HTTP transport capability in the initialize response so hosted clients can connect.
• Add pagination limits to request_list description. Currently accepts offset/size but no stated max. Specify: 'size must be 1-100 (default 20)' to prevent LLMs from requesting 10,000 items at once.