DeepSeek MCP Server

by booleamu

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
deepseek_chat and deepseek_multi_turn are highly overlapping, as both support conversational continuation via session_key, making it unclear when to choose one over the other. deepseek_reasoner and deepseek_file_analysis also blur into chat-like behavior, further muddying boundaries.
Naming Consistency4/5
All tools share the deepseek_ prefix and use snake_case, which establishes a consistent baseline. However, the suffix mixes noun-like names (chat, reasoner, fim) with verb phrases (list_models), and file_analysis deviates from the imperative style, creating minor inconsistency.
Tool Count5/5
Six tools is well-scoped for a DeepSeek model provider wrapper, covering core chat, reasoning, code completion, model listing, and file analysis without excessive fragmentation.
Completeness4/5
The tool set covers the major DeepSeek API interactions (chat, reasoner, FIM, model listing), plus a useful file analysis convenience. Minor gaps such as usage metrics or session management utilities exist but do not hamper core workflows.
Average 3.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the session continuation behavior, which is useful, but it does not mention token consumption, non-determinism, streaming behavior, or the return format. It adds some context beyond the schema but is not comprehensive.
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?
The description is two sentences: the first states the primary purpose and supported tasks, the second covers session continuation. It is concise, front-loaded, and has no unnecessary words.
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?
Given the tool has 8 parameters and no output schema, the description covers the core purpose and session continuation but omits explicit return format and guidance for choosing among sibling tools. It is adequate but leaves gaps for an agent deciding between deepseek_chat and deepseek_multi_turn.
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 100%, so the schema already documents all parameters. The tool description mentions session_key continuation but does not add additional meaning beyond the schema. Baseline 3 applies as the schema handles parameter semantics well.
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 clearly states the tool invokes the DeepSeek model for chat completion and lists supported tasks (code generation, Q&A, translation). It distinguishes from sibling tools like deepseek_reasoner and deepseek_fim by focusing on general dialogue, but it does not explicitly differentiate from deepseek_multi_turn, which may also handle multi-turn chat.
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 gives context on when to use the tool (for chat, code, Q&A, translation) and how to continue conversations via session_key. However, it does not explicitly state when to prefer this tool over deepseek_multi_turn or deepseek_reasoner, nor does it provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral transparency. It only says 'query list', implying read-only, but does not disclose response format, ordering, authentication requirements, or any rate limits. Minimal disclosure leaves significant room for surprise.
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?
A single, concise sentence that is front-loaded with the verb and resource. No fluff or repetitive content. Every word adds value.
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 tool is simple (0 params, no output schema), so minimal description may suffice. However, it lacks context about what the returned list will contain (e.g., model IDs, names, descriptions) and whether this list is dynamic. Slightly under-specified for an agent to know what to expect.
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?
The tool has zero parameters, so the schema provides no meaning to add. The description correctly references the resource being queried, and with no params to document, a baseline of 4 is appropriate.
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?
The description clearly states the action (query) and resource (list of available models on DeepSeek platform), making it distinct from sibling tools like deepseek_chat or deepseek_fim. The phrase 'currently available' adds temporal scope without ambiguity.
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?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that it's for discovering available models before choosing a chat/fim tool, nor does it provide any exclusion criteria. The absence of any usage context leaves the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does reveal an important distinction: API Key mode uses the native FIM interface, while web version simulates via dialogue. However, it omits other relevant behaviors such as required authentication, rate limits, or the exact output format, leaving room for ambiguity.
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?
The description is a single compact sentence that front-loads the core purpose ('Fill-in-the-Middle') and adds only essential context about the two modes. Every word earns its place with no fluff or repetition.
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?
Given a simple FIM tool with fully documented parameters, the description provides adequate context: what it does, how it operates in different modes, and the expected input. It lacks an explicit statement of the return value, but for this tool the output (generated middle code) is easily inferred. The absence of an output schema is partially mitigated by the straightforward nature of the 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?
The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description text mentions prefix and suffix but does not add extra meaning beyond the schema, such as parameter constraints, defaults, or interactions.
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?
The description clearly states the tool's purpose: 'Fill-in-the-Middle 代码补全' (fill-in-the-middle code completion) and explains it generates middle code from a prefix and suffix. This specific verb+resource combination distinguishes it from sibling tools like deepseek_chat and deepseek_reasoner, which are for general conversation or reasoning.
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 usage context by naming the specialized FIM functionality, but it does not explicitly compare to alternatives or state when to prefer this over other DeepSeek tools. It does provide some usage-related guidance by mentioning two modes (API Key native FIM vs web version simulated), which helps the agent understand environment-dependent behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool carries full message history and supports session continuation, but it does not explain underlying mechanics (e.g., whether full history is always required, session expiration) or mention side effects/return format. Some value is added despite gaps.
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?
A single, concise Chinese sentence with zero filler. It front-loads the core purpose (multi-turn dialogue with full context) and then adds the unique session_key feature. Every word earns its place.
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 description covers the tool's purpose and key feature, and the schema covers all 5 parameters, so it is adequate. However, it lacks details about return values (no output schema), error handling, or explicit comparison to alternatives, leaving some context unexplained for a 5-parameter 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 100%, so the baseline is 3. The description mentions session_key ('支持通过 session_key 续接上一次对话') but adds no additional parameter semantics beyond what the schema already documents for each field.
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?
The description explicitly states the verb+resource: '多轮对话，携带完整历史消息上下文调用 DeepSeek 模型' (multi-turn dialogue calling DeepSeek model with full history). It also highlights the distinguishing session_key continuation feature, which sets it apart from sibling tools like deepseek_chat and deepseek_reasoner.
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?
The description clearly implies usage for multi-turn conversations: '多轮对话' and '支持通过 session_key 续接上一次对话' (supports resuming via session_key). However, it does not explicitly name alternatives or state when not to use the tool, though sibling names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses the core behaviors (invokes R1, returns reasoning and answer, supports session continuation), but omits potential operational details like latency, cost, or rate limits. Still, it adequately conveys the primary behavior for an AI tool.
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?
The description is a single, focused sentence that conveys the main action, output, and session capability without unnecessary words. It is concise and well-structured.
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?
Given the tool's simple invocation and 100% schema coverage, the description covers the essential purpose and return format even without an output schema. It leaves out only minor details that are well-handled by the schema.
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 100%, so the baseline applies. The description adds only a brief mention of session_key continuation, but the schema already documents this parameter in detail. No additional parameter meaning is provided.
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?
The description clearly specifies a specific verb (call), a specific resource (DeepSeek-Reasoner R1 model), and a precise action (deep reasoning) with its output (full reasoning process and final answer). It also distinguishes itself from siblings by emphasizing the reasoning capability.
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?
The description implies usage for deep reasoning tasks and mentions session support, which gives clear context. However, it does not explicitly reference sibling tools or state when NOT to use it, leaving some ambiguity compared to deepseek_chat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It clearly states the file content is sent externally to DeepSeek and restricted to text, which are the primary behavioral traits. It does not mention return format or side effects, but the external transmission and text-only limitation are effectively communicated.
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?
The description is a single, focused sentence that immediately conveys the action, target, and key limitation. There is no redundant wording; every phrase carries value, making it highly concise and well-structured.
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?
For a tool without an output schema or annotations, the description is somewhat sparse. It omits details about the response format, any prerequisites (e.g., API key configuration), and potential behavioral nuances like file size limits. While the core purpose is covered, a bit more context would make it fully complete.
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 100%, so the baseline is 3. The description adds meaningful context beyond the schema by noting the API Key mode restriction (single text file) and the mode distinction between file_path and file_paths. This helps the agent choose the correct parameter and clarifies the 'text' constraint not present in the schema.
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?
The description clearly states the tool reads file content and sends it to DeepSeek for analysis, with a specific verb (read/send), resource (file), and outcome (analysis). It stands apart from sibling chat/reasoning tools by focusing on file-based input, making its purpose unmistakable.
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?
The description explicitly frames when to use the tool: for file analysis. It also notes a crucial constraint ('API Key mode: only supports a single text file'), which indirectly guides against using it for multiple files or binary formats in that mode. However, it does not name alternative tools for multi-file or web-mode scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![deepseek-mcp-server MCP server](https://glama.ai/mcp/servers/booleamu/deepseek-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/booleamu/deepseek-mcp-server)

Score Badge

Copy to your README.md:

[![deepseek-mcp-server MCP server](https://glama.ai/mcp/servers/booleamu/deepseek-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/booleamu/deepseek-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/booleamu/deepseek-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server