Skip to main content
Glama
zztdandan

DeepSeek × Exa Search Combine MCP

by zztdandan

Combined web search

search

Queries DeepSeek and Exa in parallel, then deduplicates and merges overlapping web results into one source-labeled list; restrict to one provider or fetch page text when needed.

Instructions

Search the web through DeepSeek and Exa at once and get back a single deduplicated list. By default every configured provider is queried in parallel and pages found by both are merged into one entry (labelled with all sources). Pass provider="exa" or "deepseek" to use just one. If only one API key is configured, the default automatically narrows to that provider.

Input Schema

NameRequiredDescriptionDefault
typeNoExa only search mode: auto (default), lite, deep-lite, deep, instant, fast.
countNoResults per provider (Exa caps at 100, DeepSeek at 50). Default 8.
queryYesSearch query. DeepSeek supports operators: site:, -site:, "exact phrase", -word, lang:zh,en, after:2025, before:2026-06-01.
categoryNoExa only. Focus the index on one data category.
providerNoWhich backend(s) to query. Omit or "both" to use every configured provider; "exa" / "deepseek" to force one.
max_charsNoPer-page text cap when need_content is true. Default 4000.
localizationNoDeepSeek only. IP address used to localize results.
need_contentNoAlso fetch page body text for each hit. Much larger responses and higher cost.
ori_questionNoDeepSeek only. The original user question, improves query understanding (max 128 chars).
exclude_domainsNoExa only. Exclude these domains or domain paths.
include_domainsNoExa only. Restrict results to these domains or domain paths.
end_published_dateNoExa only. ISO 8601 upper bound.
start_published_dateNoExa only. ISO 8601 lower bound, e.g. 2025-01-01T00:00:00.000Z

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and discloses meaningful behavior beyond the schema: providers are queried in parallel by default, duplicate pages are merged into one entry labeled with all sources, and provider selection auto-narrows when only one key is configured. It does not cover response errors, pagination, or rate limits, but the core operational behavior is well explained.

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 tightly written sentences with the main purpose and default behavior front-loaded. Every sentence adds information about combined search, deduplication, or provider selection without waste.

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 13-parameter search tool with no annotations or output schema, the description does enough: it explains the combined-backend model, deduplication, source labeling, and provider defaulting. Return behavior is summarized at a high level, while detailed parameter semantics remain well covered by the 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 description coverage is already 100%, so the baseline is 3, but the description adds useful meaning for the provider parameter: default parallel querying across all configured providers, explicit provider forcing, and automatic narrowing with a single API key. Other parameters are left to the schema, which is appropriate given its full coverage.

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: search the web through DeepSeek and Exa, returning a single deduplicated list. It also clarifies the default multi-provider behavior and merged deduplication, so the tool is distinguishable from a simple single-backend search or fetch.

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 context for provider selection: default queries every configured provider, provider="exa" or "deepseek" forces one, and a single configured API key automatically narrows the default. It does not explicitly compare this tool against sibling tools such as fetch or status, but usage context is otherwise clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools