Deep Research MCP Server

by SECRET4422

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.3.1
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.
Average 2/5 across 8 of 8 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on July 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

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.
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.
Behavior1/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 like read/write nature, authentication needs, or rate limits. It says nothing beyond the literal operation, offering no transparency.
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 at two words, the description is underspecified and lacks necessary information, making it inefficient for agent understanding. It prioritizes brevity over clarity.
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 3 parameters, no output schema, and no annotations, the description is woefully incomplete. It fails to convey return behavior, pagination, or any context needed for correct usage.
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 fails to explain the meaning or usage of any of the three parameters (tags, limit, query). It does not add value beyond the raw schema.
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 'Search memory' is a tautology that merely restates the tool name 'memory_search' without specifying the resource or scope. It fails to distinguish from sibling tools like search_web or memory_save.
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 such as deep_research or memory_save. No contexts, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.
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.

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:

[![mcp-deep-research-server MCP server](https://glama.ai/mcp/servers/SECRET4422/mcp-deep-research-server/badges/card.svg)](https://glama.ai/mcp/servers/SECRET4422/mcp-deep-research-server)

Score Badge

Copy to your README.md:

[![mcp-deep-research-server MCP server](https://glama.ai/mcp/servers/SECRET4422/mcp-deep-research-server/badges/score.svg)](https://glama.ai/mcp/servers/SECRET4422/mcp-deep-research-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/SECRET4422/mcp-deep-research-server'

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