Skip to main content
Glama
ruali-dev

deepseek-web

by ruali-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

deepseek-web

Unofficial, lightweight stdio MCP server for DeepSeek Search and Fetch. This project is not affiliated with, endorsed by, or sponsored by DeepSeek.

Requirements and installation

Node.js 20 or newer. Install from npm:

npm install -g deepseek-web

Or run it without a global install:

npx -y deepseek-web

For local development:

npm install
npm run build
node dist/index.js

Set DEEPSEEK_API_KEY in the MCP server's environment. Obtain a key from DeepSeek Platform. DEEPSEEK_BASE_URL is optional and defaults to https://api.deepseek.com.

export DEEPSEEK_API_KEY=YOUR_KEY
npx -y deepseek-web

The server writes diagnostics to stderr. stdout is reserved for MCP's stdio protocol.

Related MCP server: Kimi Search MCP

Tools

  • search(query, count?, ori_question?, need_content?, localization?): query is required, must contain 1–128 Unicode characters, and cannot be blank. Longer queries return an error; they are never truncated. count defaults to 10 and is clamped to 1–50. Results include URL, title, summary, rerank score, authority, date, and snippet when returned by the API.

  • fetch(url): retrieves one HTTP(S) page as Markdown. URLs must have a host, cannot contain username/password credentials, and are limited to 8,192 characters.

HTTP 403/404 and other DeepSeek API errors are returned as MCP tool errors with an explanatory message. HTTP 429 responses are retried up to three times with exponential backoff and jitter.

MCP client configuration

Examples use npx -y deepseek-web so the client can launch the package. If configuring before publishing, build locally and replace command/args with node and the absolute path to dist/index.js.

Claude Code

Add to project .mcp.json:

{
  "mcpServers": {
    "deepseek-web": {
      "command": "npx",
      "args": ["-y", "deepseek-web"],
      "env": {
        "DEEPSEEK_API_KEY": "${DEEPSEEK_API_KEY}"
      }
    }
  }
}

CLI alternative:

claude mcp add --env DEEPSEEK_API_KEY=YOUR_KEY --transport stdio deepseek-web -- npx -y deepseek-web

See Claude Code MCP configuration.

OpenCode

Add to opencode.json or opencode.jsonc (OpenCode V2 local-server dialect):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "servers": {
      "deepseek-web": {
        "type": "local",
        "command": ["npx", "-y", "deepseek-web"],
        "environment": {
          "DEEPSEEK_API_KEY": "{env:DEEPSEEK_API_KEY}"
        }
      }
    }
  }
}

This uses OpenCode's mcp.servers, type: "local", command array, and environment fields; it is not the mcpServers JSON dialect. See OpenCode MCP servers.

Codex

Add to ~/.codex/config.toml or project .codex/config.toml:

[mcp_servers.deepseek-web]
command = "npx"
args = ["-y", "deepseek-web"]

[mcp_servers.deepseek-web.env]
DEEPSEEK_API_KEY = "YOUR_KEY"

CLI alternative:

codex mcp add deepseek-web --env DEEPSEEK_API_KEY=YOUR_KEY -- npx -y deepseek-web

See Codex MCP configuration.

Cursor (ordinary MCP, not a Plugin)

Add to project .cursor/mcp.json or global ~/.cursor/mcp.json:

{
  "mcpServers": {
    "deepseek-web": {
      "command": "npx",
      "args": ["-y", "deepseek-web"],
      "env": {
        "DEEPSEEK_API_KEY": "${env:DEEPSEEK_API_KEY}"
      }
    }
  }
}

Cursor uses the regular MCP configuration file. This package has no Cursor Plugin layout or Marketplace integration. See Cursor MCP.

Pricing and limits

DeepSeek's English documentation lists $0.75 per 1,000 successful Search or Fetch calls; the Chinese documentation lists ¥5 per 1,000 successful calls. The account's billing currency and how these figures map to a particular account are unknown; verify against DeepSeek's current billing information. DeepSeek documents a limit of 5 QPS for Search and Fetch (account-level); Fetch may also have an undisclosed per-domain limit. Pricing and limits can change.

Smoke check

With DEEPSEEK_API_KEY set, run:

npm run smoke

The script directly calls Search for a small result set, then Fetches the first returned URL. These are real API calls and may be subject to DeepSeek account limits and billing. Equivalent curl checks:

curl https://api.deepseek.com/v1/tools/search \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"DeepSeek Search API","count":5,"need_content":false}'

curl https://api.deepseek.com/v1/tools/fetch \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://api-docs.deepseek.com/guides/search/"}'

License

MIT. See LICENSE.

Available Tools

2 tools
fetchB

Fetch one HTTP or HTTPS page and return its title and Markdown content.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesHTTP or HTTPS URL to fetch (maximum 8192 characters).

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. It does disclose the return shape (title + Markdown), which is real behavioral value, but says nothing about authentication, redirects, rate limits, non-HTML responses, truncation of large pages, or failure behavior.

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 sentence with zero filler, front-loading the action and the returned content. Nothing redundant or padded.

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?

Because there is no output schema, the description correctly compensates by naming the returned fields (title and Markdown content). What remains missing is failure/edge-case behavior — non-HTML content, oversized pages, or blocked requests — which a fetch tool would benefit from.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents the URL requirement and the 8192-character cap. The description adds no syntax or format detail beyond that, matching the baseline for high-coverage schemas.

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 (fetch) and resource (one HTTP/HTTPS page) plus the return payload (title and Markdown content). The scope word 'one' usefully signals it is not a crawler or multi-page operation, though it never references the sibling 'search' to sharpen the boundary.

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?

No when-to-use statement, no exclusions, and no mention of when a caller should prefer the sibling 'search' instead. The word 'one' implies a single-URL use case but that is inference, not guidance.

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.

  1. 2 tool updatesv0.1.0
    • First observedfetch
    • First observedsearch
Deploy Server
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

search and fetch have clearly distinct purposes: one performs a web search, the other retrieves a specific page's content. No overlap in functionality, making tool selection unambiguous.

Naming Consistency5/5

Both tools use a simple, consistent verb pattern (search, fetch) with no mixing of conventions. The naming is predictable and readable.

Tool Count3/5

Two tools is borderline thin for the server's apparent scope, as the rubric considers 1-2 tools to feel thin. While search and fetch are the core operations, the set offers no additional functionality.

Completeness4/5

The surface covers the essential web search and page retrieval lifecycle, but minor gaps exist such as no batch fetch, pagination beyond a count limit, or content extraction options. Agents can work around these for basic tasks.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Kimi Search MCP

    CaelixOrbit
    A
    license
    C
    quality
    B
    maintenance
    Enables MCP clients to run web searches and optionally fetch webpages through Moonshot's open platform API, using a configured API key.
    2
    355 npm
    MIT

  • seartch

    Vaib215
    A
    license
    Not graded
    quality
    C
    maintenance
    Exposes metasearch across many engines and a page-to-Markdown fetcher as two MCP tools, web_search and web_fetch, so any MCP client can run searches and pull clean article content on demand. It also supports news-focused queries with category and time-range filters, plus optional inline page content.
    AGPL 3.0