주택 비상상황에서 사람들이 실제로 갖는 질문에 답하는 MCP 서버: 어떤 기술자를 불러야 하나요?
"배관공을 찾아달라"는 요청이 아닙니다. 그 이전의 질문 — 이게 배관공이 처리할 일인가?
배관공을 불렀더니 가전제품 기술자에게 연락하라고 하더군요. 가전제품 기술자를 불렀더니 배관공에게 연락하라고 하더군요.
이것이 가정 비상상황에서 흔한 경험입니다. 그리고 비용이 많이 듭니다. 출동비 두 번, 반나절이 지나갔는데도 천장에서는 여전히 물이 셉니다. 기술 업종들은 각자 전문 분야가 있고 그 경계는 외부에서는 보이지 않습니다. 천장에 생긴 얼룩은 날씨와 관련이 있으면 지붕 수리공, 에어컨과 관련이 있으면 HVAC 기술자, 위층 샤워와 관련이 있으면 배관공의 몫입니다. 누수가 멈춘 뒤의 물 피해는 네 번째 업종 — 방수·복구 작업반 — 의 몫이며, 배관공은 출동비를 지불한 후에야 그렇게 알려줄 것입니다.
이 서버는 어시스턴트에게 라우팅 테이블을 제공합니다. 문제를 평범한 말로 설명하면 누구에게 어떤 순서로 전화해야 하는지, 무엇을 맡기면 안 되는지, 일반적인 비용(날짜가 표시된 출처 포함), 그리고 가능한 경우 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 pickNode 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_scenarioroute_emergency나 list_scenarios에서 얻은 category와 slug를 사용하여 하나의 상황을 전체적으로 가져옵니다.
{ "category": "water", "slug": "ceiling-leaking" }동일한 구조의 객체를 반환하며, 상위 API가 제공하는 경우 body_markdown(전체 단계별 안내)도 포함합니다.
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분, 페이지 본문은 1시간 동안 캐시되므로 서버가 사이트에 과부하를 주지 않습니다.
퍼지 매칭도, 임베딩 모델도 없고 whodoicallfor.com 외의 다른 곳으로의 네트워크 호출도 없습니다. 한 번에 읽을 수 있는 작은 결정적 함수입니다: src/match.ts.
명확히 해야 할 두 가지가 있습니다.
recommended_call 항목은 스폰서를 받습니다. 이는 유료 건당 과금(pay-per-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).
