Universal content reader — expose content reading as MCP tools. Fetch, normalize, and digest content from 7+ platforms (YouTube, Bilibili, X/Twitter, WeChat, Xiaohongshu, Telegram, RSS, and generic web pages).
The x-reader server exposes 4 tools via FastMCP with functional but minimal descriptions. All tools are READ_ONLY with low risk. Tool naming is verb-forward and clear (read_url, read_batch, list_inbox, detect_platform). However, descriptions lack LLM-optimized detail about WHEN to use each tool, what distinguishes them from each other, and explicit parameter constraints. Input schemas are present for all tools but lack description text for parameters, particularly 'url' and 'urls' fields have minimal context about format validation, expected platforms, or failure modes. Output schemas are entirely undocumented: agents cannot see what fields read_url returns (title, content, url, source_type, platform metadata are mentioned in prose but not in a structured schema definition). No error handling guidance, no pagination info for list_inbox, no details on timeout behavior or partial failure modes for concurrent read_batch. STDIO transport caps the protocol readiness at 50 regardless of feature completeness.
Detect which platform a URL belongs to. Returns the platform name: youtube, bilibili, twitter, wechat, xhs, telegram, rss, or generic.
List all items in the content inbox. Returns JSON array of previously fetched content.
Read multiple URLs concurrently. Returns JSON array of results. Failed URLs are logged but don't block other results.
Read content from any URL and return structured result. Supports: YouTube, Bilibili, X/Twitter, WeChat, Xiaohongshu, Telegram, RSS, and any generic web page. Returns JSON with: title, content, url, source_type, platform metadata.
Output schemas completely undocumented. Descriptions mention return fields (title, content, url, source_type, platform metadata) in prose but provide no formal JSON Schema for what agents should expect. LLMs cannot plan downstream tool calls or extract fields reliably without structured output definitions.
Input parameter descriptions are minimal or absent. The 'url' parameter in read_url and detect_platform lacks guidance on valid URL formats, accepted platforms, what happens with invalid URLs, and whether relative URLs are supported. The 'urls' array in read_batch has no min/max length constraints, no guidance on concurrent limits, or failure tolerance.
No error handling guidance. Descriptions do not explain what happens when a URL is unreachable, invalid, or times out. For read_batch, the description states 'Failed URLs are logged but don't block other results' in prose, but there's no structured error response format or guidance for agents on how to interpret partial failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
read_batch lacks pagination/pagination guidance. No mention of max concurrent requests, result limits, or how to handle large batches. Agents cannot know if 100 URLs is acceptable or will cause timeouts/memory exhaustion.
list_inbox has no pagination, offset, or limit parameters. No guidance on max item count returned. If inbox grows large, returning all items could exhaust context windows.
Descriptions do not clarify tool selection rationale. Why choose read_url over read_batch for a single URL? When to call detect_platform before read_url? Agents lack guidance to disambiguate similar tools.