Provides web search capabilities via DuckDuckGo to fetch real-time information, documentation, and technical snippets from the internet.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DevLens MCP Deep dive into current best practices for OAuth2 in Python apps"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The MCP Server I Built to Kill Alt-Tab. Clean, fast web context, right in your IDE.
Like most developers, I was sick of context-switching between VS Code and the browser for documentation. That was my core frustration. So, I built DevLens: an open-source MCP server because I was curious and wanted a custom solution that was more lightweight than existing tools.
The goal is simple: give your workspace AI (Copilot, Claude, etc.) web access that is structured and token-efficient. DevLens delivers twelve specialized tools via a three-layered architecture built for power and easy deployment.
The MCP (Model Context Protocol) is the standard that lets your AI assistant call external tools (web search, scraping) to act beyond its training data. It gives the AI real-world and real-time ..power.
DevLens's Role is to be the most efficient implementation for web research. DevLens handles the intelligence (Smart Orchestration) and formats the results into clean Markdown. This ensures your workspace AI receives the precise context it needs without the clutter or high token cost of raw HTML.
Related MCP server: Crawl4AI MCP Server
DevLens is built on two principles to solve context loss: Technical Composability and Token Efficiency.
The Problem Solved: No more useless switching between browser and editor. Your coding flow stays intact.
The Technical Edge: Our layered architecture uses simple primitives that combine powerfully. This means more precise and less costly workflows than existing "monolithic" solutions.
LLM Context Optimal: Our clean, token-optimized Markdown output is about 70% smaller than raw HTML. This is the secret for fast, accurate AI results in your chat.
Seamless IDE Integration: Designed to pair perfectly with VS Code Copilot and GitHub Copilot. Web research is injected directly into your editor.
Deployment Ready: Use it locally for your own work, or deploy it on a server to share with others.
Smart Orchestration — The system chooses the best tool sequence, automatically.
Zero Configuration — Install, run. Done.
Persona | Problem Solved (The Pain) | DevLens Solution (The Win) |
Nina, the Frontend Developer | Needs a quick fix (e.g., that one CORS config snippet) but hates opening 5 Stack Overflow tabs. | Uses suggest_workflow or search_web + summarize_page to get the validated code snippet instantly in chat. Flow maintained. |
Kenji, the Staff Engineer | Must compare three serverless vendors for an architecture decision. Needs a single, definitive data dump. | Uses deep_dive to fetch, aggregate, and analyze complex data concurrently. The LLM receives the full, pre-processed report. |
Sarah, the DevOps Specialist | Has to manually check third-party deployment guides every week for silent, breaking changes. | Uses monitor_changes to passively track content hashes on critical docs, sending an alert only when something actually changes. |
DevLens gives you 12 specialized tools—think of it like a camera bag of lenses. Pick one, or let the smart system auto-select:
Layer | Metaphor | Focus | Tools |
Primitives | Basic Lenses | Precision & Reliability | search_web, scrape_url, crawl_docs, summarize_page, extract_links |
Composed | Multi-Lens Systems | Convenience & Aggregation | deep_dive, compare_sources, find_related, monitor_changes |
Meta | Auto-Focus Intelligence | Guidance & Optimization | suggest_workflow, classify_research_intent, get_server_docs |
Python 3.12 or newer
uv package manager
# Clone the repository
git clone https://github.com/Y4NN777/devlens-mcp.git
cd devlens-mcp
# Install dependencies
uv sync
# Run the server (STDIO mode)
uv run python -m devlens.serverAdd this to claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Option 1: Using launch script (Recommended - Cross-Platform)
{
"mcpServers": {
"devlens": {
"command": "/absolute/path/to/devlens-mcp/launch_mcp.sh",
"args": []
}
}
}Option 2: Direct uv command
{
"mcpServers": {
"devlens": {
"command": "uv",
"args": ["run", "python", "-m", "devlens.server"],
"cwd": "/absolute/path/to/devlens-mcp"
}
}
}Create .vscode/mcp.json in your workspace:
{
"servers": {
"devlens": {
"command": "/absolute/path/to/devlens-mcp/launch_mcp.sh",
"args": []
}
}
}Note: The launch_mcp.sh script is cross-platform and automatically:
Detects your OS (Linux/macOS/Windows)
Locates uv installation (checks ~/.local/bin/uv, ~/.cargo/bin/uv, or system PATH)
Uses the correct Python from .venv (.venv/bin/python on Unix, .venv/Scripts/python.exe on Windows)
No manual configuration needed!
Use STDIO transport:
uv run python -m devlens.serverTest the server is working:
# Test basic functionality
uv run python -c "from devlens.server import mcp; print('DevLens server loaded successfully')"# Simple search
search_web("FastAPI tutorial", limit=5)
# Scrape with metadata
scrape_url("https://docs.python.org", include_metadata=True)
# Multi-source research
deep_dive("Python async best practices", depth=5, parallel=True)
# Compare perspectives
compare_sources("FastAPI vs Flask", ["url1", "url2"])# Let DevLens recommend the workflow
suggest_workflow("How to integrate payment API in Burkina Faso?")
# Returns:
# - Primary intent: quick_answer (50% confidence)
# - Workflow: [search_web(limit=3), scrape_url]
# - Suggested parameters optimized for intent
# - Fallback strategies if tools fail# Provide known URLs to skip search
context = ResearchContext(known_urls=["https://docs.stripe.com"])
suggest_workflow("Stripe payment integration guide", context)
# DevLens adapts:
# - Skips search (URLs already known)
# - Goes straight to crawl_docs or scrape_url
# - Optimizes parameters based on intentDevLens uses a simple, effective layered architecture—the smart bits guide the reliable bits.
Meta Layer (Intelligence) -> suggests workflows
Composed Layer (Convenience) -> combines primitives
Primitive Layer (Reliability) -> uses adapters
External Services (The Actual Internet)
Key Design Principles:
Composability — Tiny tools that handle huge tasks.
Intelligence at the Edges — Smart brain decides, reliable primitives execute.
Token Optimization — Maximum context, minimum token cost.
Fail Explicitly — No silent failures. We tell you exactly what broke.
Developer Velocity First — If it doesn't make you faster, we don't build it.
See ARCHITECTURE.md for the deep dive.
Layer | Library | Purpose | Framework |
MCP | fastmcp | MCP protocol implementation | |
Scraping | crawl4ai | JavaScript-enabled web scraping | |
Search | ddgs | DuckDuckGo search (no API key) | |
HTTP | httpx | Fallback HTTP client | |
Validation | pydantic | Input/output schemas |
Exponential backoff retry (because the internet is flaky)
Metadata extraction (+41% information density)
Smart filtering (skips all the login/signup/spam garbage)
Markdown conversion (clean text for the AI)
Content change detection via hashing
Parallel content fetching (3x faster)
Domain diversity filtering
Comparative analysis across sources
Progress tracking with success/failure reporting
7 research intent patterns (e.g., quick_answer, deep_research, comparison)
Dynamic workflow generation based on context
Parameter optimization (limits/depths automatically set for intent)
Fallback strategies when tools fail
LRU cache for insane speed (200 entries)
Tracks known URLs (no redundant searches)
Records failed tools (so the AI doesn't try the same thing twice)
Adapts workflows based on research state
Tool | Duration | Cost | Notes |
search_web | 1-2s | Low | DuckDuckGo API |
scrape_url | 2-5s | Low | Single page fetch |
crawl_docs | 10-60s | High | Multi-page crawling (big tasks take big time) |
deep_dive | 5-15s | Medium | Parallel scraping |
suggest_workflow | <50ms | Minimal | LRU cached |
REQUIREMENTS.md — Project scope and technical requirements
ARCHITECTURE.md — Software architecture and design philosophy
TOOLS.md — Comprehensive tool reference with examples
The DevLens Philosophy: Make the hard stuff simple and fast.
Composability — Build with small, focused primitives that combine
Intelligence at the Edges — Smart brain, reliable hands
Developer Velocity — If setup takes more than 5 minutes, it's too much.
Token Economy — Efficiency is currency.
Fail Explicitly — We tell you when something breaks.
Context-Aware — It remembers what happened.
Read the full philosophy in ARCHITECTURE.md.
Query: "What is FastAPI?"
-> suggest_workflow thinks: quick_answer (50%)
-> Workflow: search_web(limit=3) -> scrape_url
-> Result: Fast answer from the top source. Done.
Query: "Comprehensive guide to mobile payments in Africa"
-> suggest_workflow thinks: deep_research (75%)
-> Workflow: search_web(limit=10) -> deep_dive(depth=10, parallel=true)
-> Result: Multi-source aggregated report, ready for planning.
Query: "FastAPI documentation" + known_url
-> suggest_workflow thinks: documentation (80%)
-> Workflow: crawl_docs(max_pages=25) (skips search, goes straight to the docs)
-> Result: Complete documentation with TOC.
Query: "Compare FastAPI vs Flask"
-> suggest_workflow thinks: comparison (65%)
-> Workflow: search_web -> scrape_url (parallel) -> compare_sources
-> Result: Side-by-side analysis ready for your pull request.
Contributions welcome! Keep it simple:
Add, don't modify — New tools over changing existing ones
Document why — Explain your design choices
Test everything — All tools must have validation tests
Keep it simple — Clarity over cleverness
MIT License - See LICENSE for details.
Name origin: DevLens = A developer's lens for viewing the web. Different tools are different lenses (wide-angle, macro, zoom), with smart auto-focus (orchestration) that picks the right lens automatically.
Get documentation about the WebDocx MCP server.
Provides guidance on server capabilities, tool usage, workflows, and best practices.
Args: topic: Documentation topic - 'overview', 'tools', 'workflows', 'orchestration', or 'examples'
Returns: Formatted documentation for the requested topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | overview |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 that the tool returns formatted documentation, which is useful behavioral context. However, it doesn't mention other traits like whether it's read-only, has rate limits, requires authentication, or error handling, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief elaboration and clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, parameter semantics, and return type. However, with no annotations, it could benefit from more behavioral details (e.g., safety, performance) to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the 'topic' parameter with specific values ('overview', 'tools', 'workflows', 'orchestration', or 'examples'), which clarifies its purpose beyond the bare schema. Since there's only one parameter and the description covers it well, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get documentation', 'Provides guidance') and identifies the resource ('WebDocx MCP server'). It distinguishes from sibling tools by focusing on server documentation rather than research, comparison, crawling, or other operations listed in siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'server capabilities, tool usage, workflows, and best practices', suggesting it should be used for understanding the server's functionality. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., for learning vs. performing actions) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify the research intent of a query.
Analyzes a query to determine the user's research goal (quick answer, deep research, documentation, comparison, discovery, or monitoring). Returns confidence scores for each detected intent.
Args: query: Research question or task description.
Returns: Dictionary with primary and secondary intents with confidence scores.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'analyzes a query' and 'returns confidence scores,' but lacks details on how analysis works (e.g., model-based, rules-based), performance characteristics (e.g., latency, accuracy), or limitations (e.g., query length constraints, language support). It doesn't address potential side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with zero wasted words. It starts with a clear purpose statement, elaborates on functionality in a second sentence, and uses bullet-like sections for Args and Returns. Every sentence adds value, and the information is front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (intent classification), no annotations, and an output schema (implied by 'Returns' section), the description is reasonably complete. It covers purpose, input semantics, and output format. However, it lacks behavioral details (e.g., how classification works) and usage guidelines, which would enhance completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'query,' explaining it as a 'Research question or task description.' This clarifies the parameter's purpose beyond the schema's basic type definition (string). With 0% schema description coverage and only one parameter, the description adequately compensates by providing semantic information, though it could specify format expectations (e.g., natural language, keywords).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Classify the research intent of a query' and specifies it analyzes queries to determine research goals (quick answer, deep research, etc.). It distinguishes from siblings like tool_search_web or tool_summarize_page by focusing on intent classification rather than information retrieval or processing. However, it doesn't explicitly contrast with all siblings (e.g., tool_compare_sources might also involve intent analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, appropriate contexts, or compare with sibling tools like tool_deep_dive (which might handle 'deep research' intent) or tool_monitor_changes (which might handle 'monitoring' intent). Usage is implied only through the tool's name and purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare information across multiple sources.
Analyzes differences and similarities between sources.
Args: topic: Topic being compared. sources: List of URLs (2-5) to compare.
Returns: Comparison report with common topics and differences.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| sources | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analyzing differences and similarities but doesn't specify how the comparison is performed (e.g., text analysis, semantic similarity), what limitations exist (e.g., source accessibility, content types), or potential side effects (e.g., rate limits, data storage). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with four sentences that each add value: purpose statement, elaboration on analysis, parameter explanations, and return value description. It's front-loaded with the core functionality and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (comparison tool with 2 parameters, no annotations, but with an output schema), the description is minimally adequate. The output schema existence means return values don't need explanation, but the description still lacks details on behavioral traits (e.g., how comparison works, error handling) and usage context. It covers basics but leaves gaps for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'topic' is described as 'Topic being compared,' and 'sources' as 'List of URLs (2-5) to compare,' including a cardinality constraint (2-5 URLs). This clarifies beyond the basic schema types (string, array of strings), though it doesn't detail format requirements (e.g., URL validation) or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare information across multiple sources' and 'Analyzes differences and similarities between sources.' This specifies the verb (compare/analyze) and resource (information across sources). However, it doesn't explicitly differentiate from sibling tools like tool_find_related or tool_monitor_changes, which might also involve comparison or analysis of sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With sibling tools like tool_find_related, tool_monitor_changes, and tool_search_web that might overlap in functionality, there's no indication of specific contexts, prerequisites, or exclusions for using tool_compare_sources. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawl multi-page documentation.
Follows same-domain links to build combined docs.
Args: root_url: Starting URL. max_pages: Max pages to crawl (1-20, default 5).
Returns: Combined Markdown with table of contents.
| Name | Required | Description | Default |
|---|---|---|---|
| root_url | Yes | ||
| max_pages | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: it crawls same-domain links, combines content into Markdown with a table of contents, and has a max pages limit. However, it lacks details on rate limits, error handling, authentication needs, or content processing constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by brief behavioral notes and clear parameter/return sections. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (crawling and combining docs), no annotations, and an output schema (implied by 'Returns'), the description is mostly complete. It covers purpose, behavior, parameters, and returns, but could include more on limitations or prerequisites for a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for both parameters: root_url as the 'starting URL' and max_pages with its range (1-20) and default (5). This goes beyond the bare schema, though it could elaborate on URL format or crawling depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('crawl', 'follows', 'build') and resources ('multi-page documentation', 'same-domain links', 'combined docs'), distinguishing it from siblings like tool_scrape_url (single URL) or tool_extract_links (link extraction without content combination).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for building comprehensive documentation from linked pages on the same domain, but does not explicitly state when not to use it or name alternatives like tool_scrape_url for single pages or tool_search_web for broader searches. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research a topic from multiple sources.
Searches and scrapes multiple pages to build a report.
Args: topic: Topic to research. depth: Number of sources (1-10, default 3).
Returns: Aggregated research report.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| depth | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'searches and scrapes multiple pages' and 'builds a report,' which gives some context, but lacks details on permissions, rate limits, error handling, or what 'scrapes' entails (e.g., potential blocking or ethical considerations). For a tool with no annotations, this is insufficient to fully understand its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a high-level purpose followed by details. Sentences are efficient, with no wasted words. However, the structure could be slightly improved by integrating the 'Args' and 'Returns' sections more seamlessly into the flow, but it remains clear and concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (research and scraping from multiple sources), no annotations, and an output schema exists (indicating returns are documented elsewhere), the description is moderately complete. It covers the basic operation and parameters but lacks depth on behavioral aspects and usage context. With an output schema, it doesn't need to explain return values, but more guidance on when to use it would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'topic: Topic to research' and 'depth: Number of sources (1-10, default 3),' which clarifies the parameters beyond the bare schema. However, it doesn't provide examples, constraints beyond the range, or details on how 'depth' affects the research process, leaving some gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Research a topic from multiple sources' and 'Searches and scrapes multiple pages to build a report.' It specifies the verb (research/search/scrape) and resource (multiple sources/pages). However, it doesn't explicitly differentiate from siblings like tool_search_web or tool_scrape_url, which appear to handle similar operations individually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for aggregated research, but it doesn't specify scenarios, prerequisites, or exclusions compared to siblings such as tool_search_web (for searching) or tool_summarize_page (for summarizing). This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract all links from a page.
Useful for discovering navigation structure and resources.
Args: url: URL to extract links from. filter_external: Only return same-domain links (default True).
Returns: Organized list of internal and external links.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| filter_external | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool extracts links and organizes them, but lacks details on permissions, rate limits, error handling, or whether it follows redirects. For a web tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with zero waste. It starts with the core purpose, adds a usage tip, details parameters with explanations, and specifies the return value—all in a few sentences that are front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is fairly complete. It covers purpose, usage, parameters, and return values. However, with no annotations, it could benefit from more behavioral details like error cases or performance notes, though the output schema reduces the need to explain return formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains that 'url' is the 'URL to extract links from' and 'filter_external' controls whether to 'Only return same-domain links (default True).' This fully compensates for the schema's lack of descriptions, making parameter purposes clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract all links from a page.' It specifies the verb ('extract') and resource ('links from a page'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'tool_scrape_url' or 'tool_crawl_docs', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Useful for discovering navigation structure and resources.' This implies when to use it but doesn't explicitly state when not to use it or mention alternatives among sibling tools. For example, it doesn't clarify if this is for static extraction vs. dynamic crawling compared to 'tool_crawl_docs'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a page has changed.
Tracks content modifications over time.
Args: url: URL to monitor. previous_hash: Previous content hash to compare against.
Returns: Change detection report with content hash.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| previous_hash | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions tracking content modifications and returning a change detection report, but fails to detail critical traits such as rate limits, authentication needs, error handling (e.g., for invalid URLs), or how the hash is computed. This leaves gaps in understanding the tool's operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first ('Check if a page has changed'), followed by additional context and parameter details. Every sentence adds value without redundancy, and the structure is clear and efficient, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose, parameters, and return value, and the output schema likely details the report structure, reducing the need to explain returns. However, it lacks behavioral details like error cases or performance constraints, leaving some gaps in full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% schema description coverage. It explains that 'url' is for monitoring and 'previous_hash' is for comparison against previous content, clarifying their roles. However, it does not specify format details (e.g., URL validation, hash algorithm) or the implication of 'previous_hash' being null, so it compensates well but not fully for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if a page has changed' and 'Tracks content modifications over time.' It specifies the verb ('check', 'tracks') and resource ('page', 'content'), making the function evident. However, it does not explicitly differentiate this tool from siblings like 'tool_scrape_url' or 'tool_crawl_docs', which might also involve page content, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It lacks context on prerequisites (e.g., needing a previous hash for comparison), exclusions, or comparisons to sibling tools like 'tool_scrape_url' for content extraction or 'tool_compare_sources' for multi-source analysis. Usage is implied only through the function, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape content from a URL as Markdown.
Args: url: URL to scrape.
Returns: Markdown content with source attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that content is returned as Markdown with source attribution, which is useful, but lacks details on error handling, rate limits, authentication needs, or whether it's read-only or destructive. This leaves significant gaps for a tool that interacts with external URLs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, with a clear opening sentence followed by brief sections for args and returns. Every sentence adds value without redundancy, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interacting with external URLs) and the presence of an output schema (which likely covers return values), the description is moderately complete. It covers the core purpose and output format but lacks behavioral details like error handling or limitations, which are important for such a tool. The output schema reduces the need to explain returns, but more context is still warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% coverage. It explains that the 'url' parameter is for scraping content, and the schema only defines it as a string type. However, it does not specify URL format constraints or examples, so it doesn't fully compensate for the low schema coverage, but provides essential semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('scrape') and resource ('content from a URL'), and distinguishes it from siblings like 'tool_extract_links' or 'tool_search_web' by focusing on content extraction as Markdown. It explicitly mentions the output format and attribution, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention scenarios where it's preferred over siblings like 'tool_crawl_docs' for documentation or 'tool_search_web' for broader searches, nor does it specify prerequisites or exclusions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web using DuckDuckGo.
Args: query: Search query string. limit: Maximum results (1-20, default 5).
Returns: List of results with title, url, snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions the search engine (DuckDuckGo) and return format, but lacks details on behavioral traits such as rate limits, authentication needs, error handling, or whether it's a read-only operation. For a web search tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by structured sections for args and returns. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and an output schema (implied by 'Returns'), the description is mostly complete. It covers purpose, parameters, and return values, but lacks behavioral context and usage guidelines. The output schema reduces the need to explain returns in detail, but gaps in other areas prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'query' as a 'Search query string' and 'limit' with its range (1-20) and default (5), which aren't in the schema. However, it doesn't cover all potential semantics like query formatting or result ordering, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search the web using DuckDuckGo.' It specifies the verb ('Search') and resource ('the web'), and mentions the search engine. However, it doesn't explicitly differentiate from sibling tools like 'tool_find_related' or 'tool_monitor_changes,' which might also involve web searching, so it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With siblings like 'tool_find_related,' 'tool_deep_dive,' and 'tool_scrape_url,' there's no indication of context, prerequisites, or exclusions. It only describes what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest optimal research workflow for a query.
Analyzes the query and recommends the best tools and workflow to answer it. Uses smart intent classification and dynamic workflow generation.
Args: query: Research question or task description. known_urls: Optional list of already known URLs (default None).
Returns: Dictionary with intent, workflow steps, and suggested parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| known_urls | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'smart intent classification and dynamic workflow generation,' which hints at internal logic, but doesn't disclose critical traits like whether it's read-only (likely, but not stated), performance characteristics, rate limits, authentication needs, or error behavior. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the core purpose, followed by elaboration and a clear Args/Returns section. Every sentence adds value—explaining functionality, parameters, and output—with zero waste. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema description coverage, but an output schema exists, the description is moderately complete. It covers purpose, parameters, and return values at a high level, but lacks usage guidelines and detailed behavioral context. The output schema likely documents the return structure, so the description doesn't need to explain that deeply, but overall it's adequate with clear gaps for a tool in a crowded sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context: 'query: Research question or task description' and 'known_urls: Optional list of already known URLs (default None).' This clarifies the purpose of each parameter beyond their schema types (string and array), though it doesn't detail format constraints or examples. With 2 parameters and no schema descriptions, this provides adequate semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Suggest optimal research workflow for a query' and elaborates with 'Analyzes the query and recommends the best tools and workflow to answer it.' It specifies the verb (suggest/recommend) and resource (workflow/tools), but doesn't explicitly differentiate from sibling tools like tool_classify_research_intent or tool_deep_dive, which might have overlapping functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With siblings like tool_classify_research_intent, tool_search_web, and tool_deep_dive, there's no indication of whether this tool should be used first in a research process, when it's preferable to direct tool invocation, or what scenarios it's designed for. The lack of context leaves the agent guessing about its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quick overview of a page.
Extracts headings and key sections.
Args: url: URL to summarize.
Returns: Page summary with sections.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'quick overview' and 'extracts headings and key sections,' which implies a read-only, non-destructive operation, but doesn't specify details like rate limits, authentication needs, error handling, or what constitutes 'key sections.' For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a brief purpose statement, a bullet point for key actions, and clear sections for Args and Returns. Every sentence earns its place, with no redundant or verbose language, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (summarizing web pages), no annotations, and an output schema present, the description is minimally adequate. It covers the purpose and parameter semantics but lacks behavioral details and usage guidelines. The output schema likely handles return values, so the description's brief mention of 'Page summary with sections' is sufficient, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'url' by stating it's the 'URL to summarize,' which clarifies its purpose beyond the schema's type definition. With 0% schema description coverage and only one parameter, the description effectively compensates by providing essential semantics, making it clear what the input represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a quick overview of a page' and 'Extracts headings and key sections.' It specifies the verb ('get', 'extracts') and resource ('page', 'headings and key sections'), making it distinct from siblings like tool_scrape_url or tool_deep_dive. However, it doesn't explicitly differentiate from all siblings, such as tool_extract_links, which might also extract page content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention when to prefer it over siblings like tool_scrape_url (which might extract raw content) or tool_deep_dive (which might provide more detailed analysis). There's no context on prerequisites, exclusions, or typical use cases, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_server_docstool_classify_research_intenttool_compare_sourcestool_crawl_docstool_deep_divetool_extract_linkstool_find_relatedtool_monitor_changestool_scrape_urltool_search_webtool_suggest_workflowtool_summarize_pageScored across 12 tools
Most tools have distinct purposes, but some overlap exists. For example, tool_deep_dive and tool_crawl_docs both involve multi-page content aggregation, which could cause confusion. However, descriptions clarify that tool_deep_dive focuses on researching a topic across sources, while tool_crawl_docs is for building combined documentation from a single domain, helping to differentiate them.
The naming is mostly consistent with a 'tool_' prefix followed by a descriptive verb_noun pattern, such as tool_scrape_url and tool_summarize_page. However, get_server_docs deviates by using 'get_' instead of 'tool_', breaking the pattern. This minor inconsistency slightly reduces the overall naming uniformity.
With 12 tools, the count is well-scoped for a research and documentation server. Each tool appears to serve a specific function in the research workflow, from intent classification to content scraping and monitoring, without feeling excessive or insufficient for the domain's needs.
The tool set provides comprehensive coverage for research and documentation tasks. It includes intent classification, web searching, content scraping, summarization, comparison, change monitoring, and workflow suggestion, covering the full lifecycle from query analysis to report generation with no obvious gaps.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP server that gives your AI access to the source code and docs of all public github repos
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
