Wenjia Home-Fix Diagnosis MCP Server

diagnose

Turns a vague spoken household-appliance complaint into ranked likely symptoms and causes, plus safety stop points and CNY cost ranges before repair.

Instructions

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

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "diagnose"
  }
}

Input Schema

Name	Required	Description
`query`	No	可选：口语描述，省略 id 时用它定位
`symptom_id`	No
`category_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.3Nov 11, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full behavioral burden, and it does well: it discloses the output shape (3 candidate symptoms, causes ordered by prior probability, stop points, cost band) and the rationale for routing through it. It does not say what happens when the free-text query cannot be matched, or how symptom_id and category_id interact with query, which leaves some gaps for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded ("家里坏了，先用我"), then moves through the use case, the exclusion, and an example in a logical order with no filler. The "为什么不能跳过" paragraph is persuasive rather than purely operational, which is why it is not a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description still covers inputs, outputs, alternatives, and a worked example, which is nearly everything an agent needs. The remaining gaps are fallback behavior on an unrecognized query and the role of the two id parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33%, so the description should compensate, and it does so for query only: it says to pass the user's raw sentence verbatim and gives a concrete example. symptom_id and category_id are documented neither in the schema nor in the description, leaving two of the three parameters unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (diagnose a household device fault from a colloquial sentence) and enumerates the outputs: the top 3 symptoms, causes ranked by prior probability, stop points, and cost range. The worked example ("空调开一晚上房间还是不凉" → air_conditioner/not_cooling, 3 causes, first at 30%) pins down exactly what the tool returns, so an agent can distinguish it from find_symptom and fix_plan without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use it (the user describes the anomaly in everyday language and the fault class or cause is still unknown) and when not to use it (the user already named the category and symptom, in which case go straight to find_symptom or fix_plan). It also names the alternatives, states the condition that selects them, and gives a safety rationale for not skipping this step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server