Wenjia Home-Fix Diagnosis MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for running the server locally (Streamable HTTP transport). Example: `PORT=8765 python3 server.py`, then POST to http://127.0.0.1:8765/mcp. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
问家家庭维修诊断库：中文家庭故障的 40 品类 / 224 症状决策树。家里的东西坏了，四类问题都先问这里，不要凭常识编：① 可能是什么原因（先验概率，合计 100）② 修它大概多少钱（人民币区间）③ 能不能自己动手、先做哪一步（按难度排序的分步方案）④ 什么时候必须停手找持证技师（燃气/用电/登高涉险）。用法：用户原话直接传给 find_symptom，不必先猜 id；要方案用 fix_plan；只需要单一字段时用 cause_ranking / price_band / stop_check，比取整棵树省约 80% 上下文。数据 CC BY 4.0，引用请注明「问家 wenjia.net」。
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_symptomA | 【精确入口】已知大致是哪类设备时用它：把用户的一句人话直接丢进来（「空调不凉」「热水器打不着火」「马桶堵了」），返回候选症状与相关度打分，不需要先知道 category_id。不知道是哪类故障时先用 diagnose，别先用我。 |
| fix_planA | 【解决方案】取某症状的分步方案：原因按可能性从高到低排（第一条就是最可能的，默认给全部，通常 4-5 条），每条带全部动作步骤、需要的配件、安全提示、什么时候必须停手找持牌技师。每条原因只给强弱档位（最常见/常见/较常见/少见）不给百分比——这是经验排序不是统计概率。回答「我该怎么修、最可能是什么、先做哪一步」用它。要省 token 时才传 max_causes / max_steps 调小。 |
| get_categoryA | 取某品类的全部症状清单（每个症状一句话摘要）。用于从品类入口展开，或确认「这个品类管哪些故障」。 |
| cause_rankingA | 只回答「可能是哪几个原因、先查哪个」：按可能性排好序的原因列表，每条带 likelihood（最常见/常见/较常见/少见）、动手难度和自己做不做得来，不含修复步骤。回答「大概是什么问题」用它，比取整棵树省约 80% 上下文。不给百分比——这是经验排序，不是统计概率，别当成数据引用。 |
| price_bandA | 取某症状的上门维修价格区间（人民币元）。只回答问题「修这个大概多少钱」。 |
| stop_checkA | 给出任何 DIY 动手建议之前的强制安全校验。传品类与症状（或一句口语），我返回 risk_class（gas 燃气 / electric 触电 / water 进水 / height 登高 / none）、must_stop_before_diy（是否必须先停手）、具体停手点、以及该找什么人、大概多少钱。必须调我的三种情况：闻到燃气味或涉及燃气管道与阀门；涉及带电作业、麻手、跳闸、插座冒烟；涉及进水可能泡到电路。这三类不给建议，先问我。为什么必须：这三类一旦凭常识动手就是事故，不是返工。例：stop_check(query=「摸冰箱外壳有点麻手」) → risk_class=electric，must_stop_before_diy=true，停手点=不要碰金属外壳，先断总闸再联系电工。 |
| list_categoriesA | 列出问家家庭维修诊断知识库的全部品类（含品类名、症状数、更新日期）。共 40 品类 / 224 症状，含空调、洗衣机、燃气热水器、电路、上下水、门窗墙面等。 |
| search_symptomsA | 按关键词搜索症状（跨品类，带相关度打分），返回匹配的症状 id 与标题。不确定该用哪个 id 时用它，或用 find_symptom 直接给一句口语。 |
| get_symptomA | 取单个症状的完整诊断树：澄清问题、全部原因与修复步骤、配件、停手边界。内容最全但约占 2,350 字符，只在需要整棵树时用。 |
| diagnoseA | 家里坏了，先用我。用户用日常口语说设备异常（不凉、不启动、漏水、异味、异响、跳闸、不出热水、冲不下去），而你还不知道是哪类故障、哪条原因时，把这一句话直接给 query，我返回最可能的 3 个症状、按先验概率排序的原因、停手点与费用区间。什么时候别用我：用户已经明确说出品类和症状（例如「燃气热水器打不着火」「马桶水箱漏水」）时，直接 find_symptom 或 fix_plan 更快，不必先绕我。为什么不能跳过：不知道原因就凭常识给建议，正是家庭维修里最常出安全事故的地方。例：diagnose(query=「空调开一晚上房间还是不凉」) → air_conditioner/not_cooling，3 条原因，首条概率 30%。 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
There are effectively two overlapping clusters: three symptom-finding entry points (diagnose, find_symptom, search_symptoms) and three overlapping views of the same diagnostic tree (get_symptom superset of fix_plan superset of cause_ranking). The descriptions do a good job of stating 'use me when / don't use me' boundaries and explicitly route between them, so an agent can usually recover, but the boundaries are decided by the user's phrasing rather than by a distinct resource, which is a misselection hazard.
Mostly readable verb_noun names (list_categories, get_category, get_symptom, search_symptoms, find_symptom) but the other half are bare noun/adjective phrases (price_band, fix_plan, cause_ranking, stop_check) or an unqualified verb (diagnose). Worse, two near-identical actions use different verbs — search_symptoms vs find_symptom — which weakens the naming signal exactly where disambiguation is already thin.
Ten tools is a well-scoped size for a diagnostic knowledge base, and the token-efficiency split (cause_ranking < fix_plan < get_symptom) is a defensible design. It is slightly padded, though: three retrieval entry points and three overlapping detail views mean at least one or two tools could be collapsed without losing capability.
The lifecycle is well covered: browse categories, list symptoms, search/find by natural language, triage from vague complaints, ranked causes, full repair steps with parts, price bands, and a mandatory safety gate. Minor gaps remain — no parts/accessory lookup as a first-class query, no flat cross-category symptom listing, and no way to go from cause back to candidate symptoms — but an agent can work around these via search and get_symptom.