A
licenseA
qualityD
maintenanceEnables seamless integration between Ollama's local LLM models and MCP-compatible applications, supporting model management and chat interactions.
13
758 npm
170
AGPL 3.0
DeepSeek MCP Server
The DeepSeek MCP Server provides an interface to DeepSeek's language models, enabling:
Natural Language Interactions: Query models, settings, and configuration options
Model Management: Switch between
deepseek-reasoner(default) anddeepseek-chatmodels manually or via automatic fallbackConfigurable Parameters: Adjust temperature, max tokens, top-p, presence/frequency penalties
Multi-turn Conversations: Maintain context and message history across exchanges
MCP Integration: Work with MCP-compatible applications like Claude Desktop
Testing & Debugging: Use MCP Inspector to test completions and monitor performance
Proxy Functionality: Maintain anonymity by exposing only a proxy to external clients
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@DeepSeek MCP Serverstart a conversation with deepseek-chat and set temperature to 0.7 for creative responses"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
DeepSeek MCP Server
An MCP server for DeepSeek's current V4.1 Flash API: text and visual chat, the Responses API, FIM completion, Files API lifecycle operations, model discovery, balance checks, and bounded in-memory conversations.
Version 1.0.1 uses the stable MCP TypeScript SDK v2 and serves both the 2026-07-28 protocol and stateless legacy clients.
What's current
As of September 10, 2026:
The canonical fast model is
deepseek-flash, currently DeepSeek V4.1 Flash.deepseek-v4-flashanddeepseek-v4-flash-vision-expare temporary aliases fordeepseek-flash.DeepSeek announced that
deepseek-v4-prowill begin serving V4.1 Flash on September 14 until V4.1 Pro is released.V4.1 Flash accepts visual input through Chat Completions and Responses.
The Files API supports upload, list, retrieve, and delete for reusable image inputs.
DeepSeek documents a 1M-token context window and up to 384K output tokens for
deepseek-flash.
“Multimodal” here means image understanding. This server does not generate images, video, or audio.
Related MCP server: DeepSeek MCP Server
Tools
The server exposes eleven tools:
chat_completion: text or visual Chat Completions, thinking controls, function tools, JSON output, streaming aggregation, and optionalconversation_idmemory.create_response: stateless Responses API calls with text/images, reasoning controls, function/custom tools, web search, structured output, and semantic streaming aggregation.completion: FIM completion through/beta/completions.list_models: live model discovery.get_user_balance: account availability and balances.upload_file: upload base64 JPEG, PNG, GIF, or WebP data and receive a reusable DeepSeekfile_id.list_files: list uploaded files with cursor, order, and purpose filters.retrieve_file: retrieve metadata for onefile_id.delete_file: delete one uploaded file.reset_conversation: clear one local in-memory conversation.list_conversations: list local in-memory conversation IDs.
Every tool declares an MCP output schema and behavior annotations. Full
provider payloads remain opt-in through include_raw_response=true.
Install
Node.js 20 or newer is required.
Run directly over stdio:
DEEPSEEK_API_KEY="REPLACE_WITH_DEEPSEEK_KEY" npx -y deepseek-mcp-server@1Codex CLI:
codex mcp add deepseek --env DEEPSEEK_API_KEY="REPLACE_WITH_DEEPSEEK_KEY" -- npx -y deepseek-mcp-server@1Claude Code:
claude mcp add deepseek --env DEEPSEEK_API_KEY="REPLACE_WITH_DEEPSEEK_KEY" -- npx -y deepseek-mcp-server@1Example MCP client configuration:
{
"mcpServers": {
"deepseek": {
"command": "npx",
"args": ["-y", "deepseek-mcp-server@1"],
"env": {
"DEEPSEEK_API_KEY": "REPLACE_WITH_DEEPSEEK_KEY"
}
}
}
}Visual input
chat_completion accepts image URLs:
{
"message": [
{ "type": "text", "text": "Describe this image." },
{
"type": "image_url",
"image_url": {
"url": "https://example.com/photo.png",
"detail": "high"
}
}
]
}It also accepts a supported base64 data URL without first uploading it:
{
"message": [
{ "type": "text", "text": "What is shown here?" },
{
"type": "file",
"file_data": "data:image/png;base64,iVBORw0KGgo...",
"filename": "image.png"
}
]
}For reuse, call upload_file, then pass its returned ID:
{
"filename": "diagram.png",
"file_data": "iVBORw0KGgo...",
"expires_after_seconds": 86400
}{
"message": [
{ "type": "text", "text": "Explain this diagram." },
{ "type": "file", "file_id": "file-api-..." }
]
}The same uploaded file can be used with create_response:
{
"input": [
{
"role": "user",
"content": [
{ "type": "input_text", "text": "Read the image." },
{ "type": "input_image", "file_id": "file-api-..." }
]
}
]
}Supported image formats are JPEG, PNG, GIF, and WebP. Detail may be low,
high, original, or auto.
Upload safety boundary
upload_file accepts raw base64 or a supported image data URL. It deliberately
does not accept local file paths and does not fetch arbitrary URLs on the
server. Decoded uploads are limited to 64 MiB, and the bytes are
signature-checked before upload. Uploaded data is stored by DeepSeek under your
account; use an expiry or delete_file when it should not persist. Expiry must
be between 3,600 and 2,592,000 seconds.
Streamable HTTP
Run a local HTTP endpoint:
DEEPSEEK_API_KEY="REPLACE_WITH_DEEPSEEK_KEY" \
MCP_TRANSPORT=streamable-http \
MCP_HTTP_HOST=127.0.0.1 \
MCP_HTTP_PORT=3001 \
npx -y deepseek-mcp-server@1The endpoint defaults to http://127.0.0.1:3001/mcp.
For browser clients, set an exact comma-separated origin allowlist:
MCP_HTTP_ALLOWED_ORIGINS=https://app.example.com,http://localhost:3000Requests that include an Origin header are rejected with 403 unless the
origin is allowlisted. Native clients that omit Origin are unaffected.
Hosted endpoint
A separately deployed endpoint is available at
https://deepseek-mcp.ragweld.com/mcp using
Authorization: Bearer <token>. The hosted deployment has its own release
cycle and may lag the npm/GitHub release; inspect tools/list before relying
on a newly added tool.
Environment
Required:
DEEPSEEK_API_KEY=your-api-keyOptional:
DEEPSEEK_BASE_URL=https://api.deepseek.com
DEEPSEEK_REQUEST_TIMEOUT_MS=120000
DEEPSEEK_DEFAULT_MODEL=deepseek-flash
MCP_TRANSPORT=stdio
MCP_HTTP_HOST=127.0.0.1
MCP_HTTP_PORT=3001
MCP_HTTP_PATH=/mcp
MCP_HTTP_ALLOWED_ORIGINS=https://app.example.com,http://localhost:3000
CONVERSATION_MAX_MESSAGES=200CONVERSATION_MAX_MESSAGES bounds the total messages retained in the
process-local conversation store. Restarting the process clears this store.
MCP compatibility
Built on
@modelcontextprotocol/server,@modelcontextprotocol/node, and@modelcontextprotocol/client2.0.Streamable HTTP negotiates MCP 2026-07-28 and falls back to stateless 2025-era handling for older clients.
Stdio chooses the protocol era from the opening exchange and pins one server instance for that connection.
Static discovery/list results carry one-hour public cache hints; dynamic resource lists, runtime data, live account data, and conversations remain private and short-lived or uncached.
Explicit
conversation_idmemory is application state and works independently of transport session state.
Migrating from 0.6.0
The default model changed from
deepseek-v4-flashtodeepseek-flash.The MCP SDK moved from the monolithic v1 package to the split v2 packages.
MCP_HTTP_STATEFUL_SESSIONwas removed. HTTP protocol handling is now per-request/stateless; useconversation_idfor retained chat context.Four Files API tools and visual inputs were added.
Existing tool names and
include_raw_responsebehavior remain compatible.
Development and verification
npm ci
npm run build
npm test
npm pack --dry-runCredentialed smoke tests:
DEEPSEEK_API_KEY="REPLACE_WITH_DEEPSEEK_KEY" npm run test:live
DEEPSEEK_MCP_AUTH_TOKEN="REPLACE_WITH_TOKEN" npm run test:remoteThe live smoke covers model listing, balance, text chat, thinking streaming, Responses, FIM, visual input, and a Files upload/retrieve/list/delete lifecycle with cleanup.
Registry identity
MCP Registry:
io.github.DMontgomery40/deepseeknpm:
deepseek-mcp-server@1.0.1OCI:
docker.io/dmontgomery40/deepseek-mcp-server:0.5.0is the last published image and does not contain the 1.0.1 feature set.
Official references
License
MIT
Available Tools
11 toolschat_completionA
Primary DeepSeek V4.1 chat tool for text, images, and multi-turn generation. Defaults to deepseek-flash. Provide either message (a text string or text/image/file content parts) or messages (full chat history); if both are provided, messages is used. Images may use an HTTP(S) URL, supported base64 data URL, or Files API file_id. Thinking is enabled by default; use reasoning_effort for current effort controls. Use conversation_id for explicit in-memory context. Set include_raw_response=true only for provider-payload debugging.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| stop | No | ||
| model | No | deepseek-flash | |
| tools | No | ||
| top_p | No | ||
| stream | No | ||
| message | No | ||
| user_id | No | ||
| logprobs | No | ||
| messages | No | ||
| thinking | No | ||
| extra_body | No | ||
| max_tokens | No | ||
| temperature | No | ||
| tool_choice | No | ||
| top_logprobs | No | ||
| stream_options | No | ||
| conversation_id | No | ||
| response_format | No | ||
| presence_penalty | No | ||
| reasoning_effort | No | ||
| frequency_penalty | No | ||
| clear_conversation | No | ||
| include_raw_response | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| model | No | |
| usage | No | |
| status | No | |
| message | No | |
| retryable | No | |
| error_type | No | |
| suggestion | No | |
| tool_calls | No | |
| raw_response | No | |
| finish_reason | No | |
| response_text | No | |
| conversation_id | No | |
| reasoning_content | No | |
| stream_chunk_count | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly=false, openWorld=true), and the description adds non-obvious behavior beyond them: default model, thinking enabled by default, how reasoning_effort controls it, and that conversation_id maintains in-memory state. It does not cover streaming behavior or side effects of clear_conversation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five dense sentences, no filler, with the core capability and input-routing rule front-loaded. Slightly cramped since it compresses many parameter caveats into a single block, but nothing is wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 23-parameter, open-world generative tool with an output schema, the description covers routing, defaults, state, and the two primary input modes, so return values need not be described. Gaps remain around streaming and clear_conversation semantics, but the essential picture is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% across 23 params, so the description must compensate, and it does explain the highest-stakes ones: message/messages mutual exclusivity, accepted image URL forms, file_id usage, model default, reasoning_effort, and include_raw_response. The remaining ~16 parameters (temperature, tools, tool_choice, stream, clear_conversation, penalties, response_format, etc.) are left entirely to the bare schema, so it only partially fills a large gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('chat tool for text, images, and multi-turn generation') and names the model family and default. It does not, however, differentiate itself from siblings like `completion` or `create_response`, so an agent still has to infer why 'primary' means this one should be preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear conditional rules for its own parameters (message vs messages precedence, when to use conversation_id, when to set include_raw_response), which is genuine usage guidance. But it never says when to pick this tool over `completion`/`create_response`, which is the more consequential routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
completionA
DeepSeek FIM completion tool for prompt/suffix fill-in-the-middle workflows. Defaults to deepseek-flash in non-thinking mode. Use this when you need raw completion text instead of chat message formatting. Set include_raw_response=true only when you need the full provider payload for debugging.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| echo | No | ||
| stop | No | ||
| model | No | deepseek-flash | |
| top_p | No | ||
| prompt | Yes | ||
| stream | No | ||
| suffix | No | ||
| logprobs | No | ||
| extra_body | No | ||
| max_tokens | No | ||
| temperature | No | ||
| presence_penalty | No | ||
| frequency_penalty | No | ||
| include_raw_response | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| text | No | |
| model | No | |
| usage | No | |
| status | No | |
| message | No | |
| retryable | No | |
| error_type | No | |
| suggestion | No | |
| raw_response | No | |
| finish_reason | No | |
| stream_chunk_count | No |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so the description needn't restate them. It adds useful behavior context: the default model is deepseek-flash in non-thinking mode, and include_raw_response is a debugging-only switch that expands the payload. It says nothing about cost, rate limits, or auth, so it adds value but is not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what the tool is and the differentiator, then the usage condition, then the debugging caveat. No filler, though the guidance sentence could be grouped more crisply.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. The remaining hole is the 14 undocumented parameters, plus no mention of suffix/prompt interaction semantics that are the point of FIM. Adequate but with a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 14 parameters, so the description must carry the semantic load. It only clarifies two of them (model default, include_raw_response) and leaves temperature/top_p/stop/suffix/logprobs/echo/stream/extra_body/etc. entirely undocumented in both places. This is a significant gap for a 14-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ('FIM completion tool for prompt/suffix fill-in-the-middle') and explicitly contrasts with the sibling chat path ('raw completion text instead of chat message formatting'). An agent can distinguish this from chat_completion/create_response without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear selection condition: use this when you want raw completion text rather than chat-formatted messages, which implicitly routes agents away from chat_completion. It also scopes include_raw_response=true to debugging only. No explicit when-not or prerequisite conditions are stated, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_responseA
Create a stateless DeepSeek V4.1 response using the OpenAI-compatible Responses API. Defaults to deepseek-flash and accepts text, image URLs, base64 images, and Files API file_id inputs. Use reasoning.effort for thinking control, tools for function or server-side web-search tools, and stream=true for semantic SSE aggregation. Send full input history for multi-turn work. Set include_raw_response=true only for provider-payload debugging.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| user | No | ||
| input | No | ||
| model | No | ||
| tools | No | ||
| top_p | No | ||
| stream | No | ||
| reasoning | No | ||
| extra_body | No | ||
| temperature | No | ||
| tool_choice | No | ||
| instructions | No | ||
| top_logprobs | No | ||
| max_output_tokens | No | ||
| include_raw_response | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| model | No | |
| usage | No | |
| status | No | |
| message | No | |
| retryable | No | |
| error_type | No | |
| suggestion | No | |
| output_text | No | |
| raw_response | No | |
| function_calls | No | |
| reasoning_text | No | |
| incomplete_details | No | |
| stream_event_count | No |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark it openWorld (true) and non-idempotent/non-destructive, so the description needn't re-establish safety. It adds real value beyond them: the default model (deepseek-flash), the stateless nature, SSE streaming semantics, and the caveat that include_raw_response is debugging-only. It does not mention auth requirements, rate limits, or cost/latency implications of effort levels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with capability and default, then feature guidance, then the debugging caveat. Five dense sentences with essentially no filler. Slightly long, but every clause maps to a real parameter or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema excuses it from explaining return values, and it covers the highest-leverage knobs. However, for a 15-parameter, deeply nested, zero-coverage schema, the majority of tunables (sampling, token limits, output format, tool_choice) are undocumented, leaving meaningful gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 15 parameters, so the description carries the full semantic burden. It explains defaults and intent for model, input (text/image URL/base64/file_id), reasoning.effort, tools, stream, and include_raw_response, but leaves temperature, top_p, top_logprobs, max_output_tokens, instructions, user, text/format, tool_choice, and extra_body completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource ('Create a stateless DeepSeek V4.1 response') and pins the API surface ('OpenAI-compatible Responses API'). The 'stateless' framing plus the Responses-API naming distinguishes it from siblings chat_completion and completion without needing to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives actionable guidance for when to use specific features: reasoning.effort for thinking control, tools for function/web-search, stream=true for SSE aggregation, include_raw_response only for debugging, and full input history for multi-turn. It never names chat_completion/completion as the alternative, so the when-not-to-use side 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.
delete_fileBDestructiveIdempotent
Delete one uploaded DeepSeek image by file_id. This permanently removes that provider-side file reference.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| object | No | |
| status | No | |
| deleted | No | |
| message | No | |
| retryable | No | |
| error_type | No | |
| suggestion | No |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the agent already knows this is a destructive, irreversible operation. The description reinforces permanence ('permanently removes') and clarifies that only the provider-side reference is deleted, which adds nuance but little beyond what the annotations supply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, the action and identifier front-loaded, with the destructive consequence stated immediately after. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values need not be explained since an output schema exists, and annotations cover the safety profile, so the description is nearly sufficient. It could still note where a valid file_id is obtained or what happens when the id is unknown, but for a one-parameter mutation it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required parameter, so the description must carry the load; it identifies file_id as referencing an uploaded DeepSeek image, which gives useful meaning. However, it omits the expected 'file-api-' format/constraint and does not say where the id comes from (e.g., upload_file or list_files).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Delete') and resource ('one uploaded DeepSeek image' identified by file_id'), which clearly separates it from siblings like upload_file, list_files, and retrieve_file. It stops short of explicitly naming those alternatives, but the action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, no prerequisites (e.g., ownership of the file), and no mention of alternatives such as re-uploading or listing files first. Usage is only implied by the verb 'Delete'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_balanceARead-onlyIdempotent
Return the current DeepSeek account balance and availability status. This tool takes no parameters and is read-only. Use it for account health checks when diagnosing provider-side failures.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| message | No | |
| retryable | No | |
| error_type | No | |
| suggestion | No | |
| is_available | No | |
| balance_infos | No |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the description's 'read-only' clause is redundant with structured data. The genuinely additive content is the mention of an 'availability status' return and the diagnostic framing, which is useful but modest given the rich annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with no padding; purpose comes first and the usage hint second. The 'takes no parameters and is read-only' clause slightly duplicates schema/annotation data, keeping it just short of perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, a parameterless input, and full annotation coverage, the description only needs to convey purpose and when to reach for it — both are stated. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4. The description correctly states 'takes no parameters,' which matches the empty schema and prevents an agent from guessing at inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Return the current DeepSeek account balance and availability status'), which no sibling tool covers — siblings are chat/completion/file operations. An agent can immediately tell this is an account-diagnostic read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear selection condition: 'Use it for account health checks when diagnosing provider-side failures.' It does not name explicit exclusions, but no sibling overlaps semantically, so the routing guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_conversationsARead-onlyIdempotent
List all conversation IDs currently stored in this MCP process memory. This tool takes no parameters and does not call the DeepSeek API. Useful for debugging conversation persistence behavior.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| status | No | |
| message | No | |
| retryable | No | |
| error_type | No | |
| suggestion | No | |
| conversation_ids | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral facts beyond that: it takes no parameters and, notably, does not call the DeepSeek API, meaning it reads local process state rather than network data. Return format is covered by the existing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action and scope, followed by the no-param/no-API constraint and then the use case. No filler, every sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only inspection tool with a full annotation set and an output schema, the description supplies everything needed: what is listed, where it comes from, that no API call occurs, and why one would use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4. The description reinforces this by explicitly stating 'takes no parameters', which prevents an agent from inventing filter arguments that appear on sibling list tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (conversation IDs) and pins the scope precisely to 'currently stored in this MCP process memory', which separates it from the API-backed siblings like chat_completion and reset_conversation. An agent can identify what it returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context ('Useful for debugging conversation persistence behavior') so the agent knows when it applies, but names no alternatives or exclusions (e.g., that it only shows in-process conversations versus remote ones). Clear context without routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_filesARead-onlyIdempotent
List images uploaded to the DeepSeek Files API. Supports cursor pagination, creation-time order, and the user_data purpose filter.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | ||
| limit | No | ||
| order | No | ||
| purpose | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| object | No | |
| status | No | |
| last_id | No | |
| message | No | |
| first_id | No | |
| has_more | No | |
| retryable | No | |
| error_type | No | |
| suggestion | No |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered externally. The description adds that pagination is cursor-based and ordering is by creation time, which is useful behavior context, but says nothing about page size limits or result boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core purpose front-loaded and capabilities following. No filler, no restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the annotations cover the safety profile. Pagination, ordering, and the purpose filter are covered, but `limit` semantics are absent, leaving a small gap for a 4-parameter list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load; it clarifies that `after` is a cursor, `order` is creation-time ordering, and `purpose` filters to user_data. It omits the `limit` parameter entirely and gives no format or syntax detail, so it only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List images uploaded to the DeepSeek Files API"), which is unambiguous about what the tool returns. It does not name or contrast itself against siblings like retrieve_file or list_conversations, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the read/list use case but offers no explicit when-to-use or when-not-to-use guidance, and never mentions the alternative tools (retrieve_file, delete_file, upload_file) that an agent might confuse it with. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsARead-onlyIdempotent
List available DeepSeek models for model selection and validation. This tool takes no parameters. Use it before passing an explicit model ID to generation tools.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| object | No | |
| status | No | |
| message | No | |
| retryable | No | |
| error_type | No | |
| suggestion | No |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description's only behavioral addition is 'takes no parameters', which the schema already shows, and it says nothing about freshness/caching of the model list or whether the catalog is dynamic across the open world.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the purpose and ending with the actionable instruction. The middle sentence restates the empty schema, which is mildly redundant, keeping it just under full marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value shape need not be explained, and a no-parameter list tool needs little more than purpose and timing. The description covers both, though it omits any hint about catalog freshness or how returned IDs should be matched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The statement 'This tool takes no parameters' reinforces what the empty schema already conveys but adds no new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'List available DeepSeek models', with the added scope of 'for model selection and validation'. It loosely differentiates itself from the generation siblings by positioning itself as a pre-step to them, but it never names a specific sibling tool, so differentiation is directional rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives a when-to-use condition: 'Use it before passing an explicit model ID to generation tools.' That is actionable guidance, though there is no when-not or named alternative (e.g., a cached static list), so it falls short of a full routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reset_conversationADestructiveIdempotent
Delete stored in-memory chat history for a conversation_id. Use this when you want to keep the same ID but start a fresh thread. This only affects server-side memory in the current MCP process.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| message | No | |
| removed | No | |
| retryable | No | |
| error_type | No | |
| suggestion | No | |
| conversation_id | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds real value beyond them by scoping the destruction to server-side memory 'in the current MCP process' and clarifying the conversation_id itself survives, which an agent could not infer from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, then usage intent, then scope limitation. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param destructive reset with an output schema present, the description covers action, intent, and blast radius adequately. The only minor gap is behavior when the conversation_id doesn't exist, but return values are handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is one required param, but the description clarifies the semantics of conversation_id: it is the identifier of the thread whose history is erased, and it remains valid afterward. That is meaningful added meaning, though it doesn't state the format or error behavior for unknown IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Delete) and resource (stored in-memory chat history) scoped to a conversation_id, and is clearly distinguishable from siblings like delete_file or list_conversations. The 'in-memory' qualifier immediately frames what kind of history is affected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context: 'Use this when you want to keep the same ID but start a fresh thread.' This tells the agent the intent (reset rather than delete the conversation), though it names no explicit alternative sibling tool for the opposite case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
retrieve_fileBRead-onlyIdempotent
Retrieve metadata for one DeepSeek Files API image by file_id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| bytes | No | |
| object | No | |
| status | No | |
| message | No | |
| purpose | No | |
| filename | No | |
| retryable | No | |
| created_at | No | |
| error_type | No | |
| expires_at | No | |
| suggestion | No |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and repeat-call profile is fully covered structurally. The description adds only that it returns metadata (not file bytes) for a single image, which is a modest but real clarification beyond annotations; it says nothing about permission requirements or error behavior for a missing id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource and back-loaded with the identifier; there is no filler whatsoever.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described, and annotations cover the safety profile. The remaining gap is minor: how the id is obtained and whether the tool is limited to images are left implicit, but nothing required to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter carries only a regex pattern, so the description does the naming work by stating the lookup is 'by file_id'. However, it adds no meaning beyond the parameter name — it does not explain the expected 'file-api-' prefix format or that the id comes from upload_file/list_files.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Retrieve), a precise resource (metadata for one image), and the identifier used to select it (file_id), which separates it from the plural list_files and the mutating delete_file/upload_file siblings. It stops short of explicitly contrasting itself with list_files or stating whether non-image files are handled, so it is clear but not fully sibling-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus list_files or upload_file, no prerequisites, and no exclusions. The only implicit cue is that it fetches a single known file, which the agent must infer from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_fileA
Upload a JPEG, PNG, GIF, or WebP image to DeepSeek and return a reusable file_id. Supply base64 image data directly; server-local file paths are intentionally not accepted. Optional expiry is 3,600 to 2,592,000 seconds.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| file_data | Yes | ||
| expires_after_seconds | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| bytes | No | |
| object | No | |
| status | No | |
| message | No | |
| purpose | No | |
| filename | No | |
| retryable | No | |
| created_at | No | |
| error_type | No | |
| expires_at | No | |
| suggestion | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write/non-idempotent/open-world semantics, so the bar is lower; the description still adds real value by disclosing the accepted formats, the base64-only input restriction, the reusable file_id return, and the expiry window bounds (3,600–2,592,000s). It omits size limits, auth requirements, and what happens to the file when expiry elapses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with purpose and return value, then the input constraint, then the expiry detail. No filler, no repetition of the tool name, and each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not strictly required (the file_id mention is a bonus). For a 3-parameter upload tool the description covers formats, input mode, and expiry adequately, though it leaves file-size limits and any permission/auth prerequisites unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does: it explains file_data must be base64 image data of a listed type, and that expires_after_seconds is optional with a 3,600–2,592,000 second range. The filename parameter's role and its 512-character cap are left unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource ('Upload a JPEG, PNG, GIF, or WebP image to DeepSeek') and names the concrete artifact returned ('a reusable `file_id`'). This is unmistakably distinct from the sibling read/delete operations (list_files, retrieve_file, delete_file) without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives one hard input constraint ('Supply base64 image data directly; server-local file paths are intentionally not accepted') which steers how to call it, but never states when to prefer this tool over siblings or what precondition must hold (e.g. a file_id is needed by a later chat call). Usage context is implied rather than explicit.
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.
11 tool updates
v1.0.1- Changed
chat_completion8 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / message / anyOfAdded value: +[ + { + "minLength": 1, + "type": "string" + }, + { + "items": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "text": { + "minLength": 1, + "type": "string" + }, + "type": { + "const": "text", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "image_url": { + "additionalProperties": false, + "properties": { + "detail": { + "enum": [ + "low", + "high", + "original", + "auto" + ], + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "url" + ], + "type": "object" + }, + "type": { + "const": "image_url", + "type": "string" + } + }, + "required": [ + "type", + "image_url" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "file_data": { + "type": "string" + }, + "file_id": { + "pattern": "^file-api-[a-zA-Z0-9_-]+$", + "type": "string" + }, + "filename": { + "maxLength": 512, + "minLength": 1, + "type": "string" + }, + "type": { + "const": "file", + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + } + ] + }, + "minItems": 1, + "type": "array" + } +] - removed
Input schema / properties / message / minLengthRemoved value: -1 - removed
Input schema / properties / message / typeRemoved value: -"string" - changed
Input schema / properties / messages / items / properties / content / anyOfPrevious value: -[ - { - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "type": "string" + }, + { + "items": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "text": { + "minLength": 1, + "type": "string" + }, + "type": { + "const": "text", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "image_url": { + "additionalProperties": false, + "properties": { + "detail": { + "enum": [ + "low", + "high", + "original", + "auto" + ], + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "url" + ], + "type": "object" + }, + "type": { + "const": "image_url", + "type": "string" + } + }, + "required": [ + "type", + "image_url" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "file_data": { + "type": "string" + }, + "file_id": { + "pattern": "^file-api-[a-zA-Z0-9_-]+$", + "type": "string" + }, + "filename": { + "maxLength": 512, + "minLength": 1, + "type": "string" + }, + "type": { + "const": "file", + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + } + ] + }, + "minItems": 1, + "type": "array" + }, + { + "type": "null" + } +] - changed
Input schema / properties / model / defaultPrevious value: -"deepseek-v4-flash"New value: +"deepseek-flash" - changed
Input schema / properties / reasoning_effort / enumPrevious value: -[ - "low", - "high", - "max" -]New value: +[ + "none", + "minimal", + "low", + "medium", + "high", + "xhigh", + "max" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "conversation_id": { + "type": [ + "string", + "null" + ] + }, + "error_type": { + "enum": [ + "deepseek_api_error", + "tool_execution_error" + ], + "type": "string" + }, + "finish_reason": { + "type": [ + "string", + "null" + ] + }, + "message": { + "type": "string" + }, + "model": { + "type": "string" + }, + "raw_response": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "reasoning_content": { + "type": [ + "string", + "null" + ] + }, + "response_text": { + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "status": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "stream_chunk_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "suggestion": { + "type": "string" + }, + "tool_calls": { + "items": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "usage": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + } + }, + "type": "object" +}
- Changed
completion3 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Input schema / properties / model / defaultPrevious value: -"deepseek-v4-pro"New value: +"deepseek-flash" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "error_type": { + "enum": [ + "deepseek_api_error", + "tool_execution_error" + ], + "type": "string" + }, + "finish_reason": { + "type": [ + "string", + "null" + ] + }, + "message": { + "type": "string" + }, + "model": { + "type": "string" + }, + "raw_response": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "retryable": { + "type": "boolean" + }, + "status": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "stream_chunk_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "suggestion": { + "type": "string" + }, + "text": { + "type": "string" + }, + "usage": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + } + }, + "type": "object" +}
- Changed
create_response3 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Input schema / properties / input / anyOfPrevious value: -[ - { - "minLength": 1, - "type": "string" - }, - { - "items": { - "anyOf": [ - { - "additionalProperties": {}, - "properties": { - "content": { - "anyOf": [ - { - "type": "string" - }, - { - "items": { - "anyOf": [ - { - "additionalProperties": {}, - "properties": { - "text": { - "minLength": 1, - "type": "string" - }, - "type": { - "const": "input_text", - "type": "string" - } - }, - "required": [ - "type", - "text" - ], - "type": "object" - }, - { - "additionalProperties": {}, - "properties": { - "text": { - "minLength": 1, - "type": "string" - }, - "type": { - "const": "output_text", - "type": "string" - } - }, - "required": [ - "type", - "text" - ], - "type": "object" - } - ] - }, - "minItems": 1, - "type": "array" - } - ] - }, - "role": { - "enum": [ - "user", - "assistant", - "system", - "developer" - ], - "type": "string" - }, - "type": { - "const": "message", - "type": "string" - } - }, - "required": [ - "role", - "content" - ], - "type": "object" - }, - { - "additionalProperties": {}, - "properties": { - "arguments": { - "type": "string" - }, - "call_id": { - "minLength": 1, - "type": "string" - }, - "name": { - "minLength": 1, - "type": "string" - }, - "type": { - "const": "function_call", - "type": "string" - } - }, - "required": [ - "type", - "call_id", - "name", - "arguments" - ], - "type": "object" - }, - { - "additionalProperties": {}, - "properties": { - "call_id": { - "minLength": 1, - "type": "string" - }, - "output": { - "type": "string" - }, - "type": { - "const": "function_call_output", - "type": "string" - } - }, - "required": [ - "type", - "call_id", - "output" - ], - "type": "object" - }, - { - "additionalProperties": {}, - "properties": { - "content": { - "items": { - "additionalProperties": {}, - "properties": { - "text": { - "minLength": 1, - "type": "string" - }, - "type": { - "const": "reasoning_text", - "type": "string" - } - }, - "required": [ - "type", - "text" - ], - "type": "object" - }, - "minItems": 1, - "type": "array" - }, - "type": { - "const": "reasoning", - "type": "string" - } - }, - "required": [ - "type", - "content" - ], - "type": "object" - }, - { - "additionalProperties": {}, - "properties": { - "type": { - "const": "web_search_call", - "type": "string" - } - }, - "required": [ - "type" - ], - "type": "object" - } - ] - }, - "minItems": 1, - "type": "array" - } -]New value: +[ + { + "minLength": 1, + "type": "string" + }, + { + "items": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "content": { + "anyOf": [ + { + "type": "string" + }, + { + "items": { + "anyOf": [ + { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "text": { + "minLength": 1, + "type": "string" + }, + "type": { + "const": "input_text", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "text": { + "minLength": 1, + "type": "string" + }, + "type": { + "const": "output_text", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "type": "object" + } + ] + }, + { + "additionalProperties": {}, + "properties": { + "detail": { + "enum": [ + "low", + "high", + "original", + "auto" + ], + "type": "string" + }, + "file_id": { + "pattern": "^file-api-[a-zA-Z0-9_-]+$", + "type": "string" + }, + "image_url": { + "type": "string" + }, + "type": { + "const": "input_image", + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + } + ] + }, + "minItems": 1, + "type": "array" + } + ] + }, + "role": { + "enum": [ + "user", + "assistant", + "system", + "developer" + ], + "type": "string" + }, + "type": { + "const": "message", + "type": "string" + } + }, + "required": [ + "role", + "content" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "arguments": { + "type": "string" + }, + "call_id": { + "minLength": 1, + "type": "string" + }, + "name": { + "minLength": 1, + "type": "string" + }, + "type": { + "const": "function_call", + "type": "string" + } + }, + "required": [ + "type", + "call_id", + "name", + "arguments" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "call_id": { + "minLength": 1, + "type": "string" + }, + "output": { + "anyOf": [ + { + "type": "string" + }, + { + "items": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "text": { + "minLength": 1, + "type": "string" + }, + "type": { + "const": "input_text", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "detail": { + "enum": [ + "low", + "high", + "original", + "auto" + ], + "type": "string" + }, + "file_id": { + "pattern": "^file-api-[a-zA-Z0-9_-]+$", + "type": "string" + }, + "image_url": { + "type": "string" + }, + "type": { + "const": "input_image", + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + } + ] + }, + "minItems": 1, + "type": "array" + } + ] + }, + "type": { + "const": "function_call_output", + "type": "string" + } + }, + "required": [ + "type", + "call_id", + "output" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "call_id": { + "minLength": 1, + "type": "string" + }, + "input": { + "type": "string" + }, + "name": { + "minLength": 1, + "type": "string" + }, + "type": { + "const": "custom_tool_call", + "type": "string" + } + }, + "required": [ + "type", + "call_id", + "name", + "input" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "call_id": { + "minLength": 1, + "type": "string" + }, + "output": { + "anyOf": [ + { + "type": "string" + }, + { + "items": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "text": { + "minLength": 1, + "type": "string" + }, + "type": { + "const": "input_text", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "detail": { + "enum": [ + "low", + "high", + "original", + "auto" + ], + "type": "string" + }, + "file_id": { + "pattern": "^file-api-[a-zA-Z0-9_-]+$", + "type": "string" + }, + "image_url": { + "type": "string" + }, + "type": { + "const": "input_image", + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + } + ] + }, + "minItems": 1, + "type": "array" + } + ] + }, + "type": { + "const": "custom_tool_call_output", + "type": "string" + } + }, + "required": [ + "type", + "call_id", + "output" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "content": { + "items": { + "additionalProperties": {}, + "properties": { + "text": { + "minLength": 1, + "type": "string" + }, + "type": { + "const": "reasoning_text", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "type": "object" + }, + "minItems": 1, + "type": "array" + }, + "type": { + "const": "reasoning", + "type": "string" + } + }, + "required": [ + "type", + "content" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": { + "type": { + "const": "web_search_call", + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + } + ] + }, + "minItems": 1, + "type": "array" + } +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "error": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "error_type": { + "enum": [ + "deepseek_api_error", + "tool_execution_error" + ], + "type": "string" + }, + "function_calls": { + "items": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "incomplete_details": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "message": { + "type": "string" + }, + "model": { + "type": "string" + }, + "output_text": { + "type": "string" + }, + "raw_response": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "reasoning_text": { + "type": [ + "string", + "null" + ] + }, + "retryable": { + "type": "boolean" + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "stream_event_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "suggestion": { + "type": "string" + }, + "usage": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + } + }, + "type": "object" +}
- Added
delete_file - Changed
get_user_balance2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "balance_infos": { + "items": { + "additionalProperties": false, + "properties": { + "currency": { + "type": "string" + }, + "granted_balance": { + "type": "string" + }, + "topped_up_balance": { + "type": "string" + }, + "total_balance": { + "type": "string" + } + }, + "required": [ + "currency", + "total_balance", + "granted_balance", + "topped_up_balance" + ], + "type": "object" + }, + "type": "array" + }, + "error_type": { + "enum": [ + "deepseek_api_error", + "tool_execution_error" + ], + "type": "string" + }, + "is_available": { + "type": "boolean" + }, + "message": { + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "status": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "suggestion": { + "type": "string" + } + }, + "type": "object" +}
- Changed
list_conversations2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "conversation_ids": { + "items": { + "type": "string" + }, + "type": "array" + }, + "count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "error_type": { + "enum": [ + "deepseek_api_error", + "tool_execution_error" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "status": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "suggestion": { + "type": "string" + } + }, + "type": "object" +}
- Added
list_files - Changed
list_models2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "data": { + "items": { + "additionalProperties": {}, + "properties": { + "created": { + "type": "number" + }, + "id": { + "type": "string" + }, + "object": { + "type": "string" + }, + "owned_by": { + "type": "string" + } + }, + "required": [ + "id", + "object" + ], + "type": "object" + }, + "type": "array" + }, + "error_type": { + "enum": [ + "deepseek_api_error", + "tool_execution_error" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "object": { + "type": "string" + }, + "retryable": { + "type": "boolean" + }, + "status": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "suggestion": { + "type": "string" + } + }, + "type": "object" +}
- Changed
reset_conversation2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "conversation_id": { + "type": "string" + }, + "error_type": { + "enum": [ + "deepseek_api_error", + "tool_execution_error" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "removed": { + "type": "boolean" + }, + "retryable": { + "type": "boolean" + }, + "status": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "suggestion": { + "type": "string" + } + }, + "type": "object" +}
- Added
retrieve_file - Added
upload_file
2 tool updates
v0.6.0- Changed
chat_completion2 fields changed- changed
Input schema / properties / reasoning_effort / enumPrevious value: -[ - "high", - "max" -]New value: +[ + "low", + "high", + "max" +] - added
Input schema / properties / user_idAdded value: +{ + "maxLength": 512, + "minLength": 1, + "pattern": "^[a-zA-Z0-9_-]+$", + "type": "string" +}
- Added
create_response
7 tool updates
v0.5.0- Changed
chat_completion32 fields changed- added
Input schema / properties / clear_conversationAdded value: +{ + "default": false, + "type": "boolean" +} - added
Input schema / properties / conversation_idAdded value: +{ + "minLength": 1, + "type": "string" +} - added
Input schema / properties / extra_bodyAdded value: +{ + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" +} - removed
Input schema / properties / frequency_penalty / defaultRemoved value: -0.1 - added
Input schema / properties / include_raw_responseAdded value: +{ + "default": false, + "type": "boolean" +} - added
Input schema / properties / logprobsAdded value: +{ + "type": "boolean" +} - removed
Input schema / properties / max_tokens / defaultRemoved value: -8000 - added
Input schema / properties / message / minLengthAdded value: +1 - added
Input schema / properties / messages / items / additionalPropertiesAdded value: +{} - added
Input schema / properties / messages / items / properties / content / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - removed
Input schema / properties / messages / items / properties / content / typeRemoved value: -"string" - added
Input schema / properties / messages / items / properties / nameAdded value: +{ + "type": "string" +} - added
Input schema / properties / messages / items / properties / prefixAdded value: +{ + "type": "boolean" +} - added
Input schema / properties / messages / items / properties / reasoning_contentAdded value: +{ + "type": "string" +} - changed
Input schema / properties / messages / items / properties / role / enumPrevious value: -[ - "system", - "user", - "assistant" -]New value: +[ + "system", + "user", + "assistant", + "tool" +] - added
Input schema / properties / messages / items / properties / tool_call_idAdded value: +{ + "type": "string" +} - added
Input schema / properties / messages / items / properties / tool_callsAdded value: +{ + "items": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" +} - changed
Input schema / properties / messages / items / requiredPrevious value: -[ - "role", - "content" -]New value: +[ + "role" +] - added
Input schema / properties / messages / minItemsAdded value: +1 - changed
Input schema / properties / model / defaultPrevious value: -"deepseek-reasoner"New value: +"deepseek-v4-flash" - removed
Input schema / properties / presence_penalty / defaultRemoved value: -0 - added
Input schema / properties / reasoning_effortAdded value: +{ + "enum": [ + "high", + "max" + ], + "type": "string" +} - added
Input schema / properties / response_formatAdded value: +{ + "additionalProperties": {}, + "properties": { + "type": { + "enum": [ + "text", + "json_object" + ], + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" +} - added
Input schema / properties / stopAdded value: +{ + "anyOf": [ + { + "minLength": 1, + "type": "string" + }, + { + "items": { + "minLength": 1, + "type": "string" + }, + "maxItems": 16, + "minItems": 1, + "type": "array" + } + ] +} - added
Input schema / properties / streamAdded value: +{ + "default": false, + "type": "boolean" +} - added
Input schema / properties / stream_optionsAdded value: +{ + "additionalProperties": {}, + "properties": { + "include_usage": { + "type": "boolean" + } + }, + "type": "object" +} - removed
Input schema / properties / temperature / defaultRemoved value: -0.7 - added
Input schema / properties / thinkingAdded value: +{ + "additionalProperties": false, + "properties": { + "type": { + "enum": [ + "enabled", + "disabled" + ], + "type": "string" + } + }, + "type": "object" +} - added
Input schema / properties / tool_choiceAdded value: +{ + "anyOf": [ + { + "enum": [ + "none", + "auto", + "required" + ], + "type": "string" + }, + { + "additionalProperties": {}, + "properties": { + "function": { + "additionalProperties": {}, + "properties": { + "name": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": { + "const": "function", + "type": "string" + } + }, + "required": [ + "type", + "function" + ], + "type": "object" + } + ] +} - added
Input schema / properties / toolsAdded value: +{ + "items": { + "additionalProperties": {}, + "properties": { + "function": { + "additionalProperties": {}, + "properties": { + "description": { + "type": "string" + }, + "name": { + "minLength": 1, + "type": "string" + }, + "parameters": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "strict": { + "type": "boolean" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": { + "const": "function", + "type": "string" + } + }, + "required": [ + "type", + "function" + ], + "type": "object" + }, + "type": "array" +} - added
Input schema / properties / top_logprobsAdded value: +{ + "maximum": 20, + "minimum": 0, + "type": "integer" +} - removed
Input schema / properties / top_p / defaultRemoved value: -1
- Added
completion - Added
get_user_balance - Added
list_conversations - Added
list_models - Removed
multi_turn_chat - Added
reset_conversation
2 tool updates
v1.0.0- First observed
chat_completion - First observed
multi_turn_chat
TDQS
A3.9/5.0
Scored across 11 tools
Disambiguation4/5
The three generation tools (chat_completion, completion, create_response) have overlapping capabilities like text/image input and multi-turn support, which could cause confusion. However, their descriptions clearly differentiate use cases (chat vs FIM vs stateless Responses API), and all other tools target distinct resources or actions.
Naming Consistency4/5
Nine of eleven tools follow a consistent verb_noun pattern (e.g., list_models, upload_file, delete_file). The two exceptions (chat_completion and completion) are noun-only names, but they are conventional and readable, making the set mostly predictable.
Tool Count5/5
The server provides 11 tools, which is well within the ideal 3–15 range. Each tool covers a distinct aspect of the DeepSeek API (generation, file management, account info, conversation memory), with no obvious redundancy or bloat.
Completeness4/5
The surface covers core generation, file CRUD (upload/list/retrieve/delete), model listing, balance check, and conversation memory management. Minor gaps include no explicit update or detailed inspection of conversations, but these are not critical for typical workflows.
Maintenance
ActivityMaintained
ResponsivenessResponsive
Related MCP Connectors
Connect MCP clients to 2,000+ AI models without managing provider API keys.
MCP server for AI dialogue using various LLM models via AceDataCloud
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
MCP server for GLM chat completions using Zhipu AI models via AceDataCloud
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.2800 npm2MIT
- FlicenseNot gradedqualityDmaintenanceIntegrates local language models (like Qwen3-8B) with MCP clients, providing tools for chat, code analysis, text generation, translation, and content summarization using your own hardware.-
- AlicenseAqualityAmaintenanceMCP server for DeepSeek AI models (Chat + Reasoner). Supports multi-turn sessions, model fallback with circuit breaker, function calling, thinking mode, JSON output, multimodal input, and cost tracking.3698 npm18MIT