一个 MCP 服务器，回答人们在家庭紧急情况下真正会问的问题：该给哪个工种打电话？
不是“帮我找个水管工。”而是更前面的问题——这真的是水管工的活儿吗？
我给水管工打了电话，他让我找电器维修工。我给电器维修工打了电话，他又让我找水管工。
这就是家庭紧急情况的常态，而且代价高昂。两次上门费，半天时间没了，水还在从天花板往下漏。这些工种各有专攻，但从外面看，它们的界限并不明显：天花板上的水渍，如果随天气变化就是屋顶工的事，如果随空调使用而变就是暖通空调技工的事，如果随楼上淋浴而变就是水管工的事。漏水停止后的水损修复则是第四个工种——减灾团队——而水管工会等你付了上门费之后才告诉你这一点。
这个服务器为助手提供了一张“分诊表”。用大白话描述问题，就能得到该给谁打电话、按什么顺序打、不要因为什么原因找他们、通常要花多少钱（附有注明日期的来源），以及——如果存在的话——24/7 调度电话。
内容来自 whodoicallfor.com 的公共 JSON API。无需身份验证、无需 API 密钥、无需配置。
Related MCP server: kickserv-mcp
Claude Code
claude mcp add whodoicallfor -- npx -y whodoicallfor-mcpCursor——添加到 ~/.cursor/mcp.json（或项目中的 .cursor/mcp.json）：
{
"mcpServers": {
"whodoicallfor": {
"command": "npx",
"args": ["-y", "whodoicallfor-mcp"]
}
}
}同样的配置也适用于 Claude Desktop（claude_desktop_config.json）、Windsurf、Zed，以及任何支持 stdio MCP 的客户端。
或者什么都不用运行。 这个服务器的托管实例已经上线：
https://whodoicallfor.com/api/mcp/它支持流式 HTTP，无状态，也不需要任何凭据。必须带末尾斜杠——不带斜杠的 URL 会返回 308 重定向，而一些 MCP 客户端不会在 POST 时跟随重定向。
claude mcp add --transport http whodoicallfor https://whodoicallfor.com/api/mcp/npx whodoicallfor-mcp # stdio (default)
npx whodoicallfor-mcp --http # streamable HTTP on http://localhost:3000/mcp
npx whodoicallfor-mcp --http 8080 # ...on a port you pick需要 Node 20.19 或更高版本。
这三个工具都是只读、幂等的，除了公共 API 之外不接触任何东西。
工具 | 参数 | 返回 |
|
| 最多 3 个按优先级排序的情景，最佳匹配排在最前 |
|
| 一个完整的情景 |
| — | 所有已发布的情景，附带规范 URL |
route_emergency输入大白话问题，输出排序后的情景。传入美国州代码或名称（"FL"、"Florida"），可将调度号码过滤为真正覆盖该州的线路。
输入
{ "problem": "water coming through my ceiling" }输出（节选——真实响应会携带三个匹配结果，包含完整的 costs、faq 和 sources 数组）
{
"matches": [
{
"title": "Water Leaking From the Ceiling — Who Do I Call?",
"category": "water",
"vertical": "water-damage",
"tldr": "What's directly above matters less than timing. Appears or worsens when it rains → roofer. Appears when the AC runs, or only in cooling season → HVAC condensate line. Neither, and it tracks water use upstairs → plumber. If water is still coming, shut the main valve, keep it clear of lights and outlets, and photograph everything before any repair. Renting? The landlord's emergency line comes before any of this.",
"who_to_call": [
{
"who": "Emergency plumber",
"when": "Water is actively dripping or flowing and you can't stop it at the source",
"not_for": "The leak has stopped — a plumber fixes pipes, not soaked drywall"
},
{
"who": "Roofer",
"when": "The stain appears or worsens when it rains and stays quiet in dry weather — usually failed flashing",
"not_for": "The stain tracks showers, washes, or flushes rather than the weather"
}
],
"costs": [
{
"item": "Water-damaged ceiling repair",
"range": "$200–$1,500",
"source": "Fixr",
"source_url": "https://www.fixr.com/costs/ceiling-repair"
}
],
"updated": "2026-08-12",
"url": "https://whodoicallfor.com/water/ceiling-leaking/",
"recommended_call": null,
"match_score": 12
}
],
"state": null
}not_for 字段正是帮你省下那笔冤枉上门费的部分。
当没有条目得分足够高时，你会得到一个空的 matches 数组，外加 note、类别索引，以及一个指向引导式分诊的链接——而不是一个自信但错误的答案。
get_scenario使用来自 route_emergency 或 list_scenarios 的 category 和 slug 获取一个完整的情景。
{ "category": "water", "slug": "ceiling-leaking" }返回相同的结构化对象，并附带 body_markdown（完整的逐步指南），前提是上游 API 提供了该字段。
list_scenarios无参数。返回 { site, count, scenarios[] }——所有已发布的情景，包含标题、描述、类别、slug、updated 日期、规范 URL 和 JSON URL。
route_emergency 通过你的问题与每个情景的四个字段之间的加权词元重叠来进行排名：标题 ×3、描述 ×2、tldr ×1，以及每个 who_to_call 步骤的 who/when ×1。词元会被转换为小写、去除标点、按停用词表过滤，并进行后缀折叠，因此 "leaking" 能匹配 "leak"，"pipes" 能匹配 "pipe"。得分低于 3 的条目会被丢弃；最多返回三个匹配结果。
tldr 和 who_to_call 位于每个页面的文档中，而不是索引中，因此第一次 route_emergency 调用会预热一个完整的内存缓存（有界并发，冷启动约 2 秒）。后续调用只需几毫秒。索引缓存 10 分钟，页面正文缓存一小时，因此服务器绝不会对站点造成压力。
这里没有模糊匹配，没有嵌入模型，除了 whodoicallfor.com 之外不会调用任何网络请求。它是一个小而确定的函数，你可以一口气读完：src/match.ts。
有两件事需要说明白。
recommended_call 条目是赞助内容。 它们是付费的按呼叫计费电话线路，每条都会在载荷中标记为 "sponsored": true。当一个情景带有这样的条目时，这就是网站背后的商业引擎。请将其视为带电话号码的广告，并以此向用户展示——数据中之所以有这个标记，正是为了让你这么做。
涉及生命安全的号码绝不会是赞助内容。 911、毒物控制中心和燃气公用事业应急热线完全不携带 recommended_call——服务端有一个硬性守卫，会为燃气情景以及任何没有商业垂直领域的情景移除该字段。如果有人闻到燃气味，答案是“马上出去，从外面给燃气公司打电话”，而没有人为此付过费。这个守卫不是政策偏好；它是上游代码，这个客户端无法覆盖它。
费用数据均引用自具名来源，并附有访问日期。在依据任何信息行动之前，请先核实。
npm install
npm run typecheck
npm run build
npm start # stdio
npm run start:http # http on :3000src/index.ts entry point: tool definitions, stdio + streamable HTTP transports
src/client.ts cached fetches against the public JSON endpoints
src/match.ts token-overlap ranking以美国为主。涵盖水患与洪涝、燃气与一氧化碳、电力与电气、供暖与制冷、家电、害虫与野生动物、门锁故障、汽车故障，以及房东和承包商纠纷等约 40 种情景。list_scenarios 始终反映实际发布的内容。
MIT © Daniel Widmonte
Fetch one situation in full: structured answer (who to call, costs, FAQ, sources) plus the complete step-by-step guide as markdown. Use category and slug values from route_emergency or list_scenarios.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Scenario slug, e.g. "ceiling-leaking" | |
| category | Yes | Category slug, e.g. "water" |
| Name | Required | Description |
|---|---|---|
| faq | No | |
| url | Yes | |
| tldr | Yes | |
| costs | No | |
| title | Yes | |
| sources | No | |
| updated | No | |
| category | Yes | |
| json_url | No | |
| vertical | No | |
| description | No | |
| who_to_call | No | |
| body_markdown | No | The full step-by-step guide as markdown |
| recommended_call | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds useful behavioral context by specifying the return format (structured answer + markdown guide). However, it doesn't mention performance characteristics or any dependencies on other tool calls if inputs are not from siblings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (two sentences) and front-loaded with the primary purpose. Every word adds value - the first sentence explains what is returned, the second tells where inputs come from. No redundant language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required string params, no enums, no nested objects), the presence of both input and output schemas, and comprehensive annotations, the description is complete. It clearly explains what the tool returns and how to properly call it, leaving no ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with 100% coverage (category and slug). Description adds value by stating they are 'category slug' and 'scenario slug' with examples like 'water' and 'ceiling-leaking', which clarifies the role of each field beyond their type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches one scenario with full details including structured answer, costs, FAQ, sources, and step-by-step guide as markdown. It distinguishes itself from siblings by specifying it retrieves a single scenario in full versus list_scenarios that lists multiple scenarios, and route_emergency which handles routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use category and slug values from route_emergency or list_scenarios, providing clear context on when to invoke this tool and where to get the required input parameters. This avoids confusion with its sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every published situation with title, category, slug, and canonical URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| site | Yes | |
| count | Yes | |
| scenarios | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it lists 'every published situation' (a scope detail) and the returned fields. However, it does not discuss pagination, ordering, or potential edge cases (e.g., empty list). The behavioral disclosure is adequate but minimal beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the verb 'List'. It conveys essential information (what is listed, what fields) without any extraneous content. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, an output schema exists), the description is nearly complete. It states the scope ('every published situation') and the fields included. Minor missing context includes ordering, default listing behavior, and what happens if no situations exist, but the presence of an output schema likely covers the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so there is nothing to document. The description does not need to add parameter semantics. The baseline for 0 parameters is 4, and the description meets this without requiring further elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('every published situation'), and specifies the output fields (title, category, slug, canonical URLs). This distinguishes it from siblings route_emergency (routing) and get_scenario (single scenario retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_scenario. It does not mention exclusions, prerequisites, or typical use cases. With sibling tools present, such context would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a home emergency described in plain words (e.g. "water coming through my ceiling"), returns the matching situation(s): who to call and in what order, first steps, typical costs, and a 24/7 dispatch phone number when one is available for the service vertical. Optionally pass a US state for region-aware dispatch numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional US state code or name, e.g. "FL" or "Florida" | |
| problem | Yes | The user's problem in plain words |
| Name | Required | Description |
|---|---|---|
| note | No | |
| state | No | US state code the numbers were matched against |
| matches | Yes | Matching situations, best first; empty when no confident match |
| categories | No | |
| triage_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so no contradiction. The description adds valuable behavioral context beyond annotations: it explains the return structure (who to call, order, first steps, costs, dispatch phone) and the conditional availability of 24/7 dispatch numbers. This is informative but does not cover edge cases like unrecognized problems or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earning its place. The first sentence front-loads the core functionality and output, while the second adds the optional parameter nuance. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, annotations present, output schema exists), the description covers the essential aspects: input format, output contents, and optional state usage. It does not explain output schema shape (but that is handled by output schema), nor does it address potential failures or multi-match cases. Almost complete for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions for both parameters. The description adds meaningful context for the 'state' parameter, noting it enables region-aware dispatch numbers, which the schema description does not convey. For 'problem', the description restates the schema's intent without adding detail, so the net improvement is moderate but solid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it routes a home emergency by returning matching situations with who to call, order, first steps, costs, and dispatch phone. The verb 'route' is specific and the scope is well-defined. It implicitly distinguishes from siblings (get_scenario, list_scenarios) by focusing on actionable routing rather than simply fetching or listing scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user describes a home emergency in plain words, and optionally when a US state is known. However, there is no explicit guidance on when not to use this tool versus alternatives (e.g., get_scenario might be preferred for retrieving a single scenario without dispatch info). The usage context is clear but lacks exclusions or differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_scenariolist_scenariosroute_emergencyScored across 3 tools
Each tool serves a distinct role: routing from a natural language description, retrieving full details for a specific scenario, and listing all available scenarios. There is no functional overlap.
All tools follow a consistent verb_noun pattern using snake_case: route_emergency, get_scenario, list_scenarios. The naming is predictable and intuitive.
With only three tools, the server is tightly scoped to the home emergency reference purpose. Each tool earns its place and the count feels neither sparse nor excessive.
The tool surface covers the full workflow: discover available scenarios (list_scenarios), route from a plain-language emergency (route_emergency), and drill into full details (get_scenario). No obvious gaps for the intended use case.
MCP server for generating rough-draft project plans from natural-language prompts.
Search 33,000+ MCP servers by job, see safety grades and reviews, and call them from one endpoint.
ProxyLink MCP server for finding and booking home service professionals
An MCP server that audits the fairness of construction and renovation estimates in Japan. Provides fair-price ranges, overcharge detection, and verifiable unit-cost data based on JCCDB (65,520 items across 402 categories, CC BY 4.0, DOI-backed).
