MCP Server for Binge-watch / MoonTV / LunaTV. 一个用于追剧/追番的MCP服务器,为AI提供搜索影视播放地址的能力,并支持在小米等安卓电视/投影仪上直接播放
This server has moderate definition quality with mixed results across tools. All 6 tools have names and descriptions present, but there are significant gaps in parameter descriptions, schema completeness, and output documentation. Tool names are action-oriented (search, play, detail) which is good, but several parameters lack descriptions or have minimal ones. The server lacks error handling guidance, output schema documentation, and parameter validation rules. Most tools return unstructured YAML or raw API responses without field documentation. This is typical of community servers (C-D range).
在小米电视(投影仪/机顶盒)上播放远程影视URL。
获取电影、电视剧、综艺节目、动漫、番剧、短剧等节目的详情及播放地址
搜索电影、电视剧、综艺节目、动漫、番剧、短剧等。 你可以说: - 我想看《仙逆》最新一集 - 凡人修仙传更新到多少集了
在电视(投影仪/机顶盒)上播放远程影视URL,需要安装TvBox。
获取电影、电视剧、综艺节目、动漫、番剧、短剧等节目的详情及播放地址
搜索电影、电视剧、综艺节目、动漫、番剧、短剧等。如果超时可多重试几次。 当用户说以下内容时可通过本工具搜索资源: - 我想看《仙逆》最新一集 - 凡人修仙传更新到多少集了
Output schemas are not documented. Tools return YAML-serialized responses (moon_search, moon_detail, vods_search, vods_detail) or raw JSON dicts (mitv_play_media, tvbox_play_media) without field definitions. LLMs cannot plan downstream tool calls or extract required fields (e.g., 'id', 'source' from search results) without seeing the schema.
Parameter 'id' in moon_detail and vods_detail lacks meaningful description beyond 'ID'. Should explain: this is a string ID returned by search tools (moon_search or vods_search), not a numeric integer. Current description is too terse (under 50 chars).
Parameter 'source' in moon_detail and vods_detail has no documentation of valid values. Should be an enum or include examples. Current description says 'data source(source)' which is circular and unhelpful for LLM selection.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
No error handling guidance. Functions catch exceptions (aiohttp.ClientError, asyncio.TimeoutError, json.JSONDecodeError) but return raw error dicts or messages without recovery hints. E.g., mitv_play_media returns 'error: str(exc)', an LLM cannot infer whether to retry, check TV state, or give up.
moon_detail and vods_detail accept an 'episode' parameter defaulting to 0 (latest episode), but the description and behavior are unclear. Passing -1 fetches 'all episodes', undocumented. Parameter needs clearer documentation with examples: '0 for latest, -1 for all, or a positive integer for specific episode number.'
Search tools (vods_search, moon_search) return results as raw YAML without a 'total_count' or 'next_cursor' field for pagination. vods_search accepts a 'page' parameter but the response does not indicate whether there are more pages or how many total results exist. LLMs cannot determine when to stop paginating.
Result limiting not documented. Search tools may return unbounded results; no mention of result capping (e.g., 'limited to 20 results per call'). Returning 500+ items wastes context window and increases hallucination risk.
moon_detail and vods_detail responses include full 'episodes' dict (all episodes) in the raw output even when a single episode is requested, then strip it ('data.pop(episodes, None)'). This wastes tokens. Should only return the requested episode(s) in 'play_url' or 'episodes' field.
Duplicate functionality: vods_search + vods_detail and moon_search + moon_detail are nearly identical pairs. Descriptions and parameter names (id, source, episode) are identical. LLMs may conflate them. Clarify which service (moon/vods) is preferred or merge into a single pair with service selection.
Environment variable configuration (MITV_LOCAL_IP, MITV_LIST_CFG, MITV_API_KEY, MOON_BASE_URL, etc.) means some tools may not be registered if env vars are missing. Tools are conditionally added (e.g., 'if not MOON_BASE_URL: return'). No client feedback if a tool is unavailable. Client cannot know ahead of time which tools exist.