Skip to main content
Glama
SECRET4422

Deep Research MCP Server

by SECRET4422
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Why not generic?

Generic MCP (boring)

This MCP (pro)

echo, fetch

Orchestrated deep research

Returns raw HTML

Cheerio + Turndown → clean markdown + headings, links, meta

No memory

Persistent memory in ~/.mcp-deep-research/

One page at a time

Parallel 3-worker scraper, 10min cache

No reasoning

Fact-check with stance scoring, contradiction detection

Architecture

graph LR
    A[User: deep_research topic] --> B[search_web DDG HTML]
    B --> C[Parallel Scrape x3-8]
    C --> D[cheerio clean + turndown md]
    D --> E[extract_insights heuristic]
    E --> F[Synthesize Report + Citations]
    F --> G[memory_save + history]
    F --> H[Return to Claude]
    
    I[compare_sources] --> C
    J[fact_check_claim] --> B
    K[memory_search] --> G

Tools (8)

Tool

What it does

Params

search_web

DuckDuckGo HTML search, no API key, UDDG decode

query, count 1-10, timeFilter

scrape_page

Fetch + main-content heuristic + markdown

`url, format=markdown

extract_insights

Entities, stats regex, key-point scoring, reading time

content, goal?

deep_research

Power tool — search → parallel scrape → synthesize report

`topic, depth=quick

compare_sources

2-5 URLs → consensus vs unique vs contradictions

urls[], focus?

fact_check_claim

Searches support + debunked OR false, heuristic verdict

claim, searchDepth

memory_save

Save finding to JSON, survives restarts

key, value, tags[], source?

memory_search

Fuzzy search in persistent memory

query, tags[], limit

Resources:

  • research://memory — all saved findings

  • research://history — last 100 actions

  • research://stats — cache size, uptime

Prompts:

  • deep-dive-research — full research workflow

  • fact-check — fact-checker squad

  • compare-narratives — bias & comparison table

Quickstart & Installation

⚡ 1-Click Auto Setup for Claude Desktop (Recommended)

Run this single command in your terminal:

npx mcp-deep-research-server --install

That's it! It automatically detects your OS, writes the config to your claude_desktop_config.json, and configures the 8 research tools. Just restart Claude Desktop.

🛠️ Manual / Other Clients Setup

Run via npx:

npx mcp-deep-research-server

Or build from source:

git clone https://github.com/SECRET4422/mcp-deep-research-server.git
cd mcp-deep-research-server
npm install
npm run build

🤖 Agent Skill (Claude Code / Antigravity / Agent Frameworks)

This repository includes an open-standard Agent Skill that teaches AI coding assistants when and how to autonomously run deep research workflows.

  • Import via skill directory: skills/deep-research/

  • Spec compliant with Claude Code, Cursor, and Google Antigravity agents.

Test (smoke)

npm run test:mcp
# or
npm run inspect # opens http://localhost:6274

Manually tested:

[search] Dehradun → 3 results ✓
[deep_research] What is MCP → 3 sources in 2.1s ✓
tools/list → 8 tools ✓

Add to Claude Desktop

Edit config:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "deep-research": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-deep-research-server/build/index.js"]
    }
  }
}

Restart Claude Desktop.

Add to Cursor / Windsurf / VS Code

.cursor/mcp.json or mcp.json:

{
  "mcpServers": {
    "deep-research": {
      "command": "node",
      "args": ["./build/index.js"],
      "cwd": "/path/to/mcp-deep-research-server"
    }
  }
}

Example Prompts

Deep Research:

Use deep_research to research "Best LLM fine-tuning in 2026, depth deep" then compare LoRA vs QLoRA

Fact Check:

Fact check claim: "Bun is faster than Node" using fact_check_claim

Compare:

Compare these 3 URLs about MCP architecture focusing on security: https://modelcontextprotocol.io/docs/getting-started/intro https://www.anthropic.com/news/model-context-protocol https://en.wikipedia.org/wiki/Model_Context_Protocol

See examples/claude-example.md for more.

Data Storage

All in ~/.mcp-deep-research/:

  • memory.json — persistent findings

  • history.json — audit log (100 max)

  • cache/ — reserved

No DB, no external calls except search/scrape.

Pro Features in v1.1.0

  • ✅ Logo + pro README + badges

  • ✅ GitHub Actions CI (Node 18/20/22) + Release workflow

  • ✅ Issue templates, PR template, CONTRIBUTING, SECURITY

  • ✅ .editorconfig, smoke test script

  • ✅ Optimized package.json for npm publishing

  • ✅ CHANGELOG tracked

Roadmap

  • Tavily / Brave API fallback if keys present

  • PDF parsing via pdf-parse

  • YouTube transcript tool

  • Vector search on memory (embeddings)

  • SSRF protection — private/internal IP blocklist for scrape_page

  • Smithery registry

Dev

npm run dev     # tsx watch
npm run build
npm run lint

Guidelines in CONTRIBUTING.md.

License

MIT © Prabhakar Pal — See LICENSE

Built with 🧠 for Dehradun → World. Not a generic MCP.

Available Tools

8 tools
compare_sourcesD

Compare 2-5 URLs

ParametersJSON Schema
NameRequiredDescriptionDefault
urlsYes
focusNo

TDQS

D1.8/5.0
Behavior1/5

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

No annotations are provided, and the description fails to disclose any behavioral traits (e.g., whether it is read-only, requires authentication, or modifies data). The description does not add context beyond the bare action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely short (6 words) but lacks essential information. It is under-specified rather than appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters, no output schema, and no annotations, the description fails to explain what the output is, how to use 'focus', or any expected behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain the 'focus' parameter or provide meaning beyond the input schema. With 0% schema description coverage, the description must compensate but fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Compare 2-5 URLs' provides a verb and resource, but is vague about what aspect is compared (e.g., content, reliability). It does not distinguish from sibling tools like 'extract_insights' or 'fact_check_claim'.

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 guidance on when to use this tool versus alternatives. No when-not-to-use or exclusions provided.

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

deep_researchC

Orchestrated deep research: search + parallel scrape + synthesize

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNostandard
topicYes
maxSourcesNo
saveMemoryNo

TDQS

C2.8/5.0
Behavior3/5

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

The description discloses that the tool performs multiple operations (search, parallel scrape, synthesize), which is helpful. However, it does not mention potential side effects like saving to memory (implied by the saveMemory parameter) or behavioral traits such as longer execution time or cost implications. Without annotations, the description carries the burden for transparency, and it only partially meets it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at 13 words. While brevity is valued, this description is underspecified and missing critical information. It is not front-loaded effectively because it does not immediately clarify what the tool does in a self-contained way (e.g., 'research' is vague without context). It earns a 3 because it is not verbose but is too short to be fully useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (orchestrated multi-step process, 4 parameters, no output schema), the description is severely incomplete. It does not explain what 'synthesize' means (e.g., returns a summary, a report, or structured data), the significance of saveMemory, the behavior of depth levels, or how maxSources interacts with scraped pages. A complete description would require at least a few sentences to cover these aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has four parameters with no descriptions (schema description coverage 0%). The description does not explain any of the parameters (topic, depth, maxSources, saveMemory) beyond what is obvious from their names. For example, it does not clarify what each depth level ('quick', 'standard', 'deep') entails or how maxSources affects the search and scrape process. The description adds no semantic value to 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 performs 'deep research' through orchestrated search, parallel scraping, and synthesis. This distinguishes it from sibling tools like search_web (search only) and scrape_page (scrape only), as it combines multiple steps into one call.

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 provides no explicit guidance on when to use this tool versus alternatives. For example, it doesn't specify when deep_research is preferred over manually chaining search_web and scrape_page, or when not to use it (e.g., if only a single source is needed). The implied usage is for comprehensive research, but no exclusions or alternatives are mentioned.

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

extract_insightsD

Extract insights

ParametersJSON Schema
NameRequiredDescriptionDefault
goalNo
contentYes

TDQS

D1/5.0
Behavior1/5

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

The description lacks any behavioral details beyond the tool name. It does not disclose side effects, output format, or any traits that an AI agent needs to know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is too short to be useful; two words constitute under-specification rather than conciseness. It fails to earn its place without meaningful content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters, no output schema, and no annotations, the description is completely inadequate. It provides no context for successful invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning to the parameters (goal, content). The agent is left with no clue about their purpose or format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Extract insights' is a tautology of the tool name, providing no additional clarity about what insights are extracted or from what source. It fails to distinguish the tool from siblings like deep_research or fact_check_claim.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided. The description gives no indication of when to use this tool versus alternatives like compare_sources or search_web.

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

fact_check_claimD

Fact-check claim

ParametersJSON Schema
NameRequiredDescriptionDefault
claimYes
searchDepthNo

TDQS

D1.5/5.0
Behavior1/5

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

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It says nothing about mutability, authentication, rate limits, or output format, leaving the agent blind to key usage constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While very short, the description is under-specified and fails to include essential information, making it inadequate rather than concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two parameters, no annotations, and no output schema, the description is starkly incomplete. It does not explain return values, parameter usage, or any contextual information needed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the tool description does not explain any parameters. The meaning of 'claim' and 'searchDepth' is left entirely to the agent's intuition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Fact-check claim' is a tautology of the tool name, repeating it without adding specificity or distinguishing it from sibling tools like compare_sources or deep_research.

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 provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.

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

memory_saveC

Save to persistent memory

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYes
tagsNo
valueYes
sourceNo

TDQS

C2.3/5.0
Behavior2/5

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

No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states 'Save to persistent memory' without mentioning whether saving overwrites, appends, or handles duplicates, nor any side effects like potential mutation of existing data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is brief but under-specifies the tool's functionality. True conciseness would retain essential detail; here, the description is too terse to be adequately informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and no annotations, the description is wholly inadequate. It fails to explain what 'persistent memory' is, how the tool relates to siblings, or what happens after saving.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must explain parameters. It does not clarify the purpose of 'key', 'tags', 'value', or 'source', leaving the agent to infer their meaning from names alone.

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 'Save to persistent memory' uses a specific verb (save) and resource (persistent memory), clearly indicating the action. However, it lacks differentiation from sibling tools like memory_search or compare_sources, though the verb itself implies a distinct operation.

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 guidance on when to use this tool versus alternatives (e.g., memory_search). The description provides no context for appropriate usage, prerequisites, or exclusions.

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

scrape_pageC

Scrape URL to markdown

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
formatNomarkdown
extractMainOnlyNo

TDQS

C2.5/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states the core action. It does not disclose behavioral traits such as whether the scraping is destructive, network requirements, rate limits, or error handling, leaving much to assumption.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While extremely concise (one sentence), it lacks structure such as bullet points or sections. The brevity results in under-specification for a tool with three parameters, making it more insufficient than appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, no parameter explanations, and no annotations, the description is incomplete. It does not cover return values, error scenarios, or behavioral nuances needed for an AI agent to use the tool correctly.

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%, yet the description adds no meaning to the three parameters (url, format, extractMainOnly). It hints at output format via 'markdown' but does not explain any parameter semantics, failing to compensate for low coverage.

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 'Scrape URL to markdown' clearly states the verb (scrape) and resource (URL), and specifies the output format (markdown). It implicitly distinguishes from siblings like search_web and fact_check_claim, though no explicit differentiation is made.

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 guidance is provided on when to use this tool versus alternatives, prerequisites, or scenarios where it should be avoided. The description is purely functional with no usage context.

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

search_webC

Search web via DuckDuckGo HTML (no API key)

ParametersJSON Schema
NameRequiredDescriptionDefault
countNo
queryYesSearch query
timeFilterNoall

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description carries the burden of disclosing behaviors. It only mentions 'no API key,' omitting important traits like rate limits, result format, or limitations of scraping DuckDuckGo HTML. This is insufficient for an agent to understand behavioral implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence) and front-loaded, but it sacrifices completeness. Every word earns its place, but the overall structure is minimal, lacking the substance needed for a 3-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain return format, pagination, error handling, or limitations, leaving critical gaps for an AI agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (only 'query' has a description). The description adds no information about 'count' or 'timeFilter' parameters, failing to compensate for the schema's lack of detail. The agent must infer parameter usage from names alone.

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 action (Search web) and the specific source (DuckDuckGo HTML) plus a key feature (no API key required). However, it does not differentiate from sibling tools like deep_research or fact_check_claim, missing explicit guidance on when this tool is appropriate.

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 provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction for tool selection.

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. 8 tool updatesv1.3.1
    • Changedcompare_sources2 fields changed
      • removedInput schema / properties / focus / description
        Removed value: -"What aspect to focus comparison on? e.g. 'pricing', 'effectiveness'"
      • removedInput schema / properties / urls / description
        Removed value: -"2-5 URLs to compare"
    • Changeddeep_research4 fields changed
      • removedInput schema / properties / depth / description
        Removed value: -"quick=3 sources, standard=5, deep=8"
      • removedInput schema / properties / maxSources / description
        Removed value: -"Override number of sources (1-10)"
      • removedInput schema / properties / saveMemory / description
        Removed value: -"Save key findings to memory"
      • removedInput schema / properties / topic / description
        Removed value: -"Research topic/question"
    • Changedextract_insights2 fields changed
      • removedInput schema / properties / content / description
        Removed value: -"Content to analyze (scraped page text, article, etc)"
      • removedInput schema / properties / goal / description
        Removed value: -"What are you trying to extract? e.g. 'pricing for LLMs', 'side effects' - biases scoring"
    • Changedfact_check_claim2 fields changed
      • removedInput schema / properties / claim / description
        Removed value: -"Claim to fact-check, e.g. 'Dehradun is the capital of Uttarakhand'"
      • removedInput schema / properties / searchDepth / description
        Removed value: -"How many sources to check"
    • Changedmemory_save4 fields changed
      • removedInput schema / properties / key / description
        Removed value: -"Key/title, e.g. 'dehradun-capital-fact' or 'pricing-openai'"
      • removedInput schema / properties / source / description
        Removed value: -"Source URL or description"
      • removedInput schema / properties / tags / description
        Removed value: -"Tags for filtering"
      • removedInput schema / properties / value / description
        Removed value: -"Value/content to save"
    • Changedmemory_search3 fields changed
      • removedInput schema / properties / limit / description
        Removed value: -"Max results"
      • removedInput schema / properties / query / description
        Removed value: -"Search query in keys/values/tags"
      • removedInput schema / properties / tags / description
        Removed value: -"Filter by tags (any match)"
    • Changedscrape_page3 fields changed
      • removedInput schema / properties / extractMainOnly / description
        Removed value: -"Try to extract main article content only, removing nav/footer"
      • removedInput schema / properties / format / description
        Removed value: -"Output format"
      • removedInput schema / properties / url / description
        Removed value: -"URL to scrape"
    • Changedsearch_web3 fields changed
      • removedInput schema / properties / count / description
        Removed value: -"Number of results (1-10)"
      • changedInput schema / properties / query / description
        Previous value: -"Search query, be specific"New value: +"Search query"
      • removedInput schema / properties / timeFilter / description
        Removed value: -"Time filter appended to query if needed"
  2. 8 tool updatesv1.2.0
    • First observedcompare_sources
    • First observeddeep_research
    • First observedextract_insights
    • First observedfact_check_claim
    • First observedmemory_save
    • First observedmemory_search
    • First observedscrape_page
    • First observedsearch_web
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.6/5.0

Scored across 8 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: compare_sources compares URLs, deep_research orchestrates multi-step research, extract_insights extracts insights, fact_check_claim verifies claims, memory_save/search handle persistent memory, scrape_page fetches web content, and search_web performs web searches. No overlap.

Naming Consistency5/5

All tool names follow a consistent snake_case convention with a clear verb_noun pattern (e.g., compare_sources, memory_save, scrape_page). The naming is predictable and easy to understand.

Tool Count5/5

8 tools are well-scoped for a deep research server. The count is sufficient to cover core capabilities (search, scrape, compare, fact-check, memory) without being overwhelming.

Completeness5/5

The tool set covers the full research lifecycle: searching, scraping, comparing sources, extracting insights, fact-checking, and saving/retrieving memory. There are no obvious gaps for the intended purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches