Wenjia Home-Fix Diagnosis MCP Server

cause_ranking

Ranks likely causes for a home-appliance symptom by likelihood, DIY difficulty, and feasibility, helping you identify what to check first before repair steps.

Instructions

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

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": "cause_ranking"
  }
}

Input Schema

Name	Required	Description
`query`	No	可选：口语描述，省略 id 时用它定位
`symptom_id`	No	症状 id，如 not_cooling
`category_id`	No	品类 id，如 air_conditioner

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.7Nov 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and mostly discharges it: it defines the return shape, the likelihood vocabulary (最常见/常见/较常见/少见), and the deliberate omission of fix steps. It falls short of disclosing read-only behavior, error or empty-result handling, or what happens when all optional parameters are omitted.

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 scope and output shape are front-loaded in the first clause, followed by the ranking caveat. It is dense but every clause carries information; the closing warning about percentages is slightly repetitive with the earlier ranking description but still earns its place as an anti-misuse note.

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?

There is no output schema, so the description must describe the return value, and it does so concretely, including the enumeration of likelihood labels. For a simple three-optional-parameter read tool this is close to complete, missing only behavior when no locator parameter is supplied and how many causes are typically returned.

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 description coverage is 100%, so the three parameters are already fully documented, including the fallback ('省略 id 时用它定位'). The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 gives a precise verb+resource ('按可能性排好序的原因列表') along with the exact shape of each entry (likelihood bucket, effort, DIY feasibility) and an explicit scope exclusion ('不含修复步骤'). It implicitly distinguishes the tool from tree-wide retrieval and from a repair plan, so an agent can route here without inspecting siblings.

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 states the condition that selects this tool ('回答「大概是什么问题」用它') and names the alternative behavior it replaces ('比取整棵树省约 80% 上下文'). It also sets guardrails on interpretation (experience ranking, not statistical probability), which is exactly the when-and-how guidance an agent needs.

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

Deploy Server