This MCP server routes US home, car, and civic emergencies to the right responder by returning ranked situations with who to call, what to do first, and typical costs.
route_emergency: Describe a problem (e.g., "water coming through my ceiling") and optionally a US state; get up to 3 ranked matches with who_to_call steps, costs, FAQs, sources, and a possible sponsored 24/7 dispatch number.
get_scenario: Fetch the full structured situation plus a complete step-by-step markdown guide using category and slug.
list_scenarios: List all published situations (around 60 US-focused) with titles, categories, slugs, and canonical URLs.
All tools are read-only, idempotent, and use only the free public whodoicallfor.com API (no account/API key).
State filtering removes dispatch numbers not covering a given US state; sponsored numbers are flagged as such.
No confident match yields an empty matches array with a note, category list, and triage URL instead of a wrong guess.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@whodoicallfor-mcp Water is dripping from my ceiling, who do I call?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A free Model Context Protocol server that routes US home, car, and civic emergencies to the right responder. Describe the problem in plain words and it returns who to call, in what order, what to do first, what not to call each responder for, and typical costs with dated sources. It wraps the public JSON API of whodoicallfor.com, needs no account, no API key, and no configuration, and is documented for agents at whodoicallfor.com/for-agents/. A hosted instance is live at https://whodoicallfor.com/api/mcp/ if you would rather not run anything.
I called a plumber, who told me to call an appliance tech. I called an appliance tech, who told me to call a plumber.
That is the normal experience of a household emergency, and it is expensive: two trip charges, half a day gone, and the water is still coming through the ceiling. The trades are specialized and their boundaries are invisible from the outside. A stain on your ceiling is a roofer if it tracks the weather, an HVAC tech if it tracks the air conditioning, and a plumber if it tracks the shower upstairs. Water damage after the leak stops is a fourth trade, a mitigation crew, and a plumber will tell you so after you have paid the callout. Civic problems have the same shape: a pothole is 911 if it is causing crashes right now, and city public works or 311 if it is not.
This server gives an assistant the routing table.
Related MCP server: ai-mcp-toolkit
There are two ways to use it. Both expose the same three tools.
A stateless Streamable HTTP instance runs at:
https://whodoicallfor.com/api/mcp/The trailing slash is required. The slashless URL (/api/mcp) answers with a 308 redirect, and several MCP clients do not follow redirects on POST, so they will appear to hang or fail with an empty response. Always configure the URL with the slash.
Claude Code
claude mcp add --transport http whodoicallfor https://whodoicallfor.com/api/mcp/Cursor (~/.cursor/mcp.json, or .cursor/mcp.json in a project)
{
"mcpServers": {
"whodoicallfor": {
"url": "https://whodoicallfor.com/api/mcp/"
}
}
}Any other client that speaks Streamable HTTP can use the same URL. A machine-readable descriptor lives at /.well-known/mcp.json.
The package is not yet published to npm, so install it from source. It requires Node 20.19 or newer.
git clone https://github.com/woodydaniel/whodoicallfor-mcp.git
cd whodoicallfor-mcp
npm install
npm run buildThe built entry point is dist/index.js. Point your client at it with an absolute path.
Claude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"whodoicallfor": {
"command": "node",
"args": ["/absolute/path/to/whodoicallfor-mcp/dist/index.js"]
}
}
}Claude Code
claude mcp add whodoicallfor -- node /absolute/path/to/whodoicallfor-mcp/dist/index.jsCursor, Windsurf, Zed, and anything else that speaks stdio MCP use the same command / args shape as the Claude Desktop snippet.
If you prefer a named command, npm link inside the repo registers the whodoicallfor-mcp binary on your PATH, and you can use that in place of node /absolute/path/.../dist/index.js.
node dist/index.js # stdio (default)
node dist/index.js --http # Streamable HTTP on http://localhost:3000/mcp
node dist/index.js --http 8080 # ...on a port you pick
node dist/index.js --version
node dist/index.js --helpThe local HTTP mode is stateless (a fresh server per request) and accepts POST only, the same as the hosted instance. Anything human-readable goes to stderr; stdout belongs to the protocol.
All three are read-only, idempotent, and call nothing but the public whodoicallfor.com API.
Tool | Arguments | Returns |
|
| Up to 3 ranked situations, best first |
|
| One situation in full, including the step-by-step guide |
| none | Every published situation with canonical URLs |
route_emergency(problem, state?)Plain-language problem in, ranked situations out. Pass a US state code or name ("FL", "Florida") and any dispatch number that does not cover that state is dropped rather than returned.
Input:
{ "problem": "water coming through my ceiling", "state": "FL" }Output, abridged. The real response carries up to three matches, each with full who_to_call, costs, faq, and sources arrays:
{
"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 → 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.",
"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"
}
],
"costs": [
{
"item": "Water-damaged ceiling repair",
"range": "$200–$1,500",
"source": "Fixr",
"source_url": "https://www.fixr.com/costs/ceiling-repair"
}
],
"updated": "2026-08-24",
"url": "https://whodoicallfor.com/water/ceiling-leaking/",
"json_url": "https://whodoicallfor.com/water/ceiling-leaking.json",
"recommended_call": null,
"match_score": 12
}
],
"state": "FL"
}The not_for field is the part that saves the wasted trip charge.
When nothing scores high enough you get an empty matches array plus a note, a list of categories with their URLs, and a triage_url pointing at the site's guided triage, rather than a confidently wrong answer.
get_scenario(category, slug)Fetches one situation in full. Use the category and slug values from route_emergency or list_scenarios.
Input:
{ "category": "civic", "slug": "call-811-before-you-dig" }Output, abridged. It is the same structured object as a route_emergency match, plus body_markdown, the complete step-by-step guide as markdown:
{
"title": "Call 811 Before You Dig — Who Do I Call?",
"category": "civic",
"vertical": null,
"tldr": "Before you dig anything — a fence post, deck footing, mailbox, tree, or garden bed — call 811 or file online at your state's One Call center, and utility locators come mark your buried gas, electric, water, and other lines for free, usually within about two to three business days.",
"who_to_call": [
{
"who": "811 / your state's One Call center (call 811 or file online)",
"when": "You're planning to dig — any project, however small — and want your buried utility lines marked before you break ground.",
"not_for": "You've already hit a line or you smell gas — that's an emergency for 911 and the utility, not a locate request"
}
],
"sources": [
{
"label": "811 Before You Dig: the free national Call Before You Dig service",
"url": "https://811beforeyoudig.com/",
"accessed": "2026-08-24"
}
],
"updated": "2026-08-24",
"url": "https://whodoicallfor.com/civic/call-811-before-you-dig/",
"recommended_call": null,
"body_markdown": "## Call 811 first — before any dig\n\nBefore you put a shovel, post-hole digger, auger, or stake into the ground, make one call: **811**. ..."
}An unknown category / slug pair returns a tool error that tells the caller to run list_scenarios for valid paths.
list_scenarios()No arguments. Returns every published situation with its title, description, category, slug, updated date, canonical page URL, and JSON URL.
Output, abridged:
{
"site": "https://whodoicallfor.com",
"count": 59,
"scenarios": [
{
"title": "Water Leaking From the Ceiling — Who Do I Call?",
"description": "Ceiling leaking? Rain-driven means a roofer; only when the AC runs means HVAC; tracks upstairs water use means a plumber. What to do before anyone arrives.",
"category": "water",
"slug": "ceiling-leaking",
"vertical": "water-damage",
"updated": "2026-08-24",
"url": "https://whodoicallfor.com/water/ceiling-leaking/",
"json_url": "https://whodoicallfor.com/water/ceiling-leaking.json"
}
]
}Some situations carry a recommended_call: a 24/7 dispatch line for the service vertical involved (an emergency plumber, a water-damage crew, and so on). Every recommended_call entry is sponsored and is marked as such in the payload:
"recommended_call": {
"label": "...",
"phone": "...",
"tel_url": "tel:...",
"coverage_states": ["FL", "TX"],
"network": "...",
"sponsored": true
}When you surface one of these numbers to a user, surface the sponsored label with it. The flag is in the data precisely so that you can.
Life-safety numbers are never sponsored. 911, poison control, and gas utility emergency lines are given in the who_to_call steps and in the guide text, and the pages that point to them carry no recommended_call at all. This server only passes through what the public API returns; it never adds a number, and when a state is supplied it removes any line whose coverage_states does not include that state.
Cost figures are cited to a named source with an access date. Verify anything you are about to act on.
All content is the public JSON twin of each page on whodoicallfor.com. Append .json to any guide URL (dropping the trailing slash) to get the structured version:
https://whodoicallfor.com/water/ceiling-leaking/ ← the page
https://whodoicallfor.com/water/ceiling-leaking.json ← the dataThe index of every published situation lives at /scenarios.json. The server fetches the index and the per-page documents and nothing else. The index is cached in memory for ten minutes and page bodies for an hour, with in-flight requests de-duplicated, so a burst of tool calls produces one request per resource rather than one per call.
route_emergency ranks by weighted token overlap between the problem and four fields of each situation: title ×3, description ×2, tldr ×1, and the who and when of each who_to_call step ×1. Tokens are lowercased, stripped of punctuation, filtered against a stopword list, and suffix-folded, so "leaking" matches "leak" and "pipes" matches "pipe". Anything scoring below 3 is discarded, and at most three matches come back.
tldr and who_to_call live on the per-page documents rather than the index, so the first route_emergency call warms a full in-memory cache (bounded concurrency, roughly two seconds cold). Subsequent calls take single-digit milliseconds.
There is no fuzzy matching, no embedding model, and no network call to anything but whodoicallfor.com. It is a small deterministic function you can read in one sitting: src/match.ts.
US-focused. Around 60 situations (59 as of September 2026) across water and flooding, house and contractor problems, pests, civic issues (811 before you dig, potholes and road hazards, noise complaints, code violations, trash and bulk pickup, trees blocking a road), power and electrical, animals and wildlife, appliances, car trouble, gas and carbon monoxide, heating and cooling, and lockouts. list_scenarios always reflects what is actually published.
npm install
npm run typecheck
npm run build
npm start # stdio
npm run start:http # Streamable 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 rankingSomething wrong in the content itself? That lives on the site, not in this repo: corrections and contact.
MIT © Daniel Widmonte. See LICENSE.
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. Dates show when Glama detected each change.
v1.0.0get_scenariolist_scenariosroute_emergencyEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for generating rough-draft project plans from natural-language prompts.
ProxyLink MCP server for finding and booking home service professionals
MCP server for US nursing facility search and ownership lookup (NursingHomeDatabase).
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/woodydaniel/whodoicallfor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
