An MCP server that provides tools for fetching web page content and searching the web using DuckDuckGo
Two tools with moderate naming and reasonable descriptions, but critical gaps in schema documentation and parameter definitions. Tool names follow verb_noun pattern (web-fetch, web-search), which is good. Descriptions are present (averaging ~180 chars for web-fetch and ~140 chars for web-search), placing them within the 10-1024 character baseline but not optimized for LLM consumption. However, input schemas visible in cmd/server/main.go show only minimal parameter documentation. The 'url' parameter in web-fetch has a description, and 'query' parameter in web-search has a description, but both lack type definitions in the source snippet provided. No output schemas are documented anywhere in the provided code. Error handling descriptions mention caching behavior and redirects but lack structured error guidance for LLM recovery. Security implications (web fetch / search) are not addressed in tool definitions.
Fetches content from a specified URL and returns the parsed content Functionality: - Takes a URL as input - Fetches the URL content and parses it - Returns the structured content including title, description, text, and links Usage notes: - If an MCP-provided web fetch tool is available, prefer using that tool instead - The URL must be a fully-formed valid URL - HTTP URLs will be automatically upgraded to HTTPS - This tool is read-only and does not modify any files - Includes a self-cleaning 15-minute cache for faster responses when repeatedly accessing the same URL - When a URL redirects to a different host, the tool will inform you and provide the redirect URL in a special format
Allows you to search the web and use the results to inform responses Functionality: - Provides up-to-date information for current events and recent data - Returns search result information formatted as search result blocks - Use this tool for accessing information beyond your knowledge cutoff - Searches are performed automatically within a single API call Usage notes: - Web search is only available in the US - Account for Today's date in environment (e.g., use 2025 when appropriate)
Input schemas lack type definitions and formal constraints. Parameters 'url' and 'query' are documented as strings but no enum, pattern, length, or format constraints are declared. LLMs cannot validate input bounds before calling.
No output schemas documented. Tool descriptions mention 'structured content' and 'search result blocks' but the actual return object structure (field names, types, nesting) is not specified. LLMs cannot plan downstream operations without knowing response shape.
Tool descriptions lack recovery guidance for error cases. web-fetch mentions redirects and caching but does not tell LLMs what to do if a URL is unreachable, returns 404, or times out. web-search does not specify error conditions or retry logic.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
No pagination parameters or documentation. web-search likely returns multiple results but there is no 'limit', 'offset', 'page', or 'next_cursor' parameter visible in the schema. Large result sets will bloat context without pagination controls.
Security implications not addressed in tool definitions. web-fetch and web-search can be used to access sensitive URLs or leak information via search queries. Tool descriptions do not declare what permissions are required or what users should be allowed to access.
Parameter descriptions are sparse. 'url' in web-fetch has a description ('The URL to fetch content from') but lacks format guidance (e.g., 'Must be a valid HTTP/HTTPS URL'). 'query' in web-search has a description but does not specify length limits, language, or regional constraints.