MCP Web Tools
Enables web searching via DuckDuckGo to retrieve formatted search results including titles, URLs, and content snippets.
Click on "Install 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., "@MCP Web Toolssearch for 'how to build an MCP server' and fetch the first link"
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.
MCP Web Tools
A Model Context Protocol (MCP) server that provides web search and fetch capabilities for AI assistants like Claude Code.
This is useful when you want your code-generation tool to make web requests directly from your machine, rather than having those requests proxied through an external server you don't control. The MCP server runs locally on your host, so all web requests originate from your own network.
Features
web_search - Search the web using DuckDuckGo
Returns formatted results with titles, URLs, and snippets
Configurable result count and region
web_fetch - Fetch and extract content from web pages
Automatic HTML-to-text conversion (removes scripts, styles, navigation)
JSON response formatting
Configurable timeout
Related MCP server: DuckDuckGo MCP Server
Requirements
Python 3.13+
Installation
Quick Install (Recommended)
# Clone the repository
git clone <repo-url>
cd mcp-web-tools
# Install globally and configure Claude Code
make installThis will:
Install
mcp-web-toolsas a global executable viauv tool installRegister the MCP server with Claude Code using
claude mcp addThe executable will be available at
~/.local/bin/mcp-web-tools
Restart Claude Code after installation.
Manual Installation
# Install dependencies
uv sync
# Run directly from project
uv run mcp-web-toolsMakefile Targets
Target | Description |
| Install globally and configure Claude Code |
| Remove the global installation |
| Run tests with pytest |
| Remove build artifacts |
Claude Code Configuration
After running make install, you can verify the registration:
claude mcp listThe tools will be available in Claude Code as:
mcp__web-tools__web_searchmcp__web-tools__web_fetch
Manual Registration
If you prefer to register manually:
# User-wide (available in all projects)
claude mcp add --scope user web-tools mcp-web-tools
# Project-local (only current project)
claude mcp add --scope project web-tools mcp-web-toolsAlternative: Run from Project Directory
For development, you can register to run directly from the source:
claude mcp add --scope project web-tools uv run --directory /path/to/mcp-web-tools mcp-web-toolsTool Reference
web_search
Search the web using DuckDuckGo.
Parameters:
Parameter | Type | Required | Default | Description |
query | string | Yes | - | The search query |
max_results | integer | No | 10 | Maximum number of results |
region | string | No | "wt-wt" | Region for results (e.g., "us-en", "uk-en") |
Example response:
Search results for: python mcp server
1. Building MCP Servers in Python
URL: https://example.com/article
Learn how to build Model Context Protocol servers...
2. MCP Documentation
URL: https://modelcontextprotocol.io/docs
Official documentation for the Model Context Protocol...web_fetch
Fetch the content of a web page.
Parameters:
Parameter | Type | Required | Default | Description |
url | string | Yes | - | The URL to fetch |
timeout | integer | No | 30 | Request timeout in seconds |
Example response:
Content from https://example.com/article:
Building MCP Servers
This guide covers the basics of creating an MCP server...Development
Running Tests
make test
# Or directly
uv run pytest -vProject Structure
mcp-web-tools/
src/
mcp_web_tools/
__init__.py # Package metadata
server.py # MCP server implementation
tools.py # Tool implementations (search, fetch)
tests/
test_tools.py # Unit tests
pyproject.toml # Project configuration
Makefile # Install/uninstall automationDependencies
mcp - Model Context Protocol SDK
ddgs - DuckDuckGo Search API
httpx - Async HTTP client
lxml - HTML parsing (optional; falls back to regex-based extraction if not installed)
License
MIT
Available Tools
2 toolsweb_fetchB
Fetch the content of a web page. Returns the raw text content of the page, suitable for reading articles and documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch | |
| timeout | No | Request timeout in seconds (default: 30) |
TDQS
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 the tool returns 'raw text content' and hints at use cases, but fails to disclose critical traits like error handling (e.g., for invalid URLs), authentication needs, rate limits, or performance considerations. This leaves significant gaps for a tool that interacts with external web resources.
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, consisting of two concise sentences that directly state the tool's function and its return value. Every sentence earns its place by providing essential information 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 (fetching web content) and the absence of annotations and output schema, the description is partially complete. It covers the basic purpose and return type but lacks details on behavioral aspects, error handling, and output structure. This makes it adequate as a minimum viable description but with clear gaps in context.
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 input schema has 100% description coverage, clearly documenting both parameters ('url' and 'timeout'). The description adds no additional meaning beyond the schema, as it doesn't elaborate on parameter usage or constraints. According to the rules, with high schema coverage (>80%), the baseline is 3, which applies here since the description doesn't compensate with extra insights.
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 ('fetch') and resource ('content of a web page'), and distinguishes it from sibling 'web_search' by focusing on retrieving raw text from a given URL rather than searching. However, it doesn't explicitly differentiate from potential siblings like 'web_scrape' or 'web_metadata', keeping it at 4 instead of 5.
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 by stating it's 'suitable for reading articles and documentation,' suggesting contexts like content extraction. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'web_search' for broader queries) or any exclusions (e.g., not for dynamic pages), leaving usage somewhat inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchA
Search the web using DuckDuckGo. Returns a list of search results with titles, URLs, and snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query | |
| max_results | No | Maximum number of results (default: 10) | |
| region | No | Region for search results (e.g., 'us-en', 'uk-en') | wt-wt |
TDQS
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 search engine (DuckDuckGo) and return format, but fails to disclose critical traits like rate limits, authentication needs, error handling, or whether it's a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding its behavior and 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 and highly concise, consisting of two sentences that efficiently convey the tool's purpose and output. Every sentence earns its place by providing essential information without redundancy or unnecessary details, making it easy for an agent to quickly grasp the tool's function.
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 (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output but lacks details on behavioral traits, error cases, or integration with siblings. Without annotations or output schema, more context on limitations or usage patterns would improve completeness for agent decision-making.
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 100%, so the schema already documents all parameters (query, max_results, region) with descriptions and defaults. The description does not add any meaning beyond what the schema provides, such as examples or usage tips for parameters. Baseline 3 is appropriate as the schema handles the heavy lifting, but no extra value is added.
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 specific action ('Search the web using DuckDuckGo') and resource ('web'), distinguishing it from sibling 'web_fetch' which likely fetches specific URLs rather than performing searches. It explicitly mentions what it returns ('list of search results with titles, URLs, and snippets'), making the purpose unambiguous and distinct.
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 web searches but does not explicitly state when to use this tool versus the sibling 'web_fetch' or other alternatives. It provides basic context (searching the web) but lacks guidance on exclusions, prerequisites, or specific scenarios where this tool is preferred over others, leaving some ambiguity for the agent.
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. Dates show when Glama detected each change.
2 tool updates
v0.1.0- First observed
web_fetch - First observed
web_search
TDQS
The two tools have clearly distinct purposes: web_fetch retrieves the content of a specific URL, while web_search queries a search engine for results. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the task.
Both tools follow a consistent 'web_' prefix and snake_case naming pattern (web_fetch and web_search). This predictable structure enhances readability and usability for agents.
With only 2 tools, the server feels thin for a 'Web Tools' domain. While fetch and search are core operations, the scope suggests potential for more functionality (e.g., parsing, navigation, or analytics), making the toolset appear incomplete.
The tools cover basic web interaction (fetching content and searching), but there are notable gaps. For a web tools server, missing operations like navigating links, extracting specific data, or handling web forms limit its utility for complex agent workflows.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Fetch pages as markdown, search web and news, extract structured data. For AI agents.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables web searching through DuckDuckGo and fetching content from webpages. Provides search capabilities with configurable result limits and webpage content extraction for AI assistants.-
- AlicenseBqualityDmaintenanceEnables web search through DuckDuckGo and webpage content fetching with intelligent text extraction. Features built-in rate limiting and LLM-optimized result formatting for seamless integration with language models.2MIT
- AlicenseNot gradedqualityFmaintenanceEnables AI agents to search DuckDuckGo and fetch web content with human-assisted CAPTCHA handling, designed for local use where humans can intervene when bot detection occurs.7MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to search the web using DuckDuckGo and extract clean text content from websites for real-time research, with all processing happening locally for complete privacy.3MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/SayreBlades/mcp-web-tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server