Loading ToolBench
MCP Server for DeepSeek API integration - enables Claude Code to use DeepSeek Chat and Reasoner models
The server defines 2 tools with decent structure but has moderate gaps. deepseek_chat has a comprehensive but verbose description and reasonable schema coverage, though some parameters lack depth. deepseek_sessions has good action-based naming and clear parameter descriptions. Both tools suffer from descriptions that are too long (exceeding the 200-char baseline for LLM efficiency) and some parameter descriptions that are vague. Output schemas are not explicitly documented in the visible code. Error handling descriptions are missing, LLMs cannot tell what errors are retryable or how to recover.
Chat with DeepSeek V4 models (deepseek-v4-flash, deepseek-v4-pro; chat/reasoner accepted as aliases). Supports function calling, thinking mode, JSON output, cost tracking, session management and automatic fallback to alternative models.
Fill-in-the-middle code completion using DeepSeek models. Completes code between prefix and suffix with context awareness.
Manage conversation sessions including listing active sessions, retrieving session history, clearing sessions, and displaying session statistics.
Tool descriptions are too verbose and lack LLM-optimized clarity. deepseek_chat description is ~230 chars (exceeds 200-char baseline), mixing multiple concerns (chat, reasoner, function calling, cost tracking, sessions, fallback) in one paragraph. This forces LLMs to parse intent from a bloated description.
Parameter descriptions lack specificity and format constraints. Parameters like 'thinking' (object), 'response_format' (object), and 'tools' (array) have minimal descriptions ('Thinking mode configuration', 'Response format specification') that do not explain expected structure, valid keys, or when to use them. LLMs cannot infer required fields or format.
Output schemas are not documented in the visible code. Neither tool explicitly documents what fields are returned, their types, or structure. The deepseek_chat tool especially, which can return cost info, thinking output, function calls, and session data, needs a clear output schema so LLMs know what data is available for downstream use.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 17 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | 1.27.1+ | v1 |
Error handling guidance is absent. Neither tool describes error conditions, retryable vs non-retryable errors, or how to recover. An LLM calling deepseek_chat with invalid parameters or hitting rate limits has no explicit recovery path.
The 'thinking' parameter description does not explain the object structure. Is it {enabled: boolean}? {enabled: boolean, budget_tokens: number}? Without documentation, LLMs must guess or fail.
The 'tools' parameter for function calling has a generic description ('Tool definitions for function calling') but does not explain format, required fields (name, description, parameters), or compatibility with OpenAI format. LLMs cannot construct valid tool definitions without explicit examples or schema.
The deepseek_sessions 'metadata' parameter is described as 'Custom metadata (optional for create and update)' but does not specify type (object), allowed keys, value types, or size limits. LLMs cannot determine what to pass.