Skip to main content
Glama
Wenjia Home-Fix Diagnosis MCP Server

Wenjia Home-Fix Diagnosis MCP Server

Wenjia Home-Fix Diagnosis MCP Server · 问家家庭维修诊断

MCP License: MIT Data: CC BY 4.0

A Chinese home repair self-diagnosis engine exposed as an MCP server. 40 categories · 224 symptom decision trees · 920 ranked causes · 4,287 fix steps.

Zero dependencies (Python standard library only), read-only, no auth.

Install (stdio, one line)

Published on PyPI: https://pypi.org/project/wenjia-home-fix-mcp/

{
  "mcpServers": {
    "wenjia-home-fix": {
      "command": "uvx",
      "args": ["wenjia-home-fix-mcp"]
    }
  }
}

pip install wenjia-home-fix-mcp also works. Python >= 3.9, no other dependencies. The same file is kept at the repository root as mcp.json for catalog crawlers.

Related MCP server: mendlens

Ten tools, entry-first

You do not need to know any id. Pass the user's own words:

For

Tool

"空调不凉" "热水器打不着火" → which symptom is this

find_symptom

what to do, in what order, when to stop

fix_plan

everything a category covers

get_category

just the ranked causes

cause_ranking

just the price range

price_band

just the stop-before-DIY verdict

stop_check

full tree / clarify questions / keyword search

get_symptom / diagnose / search_symptoms

category_id and symptom_id accept Chinese names and common colloquial phrasings; when resolution fails the error message lists the valid ids so the agent can self-correct inside the same turn.

If your pip mirror has not synced yet (China)

Mainland mirrors sync PyPI with a delay. On a mirror-only network, uvx may report wenjia-home-fix-mcp was not found in the package registry. Two ways around it, both verified against 0.2.3:

# 1) point uv straight at the official index (mirror config is ignored)
uvx --default-index https://pypi.org/simple wenjia-home-fix-mcp

# 2) install the wheel directly from our host (no index involved)
pip install http://59.110.26.77/packages/wenjia_home_fix_mcp-0.2.3-py3-none-any.whl

What it does

Household failures are hard to describe and hard to fix. This server turns a vague complaint ("the radiator doesn't heat") into a structured diagnosis:

  1. 2 clarifying questions with options that each point to a diagnosis branch

  2. 4 likely causes ranked by prior probability (summing to 100%)

  3. Step-by-step fixes ordered by safety (gas valve / breaker always first)

  4. Parts prices and when to call a professional

Tools

Two families: atomic facts (cheap, for agents) and full trees (rich, for humans).

Tool

What it returns

Payload

cause_ranking

causes ranked most→least likely, each with likelihood (最常见 / 常见 / 较常见 / 少见) + difficulty + diy_ok

~520 chars

price_band

on-site repair price range in CNY

~410 chars

stop_check

risk class (gas / electric / height) + why you must stop before DIY

~420 chars

list_categories

40 categories with symptom counts

—

search_symptoms

keyword search across all 224 symptoms

—

get_symptom

full diagnosis tree: questions, causes, fixes, parts, prices

~2,350 chars

diagnose

ranked likely_causes + clarifying questions — best for AI assistants

—

Why atomic tools matter: an agent that only needs a number should not pay for a whole tree. Single-field calls cost 77–83% less context than get_symptom (measured on air_conditioner/not_cooling: 532 / 410 / 420 vs 2,350 chars). Every response carries v / dataset / as_of / src / lic / attr so an upstream agent can decide whether to trust and cite it.

What we deliberately do NOT sell

Step-by-step text — frontier models already write it well. What they cannot invent is prior probability, regional price, and the "stop now" judgment. Those three are what these tools exist for.

Live endpoint

POST https://wenjia.net/mcp        (after ICP filing; currently http://59.110.26.77/mcp)
Health: GET /mcp/health
Transport: Streamable HTTP, JSON-RPC 2.0, protocol 2025-06-18

Example

curl -s -X POST http://59.110.26.77/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"diagnose",
                 "arguments":{"category_id":"heating","symptom_id":"all_cold"}}}'

Run it locally

git clone <this repo>
cd <repo>
PORT=8765 python3 server.py
# POST http://127.0.0.1:8765/mcp

No pip install. Python 3.9+.

systemd / nginx

See deploy/wenjia-mcp.service for a hardened unit (read-only FS, www-data, auto-restart) and put nginx in front:

location = /mcp {
    proxy_pass http://127.0.0.1:8765;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
}

Data

data/mcp_data.json — the full dataset, regenerated from the source knowledge trees. Licensed CC BY 4.0: reuse freely, cite "问家 wenjia-home-fix-diagnosis".

Attribution line used across our content: 数据来自问家家庭维修诊断树(40 品类 224 症状,持续更新)

Honest limitations

  • prob_prior values are literature-and-experience priors, not repair-ticket statistics. Treat them as a ranking signal, never as precise frequencies.

  • Prices are 2026 Chinese market ranges (CNY); regional variation not modeled.

  • Coverage is urban household scenarios; rural self-built housing is out of scope.

  • Every symptom carries a see_pro field — when to stop and call a licensed technician. Do not strip it when redistributing.

License

  • Code: MIT (see LICENSE)

  • Data: CC BY 4.0 (see DATA-LICENSE.md)

Not affiliated with any appliance manufacturer. Brand names in the data appear only as references to public troubleshooting documentation.

Available Tools

10 tools
cause_rankingA

只回答「可能是哪几个原因、先查哪个」:按可能性排好序的原因列表,每条带 likelihood(最常见/常见/较常见/少见)、动手难度和自己做不做得来,不含修复步骤。回答「大概是什么问题」用它,比取整棵树省约 80% 上下文。不给百分比——这是经验排序,不是统计概率,别当成数据引用。

Inputs: query, symptom_id, category_id.

diagnoseA

家里坏了,先用我。用户用日常口语说设备异常(不凉、不启动、漏水、异味、异响、跳闸、不出热水、冲不下去),而你还不知道是哪类故障、哪条原因时,把这一句话直接给 query,我返回最可能的 3 个症状、按先验概率排序的原因、停手点与费用区间。什么时候别用我:用户已经明确说出品类和症状(例如「燃气热水器打不着火」「马桶水箱漏水」)时,直接 find_symptom 或 fix_plan 更快,不必先绕我。为什么不能跳过:不知道原因就凭常识给建议,正是家庭维修里最常出安全事故的地方。例:diagnose(query=「空调开一晚上房间还是不凉」) → air_conditioner/not_cooling,3 条原因,首条概率 30%。

Inputs: query, symptom_id, category_id.

find_symptomA

【精确入口】已知大致是哪类设备时用它:把用户的一句人话直接丢进来(「空调不凉」「热水器打不着火」「马桶堵了」),返回候选症状与相关度打分,不需要先知道 category_id。不知道是哪类故障时先用 diagnose,别先用我。

Inputs: query (required), limit.

fix_planA

【解决方案】取某症状的分步方案:原因按可能性从高到低排(第一条就是最可能的,默认给全部,通常 4-5 条),每条带全部动作步骤、需要的配件、安全提示、什么时候必须停手找持牌技师。每条原因只给强弱档位(最常见/常见/较常见/少见)不给百分比——这是经验排序不是统计概率。回答「我该怎么修、最可能是什么、先做哪一步」用它。要省 token 时才传 max_causes / max_steps 调小。

Inputs: query, max_steps, max_causes, symptom_id, +1 more.

get_categoryA

取某品类的全部症状清单(每个症状一句话摘要)。用于从品类入口展开,或确认「这个品类管哪些故障」。

Inputs: category, category_id.

get_symptomA

取单个症状的完整诊断树:澄清问题、全部原因与修复步骤、配件、停手边界。内容最全但约占 2,350 字符,只在需要整棵树时用。

Inputs: query, symptom_id, category_id.

list_categoriesA

列出问家家庭维修诊断知识库的全部品类(含品类名、症状数、更新日期)。共 40 品类 / 224 症状,含空调、洗衣机、燃气热水器、电路、上下水、门窗墙面等。

Inputs: no named parameters.

price_bandA

取某症状的上门维修价格区间(人民币元)。只回答问题「修这个大概多少钱」。

Inputs: query, symptom_id, category_id.

search_symptomsA

按关键词搜索症状(跨品类,带相关度打分),返回匹配的症状 id 与标题。不确定该用哪个 id 时用它,或用 find_symptom 直接给一句口语。

Inputs: query (required), limit, category_id.

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,停手点=不要碰金属外壳,先断总闸再联系电工。

Inputs: query, symptom_id, category_id.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.7/5.0

    Scored across 10 tools

    Disambiguation3/5

    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.

    Naming Consistency3/5

    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.

    Tool Count4/5

    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.

    Completeness4/5

    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.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • F
      license
      Not graded
      quality
      D
      maintenance
      Enables users to diagnose home appliance errors and receive safety actions by identifying products from photos or error codes, using official manufacturer data.
      -
    • A
      license
      Not graded
      quality
      C
      maintenance
      Provides AI agents with manufacturer-sourced HVAC technical documentation, enabling error-code lookup, diagnostics, and guided troubleshooting with exact source citations.
      MIT