家庭の緊急時に人々が実際に抱く質問に答えるMCPサーバー: どの専門業者に電話すればいい?
「配管工を探して」ではありません。その前の質問 — これってそもそも配管工の仕事?
配管工に電話したら、家電修理業者に電話しろと言われた。家電修理業者に電話したら、配管工に電話しろと言われた。
それは家庭の緊急事態では普通のことで、しかも費用がかさむ。出張費が2回、半日が無駄になり、それでも天井から水は落ちてくる。職種は専門化されており、その境界は外からは見えない。天井の染みは、雨に伴って現れるなら屋根業者、エアコンの稼働に伴うならHVAC技術者、上の階のシャワーに伴うなら配管工の仕事だ。漏水が止まった後の水害は4つ目の職種 — 復旧作業員 — の担当であり、配管工は出張費を支払った後にそう教えてくれるだろう。
このサーバーはアシスタントに案内表を提供する。問題を平易な言葉で説明すると、誰に連絡すべきか、どの順序で、何の目的では連絡すべきでないか、日付入りのソース付きの一般的な費用、そしてあれば24時間365日の緊急連絡先が返ってくる。
コンテンツは 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/これはstreamable 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 pickNode 20.19以降が必要。
3つとも読み取り専用で、冪等であり、公開APIの外部には一切アクセスしない。
ツール | 引数 | 戻り値 |
|
| ランク付けされた最大3件の状況（最良が先） |
|
| 1件の状況を完全な形で |
| — | 公開されているすべての状況と正規URL |
route_emergency平易な言葉の問題を入力し、ランク付けされた状況を出力する。米国の州コードまたは州名（"FL"、"Florida"）を渡すと、緊急連絡先がその州を実際にカバーする番号に絞り込まれる。
入力
{ "problem": "water coming through my ceiling" }出力（要約版 — 実際のレスポンスには完全な costs・faq・sources 配列を持つ3件のマッチが含まれる）
{
"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_scenarioroute_emergency または list_scenarios の category と slug を使用して、1件の状況を完全に取得する。
{ "category": "water", "slug": "ceiling-leaking" }同じ構造化オブジェクトに加え、アップストリームAPIが提供する場合には body_markdown（完全なステップバイステップガイド）も返す。
list_scenarios引数なし。{ site, count, scenarios[] } を返す — 公開されているすべての状況について、タイトル、説明、カテゴリ、slug、updated 日付、正規URL、JSON URLが含まれる。
route_emergency は、あなたの問題と各状況の4つのフィールドとの間の重み付きトークン重複によってランク付けする。タイトル×3、説明×2、tldr×1、各 who_to_call ステップの who/when×1。トークンは小文字化され、句読点が除去され、ストップワードリストでフィルタリングされ、接尾辞が畳み込まれるため、"leaking" は "leak" に、"pipes" は "pipe" にマッチする。スコアが3未満のものは破棄され、戻ってくる最大は3件だ。
tldr と who_to_call はインデックスではなくページごとのドキュメントに存在するため、最初の route_emergency 呼び出しでメモリ内キャッシュ全体がウォームアップされる（同時実行数は制限付き、コールド時約2秒）。以降の呼び出しは一桁ミリ秒だ。インデックスは10分間、ページ本体は1時間キャッシュされるため、サイトに負荷をかけることはない。
ファジーマッチングも、埋め込みモデルも、whodoicallfor.com 以外へのネットワーク呼び出しもない。一気に読める小さな決定論的関数だ: src/match.ts。
はっきりさせておくべきことが2つある。
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).
