Deepseek MCP Server
Quick Start
Remote (No Install)
Use the hosted endpoint directly — no npm install, no Node.js required. Bring your own DeepSeek API key:
Claude Code:
claude mcp add --transport http deepseek \
https://deepseek-mcp.tahirl.com/mcp \
--header "Authorization: Bearer YOUR_DEEPSEEK_API_KEY"Cursor / Windsurf / VS Code:
{
"mcpServers": {
"deepseek": {
"url": "https://deepseek-mcp.tahirl.com/mcp",
"headers": {
"Authorization": "Bearer ${DEEPSEEK_API_KEY}"
}
}
}
}Local (stdio)
Claude Code:
claude mcp add -s user deepseek npx @arikusi/deepseek-mcp-server -e DEEPSEEK_API_KEY=your-key-hereGemini CLI:
gemini mcp add deepseek npx @arikusi/deepseek-mcp-server -e DEEPSEEK_API_KEY=your-key-hereScope options (Claude Code):
-s user: Available in all your projects (recommended)-s local: Only in current project (default)-s project: Project-specific.mcp.jsonfile
Get your API key: https://platform.deepseek.com
Related MCP server: DeepSeek MCP Sample
Features
DeepSeek V3.2: Both models now run DeepSeek-V3.2 (since Sept 2025)
Multi-Turn Sessions: Conversation context preserved across requests via
session_idparameterModel Fallback & Circuit Breaker: Automatic fallback between models with circuit breaker protection against cascading failures
MCP Resources:
deepseek://models,deepseek://config,deepseek://usage— query model info, config, and usage statsThinking Mode: Enable thinking on deepseek-chat with
thinking: {type: "enabled"}JSON Output Mode: Structured JSON responses with
json_mode: trueFunction Calling: OpenAI-compatible tool use with up to 128 tool definitions
Cache-Aware Cost Tracking: Automatic cost calculation with cache hit/miss breakdown
Session Management Tool: List, delete, and clear sessions via
deepseek_sessionstoolConfigurable: Environment-based configuration with validation
12 Prompt Templates: Templates for debugging, code review, function calling, and more
Streaming Support: Real-time response generation
Multimodal Ready: Content part types for text + image input (enable with
ENABLE_MULTIMODAL=true)Remote Endpoint: Hosted at
deepseek-mcp.tahirl.com/mcp— BYOK (Bring Your Own Key), no install neededHTTP Transport: Self-hosted remote access via Streamable HTTP with
TRANSPORT=httpDocker Ready: Multi-stage Dockerfile with health checks for containerized deployment
Tested: 265 tests, ~89% line coverage
Type-Safe: Full TypeScript implementation
MCP Compatible: Works with any MCP-compatible CLI (Claude Code, Gemini CLI, etc.)
Installation
Prerequisites
Node.js 18+
A DeepSeek API key (get one at https://platform.deepseek.com)
Manual Installation
If you prefer to install manually:
npm install -g @arikusi/deepseek-mcp-serverFrom Source
Clone the repository
git clone https://github.com/arikusi/deepseek-mcp-server.git
cd deepseek-mcp-serverInstall dependencies
npm installBuild the project
npm run buildUsage
Once configured, your MCP client will have access to deepseek_chat and deepseek_sessions tools, plus 3 MCP resources.
Example prompts:
"Use DeepSeek to explain quantum computing"
"Ask DeepSeek Reasoner to solve: If I have 10 apples and buy 5 more..."Your MCP client will automatically call the deepseek_chat tool.
Manual Configuration (Advanced)
If your MCP client doesn't support the add command, manually add to your config file:
{
"mcpServers": {
"deepseek": {
"command": "npx",
"args": ["@arikusi/deepseek-mcp-server"],
"env": {
"DEEPSEEK_API_KEY": "your-api-key-here"
}
}
}
}Config file locations:
Claude Code:
~/.claude.json(add toprojects["your-project-path"].mcpServerssection)Other MCP clients: Check your client's documentation for config file location
Available Tools
deepseek_chat
Chat with DeepSeek AI models with automatic cost tracking and function calling support.
Parameters:
messages(required): Array of conversation messagesrole: "system" | "user" | "assistant" | "tool"content: Message texttool_call_id(optional): Required for tool role messages
model(optional): "deepseek-chat" (default) or "deepseek-reasoner"temperature(optional): 0-2, controls randomness (default: 1.0). Ignored when thinking mode is enabled.max_tokens(optional): Maximum tokens to generate (deepseek-chat: max 8192, deepseek-reasoner: max 65536)stream(optional): Enable streaming mode (default: false)tools(optional): Array of tool definitions for function calling (max 128)tool_choice(optional): "auto" | "none" | "required" |{type: "function", function: {name: "..."}}thinking(optional): Enable thinking mode{type: "enabled"}json_mode(optional): Enable JSON output mode (supported by both models)session_id(optional): Session ID for multi-turn conversations. Previous context is automatically prepended.
Response includes:
Content with formatting
Function call results (if tools were used)
Request information (tokens, model, cost in USD)
Structured data with
cost_usdandtool_callsfields
Example:
{
"messages": [
{
"role": "user",
"content": "Explain the theory of relativity in simple terms"
}
],
"model": "deepseek-chat",
"temperature": 0.7,
"max_tokens": 1000
}DeepSeek Reasoner Example:
{
"messages": [
{
"role": "user",
"content": "If I have 10 apples and eat 3, then buy 5 more, how many do I have?"
}
],
"model": "deepseek-reasoner"
}The reasoner model will show its thinking process in <thinking> tags followed by the final answer.
Function Calling Example:
{
"messages": [
{
"role": "user",
"content": "What's the weather in Istanbul?"
}
],
"tools": [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get current weather for a location",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City name"
}
},
"required": ["location"]
}
}
}
],
"tool_choice": "auto"
}When the model decides to call a function, the response includes tool_calls with the function name and arguments. You can then send the result back using a tool role message with the matching tool_call_id.
Thinking Mode Example:
{
"messages": [
{
"role": "user",
"content": "Analyze the time complexity of quicksort"
}
],
"model": "deepseek-chat",
"thinking": { "type": "enabled" }
}When thinking mode is enabled, temperature, top_p, frequency_penalty, and presence_penalty are automatically ignored.
JSON Output Mode Example:
{
"messages": [
{
"role": "user",
"content": "Return a json object with name, age, and city fields for a sample user"
}
],
"model": "deepseek-chat",
"json_mode": true
}JSON mode ensures the model outputs valid JSON. Include the word "json" in your prompt for best results. Supported by both deepseek-chat and deepseek-reasoner.
Multi-Turn Session Example:
{
"messages": [
{
"role": "user",
"content": "What is the capital of France?"
}
],
"session_id": "my-session-1"
}Use the same session_id across requests to maintain conversation context. Messages are stored in memory and prepended automatically. In HTTP transport each connected MCP session has its own isolated session store — a session_id created by one HTTP client is not visible to another (see HTTP Transport below).
deepseek_sessions
Manage conversation sessions.
Parameters:
action(required): "list" | "clear" | "delete"session_id(optional): Required when action is "delete"
Examples:
{"action": "list"}
{"action": "delete", "session_id": "my-session-1"}
{"action": "clear"}Available Resources
MCP Resources provide read-only data about the server:
Resource URI | Description |
| Available models with capabilities, context limits, and pricing |
| Current server configuration (API key masked) |
| Real-time usage statistics (requests, tokens, costs, sessions) |
Model Fallback & Circuit Breaker
When a model fails with a retryable error (429, 503, timeout), the server automatically falls back to the other model:
deepseek-chatfails → triesdeepseek-reasonerdeepseek-reasonerfails → triesdeepseek-chat
The circuit breaker protects against cascading failures:
After
CIRCUIT_BREAKER_THRESHOLDconsecutive failures (default: 5), the circuit opens (fast-fail mode)After
CIRCUIT_BREAKER_RESET_TIMEOUTms (default: 30000), it enters half-open state and sends a probe requestIf the probe succeeds, the circuit closes and normal operation resumes
Fallback can be disabled with FALLBACK_ENABLED=false.
Available Prompts
Prompt templates (12 total):
Core Reasoning
debug_with_reasoning: Debug code with step-by-step analysis
code_review_deep: Comprehensive code review (security, performance, quality)
research_synthesis: Research topics and create structured reports
strategic_planning: Create strategic plans with reasoning
explain_like_im_five: Explain complex topics in simple terms
Advanced
mathematical_proof: Prove mathematical statements rigorously
argument_validation: Analyze arguments for logical fallacies
creative_ideation: Generate creative ideas with feasibility analysis
cost_comparison: Compare LLM costs for tasks
pair_programming: Interactive coding with explanations
Function Calling
function_call_debug: Debug function calling issues with tool definitions and messages
create_function_schema: Generate JSON Schema for function calling from natural language
Each prompt is optimized for the DeepSeek Reasoner model to provide detailed reasoning.
Models
Both models run DeepSeek-V3.2 with unified pricing.
deepseek-chat
Best for: General conversations, coding, content generation
Speed: Fast
Context: 128K tokens
Max Output: 8K tokens (default 4K)
Mode: Non-thinking (can enable thinking via parameter)
Features: Thinking mode, JSON mode, function calling, FIM completion
Pricing: $0.028/1M cache hit, $0.28/1M cache miss, $0.42/1M output
deepseek-reasoner
Best for: Complex reasoning, math, logic problems, multi-step tasks
Speed: Slower (shows thinking process)
Context: 128K tokens
Max Output: 64K tokens (default 32K)
Mode: Thinking (always active, chain-of-thought reasoning)
Features: JSON mode, function calling
Output: Both reasoning process and final answer
Pricing: $0.028/1M cache hit, $0.28/1M cache miss, $0.42/1M output
Configuration
The server is configured via environment variables. All settings except DEEPSEEK_API_KEY are optional.
Variable | Default | Description |
| (required) | Your DeepSeek API key |
|
| Custom API endpoint |
|
| Default model for requests |
|
| Show cost info in responses |
|
| Request timeout in milliseconds |
|
| Maximum retry count for failed requests |
|
| Skip startup API connection test |
|
| Maximum message content length (characters) |
|
| Session time-to-live in minutes |
|
| Maximum number of concurrent sessions |
|
| Enable automatic model fallback on errors |
|
| Consecutive failures before circuit opens |
|
| Milliseconds before circuit half-opens |
|
| Max messages per session (sliding window) |
|
| Enable multimodal (image) input support |
|
| Transport mode: |
|
| HTTP server port (when TRANSPORT=http) |
Example with custom config:
claude mcp add -s user deepseek npx @arikusi/deepseek-mcp-server \
-e DEEPSEEK_API_KEY=your-key \
-e SHOW_COST_INFO=false \
-e REQUEST_TIMEOUT=30000Development
Project Structure
deepseek-mcp-server/
├── worker/ # Cloudflare Worker (remote BYOK endpoint)
│ ├── src/index.ts # Worker entry point
│ ├── wrangler.toml # Cloudflare config
│ └── package.json
├── src/
│ ├── index.ts # Entry point, bootstrap
│ ├── server.ts # McpServer factory (auto-version)
│ ├── deepseek-client.ts # DeepSeek API wrapper (circuit breaker + fallback)
│ ├── config.ts # Centralized config with Zod validation
│ ├── cost.ts # Cost calculation and formatting
│ ├── schemas.ts # Zod input validation schemas
│ ├── types.ts # TypeScript types + type guards
│ ├── errors.ts # Custom error classes
│ ├── session.ts # In-memory session store (multi-turn)
│ ├── circuit-breaker.ts # Circuit breaker pattern
│ ├── usage-tracker.ts # Usage statistics tracker
│ ├── transport-http.ts # Streamable HTTP transport (Express)
│ ├── tools/
│ │ ├── deepseek-chat.ts # deepseek_chat tool (sessions + fallback)
│ │ ├── deepseek-sessions.ts # deepseek_sessions tool
│ │ └── index.ts # Tool registration aggregator
│ ├── resources/
│ │ ├── models.ts # deepseek://models resource
│ │ ├── config.ts # deepseek://config resource
│ │ ├── usage.ts # deepseek://usage resource
│ │ └── index.ts # Resource registration aggregator
│ └── prompts/
│ ├── core.ts # 5 core reasoning prompts
│ ├── advanced.ts # 5 advanced prompts
│ ├── function-calling.ts # 2 function calling prompts
│ └── index.ts # Prompt registration aggregator
├── dist/ # Compiled JavaScript
├── llms.txt # AI discoverability index
├── llms-full.txt # Full docs for LLM context
├── vitest.config.ts # Test configuration
├── package.json
├── tsconfig.json
└── README.mdBuilding
npm run buildWatch Mode (for development)
npm run watchTesting
# Run all tests
npm test
# Watch mode
npm run test:watch
# With coverage report
npm run test:coverageTesting Locally
# Set API key
export DEEPSEEK_API_KEY="your-key"
# Run the server
npm startThe server will start and wait for MCP client connections via stdio.
Remote Endpoint (Hosted)
A hosted BYOK (Bring Your Own Key) endpoint is available at:
https://deepseek-mcp.tahirl.com/mcpSend your DeepSeek API key as Authorization: Bearer <key>. No server-side API key stored — your key is used directly per request. Powered by Cloudflare Workers (global edge, zero cold start).
Note: The
deepseek-reasonermodel may take over 30 seconds for complex queries. Some MCP clients (e.g. Claude Code) have built-in tool call timeouts that may interrupt long-running requests. For complex tasks,deepseek-chatis recommended.
# Test health
curl https://deepseek-mcp.tahirl.com/health
# Test MCP (requires auth)
curl -X POST https://deepseek-mcp.tahirl.com/mcp \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_KEY" \
-d '{"jsonrpc":"2.0","method":"initialize","params":{"capabilities":{}},"id":1}'HTTP Transport (Self-Hosted)
Run your own HTTP endpoint:
TRANSPORT=http HTTP_PORT=3000 DEEPSEEK_API_KEY=your-key node dist/index.jsTest the health endpoint:
curl http://localhost:3000/healthThe MCP endpoint is available at POST /mcp (Streamable HTTP protocol).
Session isolation (1.7.0+): In HTTP transport each connected MCP session
gets its own McpServer instance and its own SessionStore. Conversation
history, session listings, and deletions are scoped to the MCP session that
created them — one client cannot read, enumerate, or wipe another client's
sessions. STDIO transport is single-tenant by nature and unaffected.
Docker
# Build
docker build -t deepseek-mcp-server .
# Run
docker run -d -p 3000:3000 -e DEEPSEEK_API_KEY=your-key deepseek-mcp-server
# Or use docker-compose
DEEPSEEK_API_KEY=your-key docker compose up -dThe Docker image defaults to HTTP transport on port 3000 with a built-in health check.
Troubleshooting
"DEEPSEEK_API_KEY environment variable is not set"
Option 1: Use the correct installation command
# Make sure to include -e flag with your API key
claude mcp add deepseek npx @arikusi/deepseek-mcp-server -e DEEPSEEK_API_KEY=your-key-hereOption 2: Manually edit the config file
If you already installed without the API key, edit your config file:
For Claude Code: Open
~/.claude.json(Windows:C:\Users\USERNAME\.claude.json)Find the
"mcpServers"section under your project pathAdd the
envfield with your API key:
"deepseek": {
"type": "stdio",
"command": "npx",
"args": ["@arikusi/deepseek-mcp-server"],
"env": {
"DEEPSEEK_API_KEY": "your-api-key-here"
}
}Save and restart Claude Code
"Failed to connect to DeepSeek API"
Check your API key is valid
Verify you have internet connection
Check DeepSeek API status at https://status.deepseek.com
Server not appearing in your MCP client
Verify the path to
dist/index.jsis correctMake sure you ran
npm run buildCheck your MCP client's logs for errors
Restart your MCP client completely
Permission Denied on macOS/Linux
Make the file executable:
chmod +x dist/index.jsPublishing to npm
To share this MCP server with others:
Run
npm loginRun
npm publish --access public
Users can then install with:
npm install -g @arikusi/deepseek-mcp-serverContributing
Contributions are welcome! Please read our Contributing Guidelines before submitting PRs.
Reporting Issues
Found a bug or have a feature request? Please open an issue using our templates.
Development
# Clone the repo
git clone https://github.com/arikusi/deepseek-mcp-server.git
cd deepseek-mcp-server
# Install dependencies
npm install
# Build in watch mode
npm run watch
# Run tests
npm test
# Lint
npm run lintChangelog
See CHANGELOG.md for version history and updates.
License
MIT License - see LICENSE file for details
Support
Resources
DeepSeek Platform - Get your API key
Model Context Protocol - MCP specification
DeepSeek API Documentation - API reference
Acknowledgments
Built with Model Context Protocol SDK
Uses OpenAI SDK for API compatibility
Created for the MCP community
Made by @arikusi
This is an unofficial community project and is not affiliated with DeepSeek.
Available Tools
3 toolsdeepseek_chatDeepSeek Chat CompletionA
Chat with DeepSeek V4 models. deepseek-v4-flash (fast, economical) and deepseek-v4-pro (most capable), both 1M context with optional chain-of-thought thinking mode. deepseek-chat and deepseek-reasoner are deprecated aliases, still accepted for backward compatibility (resolve to v4-flash) but slated for removal; prefer the v4 names. Features: multi-turn sessions (session_id), function calling (tools parameter), thinking mode, JSON output mode, multimodal input (when enabled), automatic cost tracking, and model fallback with circuit breaker resilience.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use. deepseek-v4-flash (default, fast/economical) or deepseek-v4-pro (most capable), both 1M context, up to 384K output. Non-thinking by default for speed; pass thinking:{type:"enabled"} to reason. Deprecated aliases (still accepted, prefer v4 names): deepseek-chat -> v4-flash non-thinking, deepseek-reasoner -> v4-flash thinking. | deepseek-v4-flash |
| tools | No | Array of tool definitions for function calling. Each tool has type "function" and a function object with name, description, and parameters (JSON Schema). | |
| stream | No | Enable streaming mode. Returns full response after streaming completes. | |
| messages | Yes | Array of conversation messages. Each message has role (system/user/assistant/tool) and content (string or array of content parts for multimodal). Tool messages require tool_call_id. | |
| thinking | No | Toggle chain-of-thought thinking mode. Use {type: "enabled"} to reason, {type: "disabled"} for a fast direct answer (the default here). When enabled, temperature/top_p are ignored. | |
| json_mode | No | Enable JSON output mode. The model will output valid JSON. Include the word "json" in your prompt for best results. Supported by both models. | |
| max_tokens | No | Maximum tokens to generate. V4 models support up to 384000 output tokens. | |
| session_id | No | Session ID for multi-turn conversations. When provided, previous messages from this session are prepended to the current messages. If the session does not exist, it is created automatically. Omit for stateless single-turn requests. | |
| temperature | No | Sampling temperature (0-2). Higher = more random. Default: 1.0. Ignored when thinking mode is enabled. | |
| tool_choice | No | Controls which tool the model calls. "auto" (default), "none", "required", or {type:"function",function:{name:"..."}} | |
| response_schema | No | JSON Schema to validate the model output against. Implies JSON output mode. The server validates the parsed result and, on failure, issues up to RESPONSE_SCHEMA_MAX_RETRIES repair retries (feeding the validation error back). The returned content is the first schema-valid object, or the last attempt with schema.valid=false and schema.error set. | |
| reasoning_effort | No | Reasoning effort while thinking mode is active: "high" (default) or "max". Only applies when thinking is enabled. |
Output Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| usage | Yes | |
| schema | No | |
| content | Yes | |
| request | Yes | |
| cost_usd | No | |
| fallback | No | |
| effective | No | |
| session_id | No | |
| tool_calls | No | |
| routed_from | No | |
| finish_reason | Yes | |
| json_parse_error | No | |
| reasoning_content | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add useful behavioral context: deprecated aliases slated for removal, model fallback with circuit breaker resilience, automatic cost tracking, and optional thinking mode. It does not cover every runtime behavior, but the traits disclosed go beyond a bare feature list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose, then efficiently lists model variants and capabilities. It is dense but every sentence contributes useful differentiating information, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity tool with 12 parameters, nested objects, and an output schema, the description gives a strong high-level map: model choice, context length, aliases, and the major feature areas. The schema fills in the rest, so the agent is not left without critical calling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 12 parameters. The description restates some parameter concepts (tools, thinking, session_id, json_mode) but adds no syntax or usage detail beyond what the input schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Chat with DeepSeek V4 models," which clearly identifies this as a chat-completion tool. The feature list (multi-turn sessions, function calling, thinking mode, JSON mode) further clarifies scope, though it does not explicitly contrast with deepseek_fim or deepseek_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage from the verb "Chat" and names relevant capabilities like session_id and tools, giving an agent a reasonable sense of when to call it. However, it provides no explicit guidance about when to prefer deepseek_fim or deepseek_sessions, nor any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deepseek_fimDeepSeek FIM CompletionA
Fill-in-the-Middle (FIM) completion with DeepSeek V4. Provide a prompt (prefix) and an optional suffix; the model completes the text in between. Ideal for code completion and content infilling. Runs in non-thinking mode on the Beta endpoint; output is capped at 4K tokens. The deprecated aliases deepseek-chat and deepseek-reasoner are still accepted and resolve to deepseek-v4-flash (FIM has no thinking mode). Includes automatic cost tracking and model fallback with circuit breaker resilience.
| Name | Required | Description | Default |
|---|---|---|---|
| stop | No | Optional stop sequence(s). Generation stops when any is produced. A single string or an array of up to 16 strings. | |
| model | No | Model to use. deepseek-v4-flash (default, fast/economical) or deepseek-v4-pro (most capable). Deprecated aliases deepseek-chat / deepseek-reasoner are still accepted and resolve to v4-flash. FIM is always non-thinking. | deepseek-v4-flash |
| prompt | Yes | The prefix text that comes before the content to generate. Required. For code completion, this is the code up to the cursor. | |
| suffix | No | Optional suffix text that comes after the content to generate. The model fills the gap between prompt and suffix. | |
| max_tokens | No | Maximum tokens to generate. FIM completions are capped at 4096 tokens by the API. | |
| temperature | No | Sampling temperature (0-2). Higher = more random. Default: 1.0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| model | Yes | |
| usage | Yes | |
| cost_usd | No | |
| routed_from | No | |
| finish_reason | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does substantial work: it discloses the non-thinking mode, Beta endpoint, the 4K output cap, deprecated alias resolution to deepseek-v4-flash, and automatic cost tracking with fallback/circuit-breaker resilience. It only omits operational details like rate limits and error behavior, which are not typically required for invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, with every sentence carving a distinct role: mechanism, use case, endpoint/mode/cap, then alias and resilience behavior. No filler words, and the critical scoping information comes first so an agent scanning the description immediately knows what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (return values need no explanation), only one required parameter, and 100% schema coverage, the description is nearly complete: it covers behavior (non-thinking, Beta, 4K cap), alias semantics, and resilience. The omission of rate limits and explicit sibling routing is minor for a single-call completion tool, but with no annotations the description could have gone slightly further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents all 6 parameters, including the model enum and the 4096 cap. The description adds modest extra meaning by framing prompt+suffix as an infill gap ('the model completes the text in between') and by restating alias resolution, but most of its param-related content duplicates the model and max_tokens schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific mechanism and resource: 'Fill-in-the-Middle (FIM) completion with DeepSeek V4', and explains the exact contract — 'Provide a prompt (prefix) and an optional suffix; the model completes the text in between.' This clearly separates it from the deepseek_chat and deepseek_sessions sibings, since FIM fill-in-the-midddle semantics are structurally different from conversation or session management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear use-case context — 'Ideal for code completion and content infilling' — and notes FIM 'has no thinking mode', which implicitly discourages use for reasoning-heavy prompts. However, it never names the sibling tools or explicitly states when to choose deepseek_chat instead (e.g., multi-turn conversation, general Q&A), so the selection logic is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deepseek_sessionsDeepSeek Session ManagementA
Manage multi-turn conversation sessions. List active sessions, delete a specific session, or clear all sessions. Sessions store conversation history for use with the session_id parameter in deepseek_chat.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. "list": show all active sessions, "clear": remove all sessions, "delete": remove a specific session (requires session_id) | |
| session_id | No | Session ID to delete (required when action is "delete") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description alone must convey behavioral traits. It lists actions but does not mention impacts like data loss on deletion, authentication needs, or rate limits. Basic transparency but insufficient for a management tool with destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. Could be slightly more structured but is efficient and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description does not specify what the 'list' action returns (e.g., session IDs). The tool is fairly complete given the schema and context signals, but missing output details and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds useful context about sessions used with deepseek_chat, but adds no new details beyond what the schema already provides for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages multi-turn conversation sessions with specific actions (list, delete, clear), and distinguishes from the sibling tool deepseek_chat by noting sessions are used with that tool's session_id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that sessions store history used by deepseek_chat, providing context for when to use this management tool. However, it lacks explicit when-not-to-use guidance or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v2.3.0- Changed
deepseek_chat8 fields changed- changed
Input schema / properties / model / descriptionPrevious value: -"Model to use. deepseek-v4-flash (default, fast/economical) or deepseek-v4-pro (most capable), both 1M context, up to 384K output. Non-thinking by default for speed; pass thinking:{type:\"enabled\"} to reason. Aliases: deepseek-chat -> v4-flash non-thinking, deepseek-reasoner -> v4-flash thinking."New value: +"Model to use. deepseek-v4-flash (default, fast/economical) or deepseek-v4-pro (most capable), both 1M context, up to 384K output. Non-thinking by default for speed; pass thinking:{type:\"enabled\"} to reason. Deprecated aliases (still accepted, prefer v4 names): deepseek-chat -> v4-flash non-thinking, deepseek-reasoner -> v4-flash thinking." - added
Input schema / properties / response_schemaAdded value: +{ + "additionalProperties": {}, + "description": "JSON Schema to validate the model output against. Implies JSON output mode. The server validates the parsed result and, on failure, issues up to RESPONSE_SCHEMA_MAX_RETRIES repair retries (feeding the validation error back). The returned content is the first schema-valid object, or the last attempt with schema.valid=false and schema.error set.", + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Output schema / properties / effectiveAdded value: +{ + "additionalProperties": false, + "properties": { + "model": { + "type": "string" + }, + "temperature": { + "type": "number" + }, + "thinking": { + "type": "boolean" + } + }, + "required": [ + "model", + "thinking" + ], + "type": "object" +} - added
Output schema / properties / fallbackAdded value: +{ + "additionalProperties": false, + "properties": { + "fallbackModel": { + "type": "string" + }, + "originalModel": { + "type": "string" + }, + "reason": { + "type": "string" + } + }, + "required": [ + "originalModel", + "fallbackModel", + "reason" + ], + "type": "object" +} - added
Output schema / properties / json_parse_errorAdded value: +{ + "type": "string" +} - added
Output schema / properties / requestAdded value: +{ + "additionalProperties": false, + "properties": { + "cache_hit_tokens": { + "type": "number" + }, + "cache_miss_tokens": { + "type": "number" + }, + "completion_tokens": { + "type": "number" + }, + "cost_usd": { + "type": "number" + }, + "fallback_used": { + "type": "boolean" + }, + "finish_reason": { + "type": "string" + }, + "model": { + "type": "string" + }, + "prompt_tokens": { + "type": "number" + }, + "temperature": { + "type": "number" + }, + "thinking": { + "type": "boolean" + }, + "total_tokens": { + "type": "number" + }, + "wire_model": { + "type": "string" + } + }, + "required": [ + "model", + "wire_model", + "thinking", + "fallback_used", + "finish_reason", + "prompt_tokens", + "completion_tokens", + "total_tokens", + "cache_hit_tokens", + "cache_miss_tokens", + "cost_usd" + ], + "type": "object" +} - added
Output schema / properties / schemaAdded value: +{ + "additionalProperties": false, + "properties": { + "attempts": { + "type": "number" + }, + "error": { + "type": "string" + }, + "valid": { + "type": "boolean" + } + }, + "required": [ + "valid", + "attempts" + ], + "type": "object" +} - changed
Output schema / requiredPrevious value: -[ - "content", - "model", - "usage", - "finish_reason" -]New value: +[ + "content", + "model", + "usage", + "request", + "finish_reason" +]
- Changed
deepseek_fim1 field changed- changed
Input schema / properties / model / descriptionPrevious value: -"Model to use. deepseek-v4-flash (default, fast/economical) or deepseek-v4-pro (most capable). Aliases deepseek-chat / deepseek-reasoner resolve to v4-flash. FIM is always non-thinking."New value: +"Model to use. deepseek-v4-flash (default, fast/economical) or deepseek-v4-pro (most capable). Deprecated aliases deepseek-chat / deepseek-reasoner are still accepted and resolve to v4-flash. FIM is always non-thinking."
1 tool update
v2.1.0- Added
deepseek_fim
1 tool update
v2.0.0- Changed
deepseek_chat9 fields changed- changed
Input schema / properties / max_tokens / descriptionPrevious value: -"Maximum tokens to generate. deepseek-chat: max 8192, deepseek-reasoner: max 65536"New value: +"Maximum tokens to generate. V4 models support up to 384000 output tokens." - changed
Input schema / properties / max_tokens / maximumPrevious value: -65536New value: +384000 - changed
Input schema / properties / model / defaultPrevious value: -"deepseek-chat"New value: +"deepseek-v4-flash" - changed
Input schema / properties / model / descriptionPrevious value: -"Model to use. Both run DeepSeek V3.2 (128K context). deepseek-chat: non-thinking mode (max 8K output), deepseek-reasoner: thinking mode (max 64K output)"New value: +"Model to use. deepseek-v4-flash (default, fast/economical) or deepseek-v4-pro (most capable), both 1M context, up to 384K output. Non-thinking by default for speed; pass thinking:{type:\"enabled\"} to reason. Aliases: deepseek-chat -> v4-flash non-thinking, deepseek-reasoner -> v4-flash thinking." - changed
Input schema / properties / model / enumPrevious value: -[ - "deepseek-chat", - "deepseek-reasoner" -]New value: +[ + "deepseek-v4-flash", + "deepseek-v4-pro", + "deepseek-chat", + "deepseek-reasoner" +] - added
Input schema / properties / reasoning_effortAdded value: +{ + "description": "Reasoning effort while thinking mode is active: \"high\" (default) or \"max\". Only applies when thinking is enabled.", + "enum": [ + "high", + "max" + ], + "type": "string" +} - changed
Input schema / properties / thinking / descriptionPrevious value: -"Enable thinking mode. When enabled, temperature/top_p/frequency_penalty/presence_penalty are automatically ignored. Use {type: \"enabled\"} to activate."New value: +"Toggle chain-of-thought thinking mode. Use {type: \"enabled\"} to reason, {type: \"disabled\"} for a fast direct answer (the default here). When enabled, temperature/top_p are ignored." - added
Output schema / properties / cost_usdAdded value: +{ + "type": "number" +} - added
Output schema / properties / routed_fromAdded value: +{ + "type": "string" +}
2 tool updates
v1.5.0- First observed
deepseek_chat - First observed
deepseek_sessions
TDQS
Scored across 3 tools
Each tool targets a clearly distinct capability: chat completion, fill-in-the-middle completion, and session management. There is no overlap in purpose or behavior, so an agent can reliably select the right tool.
All tools share the deepseek_ prefix and use lowercase snake_case, which is predictable. However, the suffix varies in part-of-speech (chat is a verb, fim is an acronym, sessions is a noun), so it is not a strict verb_noun pattern.
Three tools is a well-scoped surface for a model access server: one for interactive chat, one for code infilling, and one for session lifecycle management. Each tool earns its place without redundancy or bloat.
The core model capabilities (chat and FIM) plus session lifecycle management cover the main workflows. Minor gaps exist, such as no explicit session creation tool (sessions are implicitly created via chat) and no way to inspect a session's message history directly.
Maintenance
Related MCP Connectors
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
MCP server for building and testing AI agents with multi-model experimentation and insights.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Related MCP Servers
- AlicenseDqualityDmaintenanceAllows seamless integration of DeepSeek's language models with MCP-compatible applications like Claude Desktop, supporting features such as model selection, temperature control, and multi-turn conversations with automatic model fallback.2518 npm2MIT
- FlicenseNot gradedqualityDmaintenanceA Node.js + TypeScript MCP server that proxies to DeepSeek's Chat, Image, and TTS APIs for conversation, image generation, and text-to-speech.-
- AlicenseAqualityDmaintenanceMCP server that wraps DeepSeek's AI capabilities into standard MCP tools, supporting three authentication modes including free web-based usage without API keys.6518 npm1MIT
- AlicenseNot gradedqualityDmaintenanceMulti-model MCP server enabling code generation, visual analysis, and complex reasoning via Qwen3 models.MIT