MCP server with multi-tier fallback chain for fetching web content as clean markdown
intercept-mcp has 4 tools with clear naming (verb_noun pattern: fetch, fetch_batch, search, research) and documented descriptions. However, critical gaps exist: input schemas are inferred from package.json comments and code rather than explicitly visible in schema definitions; parameter descriptions lack validation constraints (format, range, enum values); output schemas are not documented; no error handling guidance. The server attempts comprehensive web-fetching functionality but falls short of production-grade tool definition standards.
Fetch and convert a URL to clean markdown, with optional field extraction and table parsing
Fetch multiple URLs in parallel and return their markdown content
Search the web and fetch full content for top results, returning markdown articles
Search the web and return results as markdown, optionally fetching full content
No documented output schemas for any tool. LLMs cannot infer what fields will be returned, forcing them to guess about downstream field usage and breaking tool chaining.
Parameters lack format/range constraints in descriptions. 'maxTier' accepts 1-5 but description only says 'Maximum fetcher tier to use (1-5, default 5)', no enum definition in schema. LLMs can pass invalid integers.
Engine parameter ('brave', 'searxng', 'duckduckgo') documented as free-form string with inline examples rather than as an enum. LLMs may hallucinate other engines like 'google' or 'bing'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
No error handling guidance. Source code shows many failure paths (SSRF guard, cache failures, fetch errors, fetcher timeouts) but tool descriptions provide no recovery hints. LLMs receive raw errors with no guidance on what to do next.
Tool definitions inferred from comments in package.json and code snippets rather than explicitly registered with full schema. Code truncation at 'c' in src/server.ts prevents verification of actual tool registration. Per HARD SCORING RULES, this caps individual tool scores at 50 if schema not visible.
Fetch batch responses and result pagination not documented. Large bulk fetches could return unbounded lists; no mention of pagination, total count, or result limits.
Search results lack documentation of returned fields. LLMs cannot plan downstream fetch calls without knowing which fields (title, snippet, url, date) are present in each result.
CSS selectors and table extraction parameters ('selectors', 'tables') in fetch tool lack constraint documentation. What format does 'selectors' object accept? Flat keys? Nested paths? No guidance.