Thumbtack MCP is a read-only, anonymous server for searching local service professionals on Thumbtack and inspecting their public profiles, reviews, and credentials.
thumbtack_search_pros — search pros by service and US ZIP; returns up to 10 ranked results with rating, review count, hires, response time, and profile URL.
thumbtack_resolve_service — canonicalize loose service names to Thumbtack slugs (e.g., plumbing → plumbers).
thumbtack_get_pro — fetch a pro's profile: name, description, location, aggregate rating, credentials, and section inventory.
thumbtack_get_pro_reviews — read reviews on a pro's profile: stars, author, date, text.
thumbtack_graphql — issue arbitrary read-only GraphQL queries; mutations are refused.
thumbtack_healthcheck — verify Thumbtack's page and GraphQL surfaces are reachable and response shapes still match.
All read tools default to a compact response and can optionally return full data; no account or API key is needed.
Provides tools for searching local service pros and reading their profiles, ratings, reviews, and credentials on Thumbtack.
Click on "Deploy 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., "@thumbtack-mcp find plumbers in 94110"
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.
Unofficial Thumbtack MCP server — search local service pros, and read their profiles, ratings, reviews and credentials.
Read-only and anonymous. Thumbtack's consumer pages and its GraphQL endpoint answer without a login, so this server needs no account, no API key and no browser extension. It also cannot write: Thumbtack's write paths sit behind a reCAPTCHA-gated login that no server-side client can pass.
Thumbtack has no public consumer API. This server reads its server-rendered pages and anonymous GraphQL endpoint, and may break or violate their ToS. Developed and maintained by AI (Claude). Use at your own discretion.
// .mcp.json
{ "mcpServers": { "thumbtack": { "command": "npx", "args": ["-y", "@chrischall/thumbtack-mcp"] } } }No configuration — there are no environment variables.
Related MCP server: valet-parking-directory
Tool | What it does |
| Search pros by trade + US ZIP. Returns up to 10 with rating, review count, lifetime hires, mean response time, profile URL. |
| Canonicalise a loose service name ( |
| A pro's profile: name, description, location, aggregate rating, credentials, section inventory. |
| Reviews on a pro's profile — stars, author, date, text. |
| Escape hatch for arbitrary read-only GraphQL. Mutations refused. |
| Probes the page and GraphQL surfaces separately and reports the response shape still matches. |
Every read tool takes view: "compact" | "full", and compact is the
default. On thumbtack_search_pros that is a hand-written field projection;
on thumbtack_get_pro, thumbtack_get_pro_reviews and thumbtack_graphql it
strips image URLs, which needs no knowledge of the payload's shape. Pass
view: "full" for the untouched upstream records — they are large and mostly
tracking metadata, which is why the slim shape is what you get without asking.
thumbtack_resolve_service and thumbtack_healthcheck take no view: both
already answer with a handful of scalar fields, and a rung that cannot change
anything is worse than no parameter.
skills/thumbtack/ is a self-contained skill covering the same surface with
plain curl + jq — no server process. Use it for one-shot lookups and
scripts.
Three verified surfaces, all pinned in docs/THUMBTACK-API.md:
Search pages — results embedded in __NEXT_DATA__.
Profile pages — window.__APOLLO_STATE__ (a bare JS assignment, so it
needs balanced-brace extraction) plus schema.org JSON-LD.
GraphQL (app.thumbtack.com/graphql) — accepts ad-hoc anonymous
queries; introspection is disabled.
Two things that bite anyone reading these pages:
JSON-LD @type is the trade-specific subtype, not LocalBusiness — a
plumber's node is "@type":"Plumber". Match by shape, not by type name.
GraphQL returns HTTP 200 with an errors[] body. Status alone is never
sufficient.
Your own Thumbtack account (projects, messages, quotes) — the login is reCAPTCHA-gated, so there is no server-side password login.
The Partner Platform API (developers.thumbtack.com) — real and
documented, but gated behind partner credentials ("Request Access"). It is a
seller surface, not a consumer one.
npm install
npm run build
npm test # unit + server-boot smoke tests
npm run test:coverageCoverage is enforced at 100%.
MIT
Read a Thumbtack pro's profile: name, description, location, aggregate rating, plus credentials (background check, licences) and the section inventory. Takes a profile URL from thumbtack_search_pros.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full https://www.thumbtack.com/... pro profile URL. | |
| view | No | Response shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact returns the slim projection where one exists and strips image URLs elsewhere; "full" returns Thumbtack's whole records. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read operation, and the description reinforces that with 'Read'. It adds useful behavioral context by detailing exactly what profile data is returned, including credentials and section inventory, which goes beyond the annotation's bare safety signal.
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 with no filler. The first sentence names the action and return fields, and the second sentence ties the tool into the search workflow, so every sentence 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?
For a read-only profile fetch with one required and one optional parameter, the description is largely complete: it lists the output fields and the required input source. It does not explain 'section inventory' in detail or describe likely errors, but the schema covers the parameter behavior and no output schema is expected.
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%, so the schema fully documents the url and view parameters, including the compact/full distinction. The description adds one meaningful connection by stating the URL comes from thumbtack_search_pros, but it does not add detail about the view parameter; baseline 3 is appropriate.
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 states a specific action ('Read a Thumbtack pro's profile') and a clear resource, then enumerates the returned content: name, description, location, aggregate rating, credentials, and section inventory. It also distinguishes this tool from review- or search-related siblings by framing it as the profile reader fed by thumbtack_search_pros.
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 clear usage context by saying it takes a profile URL from thumbtack_search_pros, which tells an agent when in the workflow to call this tool. It does not explicitly list exclusions or name alternatives like thumbtack_get_pro_reviews, but the input source and profile focus imply the right selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the reviews embedded on a Thumbtack pro's profile page (star rating, author, date, text). Takes a profile URL from thumbtack_search_pros.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full https://www.thumbtack.com/... pro profile URL. | |
| view | No | Response shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact returns the slim projection where one exists and strips image URLs elsewhere; "full" returns Thumbtack's whole records. | |
| limit | No | Cap the number of reviews returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by specifying the exact data extracted (star rating, author, date, text) and noting the source is the profile page. This goes beyond the annotation without contradicting it, and provides useful context about the tool's behavior.
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?
Two sentences with no wasted words. The core purpose is stated first, followed by the required input source. The description is efficiently structured and front-loaded.
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?
The description covers what the tool does, what it returns, and where the input comes from. The schema fully documents all three parameters, annotations confirm read-only behavior, and there is no output schema requiring explanation. An agent has everything needed to invoke this correctly.
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 description coverage is 100%, so the baseline is 3. The description adds meaning to the 'url' parameter by specifying it should come from thumbtack_search_pros, which is not in the schema. It does not add detail for 'view' or 'limit' beyond the schema, but those are already fully documented. This modest addition justifies a 4.
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 states a specific verb ('Read') and a specific resource ('reviews embedded on a Thumbtack pro's profile page'), and enumerates the data returned (star rating, author, date, text). This clearly distinguishes it from sibling tools like thumbtack_get_pro (which likely returns profile info) and thumbtack_search_pros (which returns search results).
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 a clear context: it takes a profile URL from thumbtack_search_pros, implying it should be used after a search. However, it does not explicitly mention alternatives or exclusions (e.g., 'use this instead of thumbtack_get_pro for reviews'). The context is helpful but lacks explicit routing to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Escape hatch: issue an arbitrary read-only query against Thumbtack's anonymous GraphQL endpoint. Introspection is disabled upstream, so field names must come from a page's Apollo state. Mutations are refused.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Response shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact returns the slim projection where one exists and strips image URLs elsewhere; "full" returns Thumbtack's whole records. | |
| query | Yes | A GraphQL query document. Must not contain a mutation or subscription. | |
| variables | No | Variables for the query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint, so the description adds genuinely useful behavior beyond that: the endpoint is anonymous, introspection is disabled upstream, field names must come from a page's Apollo state, and mutations are refused. These are the critical operational constraints for issuing a raw query. It stops short of describing error shapes or rate limits, but the important behavior is well covered.
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?
Three short sentences: purpose is front-loaded, then the two most important caveats (introspection disabled, mutations refused). There is no filler and no repetition of schema content.
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?
For a raw GraphQL escape hatch, the description covers the endpoint, auth expectations (anonymous), field discovery limitation, and mutation prohibition. The only notable gap is that it does not describe the response envelope, but for an arbitrary query tool the result shape is inherently query-dependent, so this is a minor omission.
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 description coverage is 100%, and each parameter ('query', 'variables', 'view') already carries a detailed schema description, including the 'compact' vs 'full' response distinction. The description adds no parameter-specific information, so baseline 3 is appropriate.
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 states a specific verb ('issue'), a resource ('arbitrary read-only query against Thumbtack's anonymous GraphQL endpoint'), and frames itself as an 'escape hatch.' This clearly differentiates it from the wrapped sibling tools like thumbtack_get_pro and thumbtack_search_pros.
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?
'Escape hatch' signals that this tool is the fallback for queries not covered by higher-level wrappers, and 'arbitrary read-only query' sets a clear scope. It does not explicitly name alternatives or list when-not conditions, but the context is unambiguous enough for an agent to route to it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that Thumbtack's anonymous surface is reachable and still has the response shape this server expects. Reports the server version, the HTML page probe and the GraphQL probe separately.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and the title 'Healthcheck'. The description adds meaningful behavioral context: it probes the HTML page and GraphQL endpoints separately and reports server version plus each probe result. This goes beyond what the structured annotations convey.
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?
Two sentences with no wasted words. The core purpose is front-loaded, and the second sentence explains what the report contains, which is exactly the useful detail an agent needs.
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?
For a simple, parameterless healthcheck tool, this is complete: an agent knows what it does, what it checks, and what kind of output to expect. No output schema is present, but the description names the three reported components (server version, HTML probe, GraphQL probe) sufficiently.
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 tool has zero parameters and schema coverage is 100%, so the schema already fully documents the input surface. No parameter explanation is needed, and the baseline of 4 is appropriate for a parameterless tool.
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 states a specific verb ('check') and a precise resource ('Thumbtack's anonymous surface') plus what 'health' means here: reachability and expected response shape. It is also clearly distinct from the data-fetching siblings like thumbtack_search_pros and thumbtack_get_pro.
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 makes it clear that this tool is a diagnostic probe for reachability and response shape, so an agent can infer when to run it before relying on other Thumbtack tools. It does not explicitly state 'use this instead of X' or list exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a loose service name to the canonical Thumbtack slug by asking Thumbtack (it canonicalises via redirect, e.g. "plumbing" -> "plumbers"). Use before assuming a slug is right.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ZIP used to drive the lookup; does not affect the resolved slug. | 10001 |
| service | Yes | Trade or service name to canonicalise. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral detail: the tool asks Thumbtack externally and canonicalizes via redirect. It does not contradict 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?
Two sentences, front-loaded with the core action, a concrete example, and a one-line usage instruction. There is no filler 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?
For a simple two-parameter read-only resolver, the description covers what the tool does, how it behaves, when to use it, and implies the return value (the canonical slug). There is no output schema, but the purpose sentence is sufficient for invocation.
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 description coverage is 100%, so the schema already explains both parameters. The description's example illustrates the service parameter's semantics but does not add meaning beyond the structured schema.
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 specifies a clear verb ('Resolve'), a resource ('loose service name'), and the exact output ('canonical Thumbtack slug'), with a disambiguating example ('plumbing' -> 'plumbers'). This clearly differentiates it from the sibling tools, which search/get pros or perform GraphQL/health operations.
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?
It explicitly states when to use it: 'Use before assuming a slug is right.' It does not name alternatives or give exclusions, but the sibling tools are functionally distinct enough that no competing choice needs to be ruled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Thumbtack for local service pros by trade and US ZIP code. Returns up to 10 ranked pros with rating, review count, lifetime hires, mean response time and profile URL. Anonymous — no account needed.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 5-digit US ZIP code to search near. | |
| view | No | Response shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact returns the slim projection where one exists and strips image URLs elsewhere; "full" returns Thumbtack's whole records. | |
| limit | No | Cap the number of pros returned (upstream page size is 10). | |
| service | Yes | Trade or service, e.g. "house cleaning", "plumbing", "electrician". Loose names are canonicalised by Thumbtack. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds valuable context beyond that: it notes the operation is anonymous (no account needed) and specifies the return fields (rating, review count, lifetime hires, mean response time, profile URL). This goes beyond the annotation's safety profile without contradicting it.
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?
Two sentences, zero fluff, and the primary purpose is front-loaded. The anonymity note is a useful extra that doesn't dilute the message. Every sentence 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?
For a read-only search tool with four well-documented parameters and no output schema, the description is complete: it states the return fields, the result limit (up to 10), and the anonymous access model. Nothing essential for correct invocation is missing.
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 description coverage is 100%, so the schema already documents all four parameters clearly. The description reiterates the service and ZIP purpose but adds no new parameter-specific details beyond what the schema provides, which is the baseline for full coverage.
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 states a specific verb (Search), a resource (local service pros), and the scope (by trade and US ZIP code). It clearly distinguishes this from sibling tools like thumbtack_get_pro (single pro) or thumbtack_get_pro_reviews (reviews), making the purpose unambiguous.
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 when to use it (searching for pros by trade and ZIP), but it does not explicitly name alternatives or provide 'when-not-to-use' guidance. The context is clear, but no exclusions or sibling references are given, leaving usage to inference.
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.
v0.1.5thumbtack_get_pro1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"thumbtack_get_pro_reviews1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"thumbtack_graphql1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"thumbtack_healthcheck1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"thumbtack_resolve_service1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"thumbtack_search_pros1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v0.1.2thumbtack_get_pro1 field changedInput schema / properties / viewAdded value: +{
+ "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact returns the slim projection where one exists and strips image URLs elsewhere; \"full\" returns Thumbtack's whole records.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}thumbtack_get_pro_reviews1 field changedInput schema / properties / viewAdded value: +{
+ "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact returns the slim projection where one exists and strips image URLs elsewhere; \"full\" returns Thumbtack's whole records.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}thumbtack_graphql1 field changedInput schema / properties / viewAdded value: +{
+ "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact returns the slim projection where one exists and strips image URLs elsewhere; \"full\" returns Thumbtack's whole records.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}thumbtack_search_pros2 fields changedInput schema / properties / compactRemoved value: -{
- "default": false,
- "description": "Set true for slim summaries (name, rating, reviews, hires, response time, url). Default false returns the full upstream records, which are large and mostly tracking metadata.",
- "type": "boolean"
-}Input schema / properties / viewAdded value: +{
+ "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact returns the slim projection where one exists and strips image URLs elsewhere; \"full\" returns Thumbtack's whole records.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}v0.1.0thumbtack_get_prothumbtack_get_pro_reviewsthumbtack_graphqlthumbtack_healthcheckthumbtack_resolve_servicethumbtack_search_prosScored across 6 tools
Each tool serves a distinct purpose: resolving slugs, searching pros, reading profiles, reading reviews, an explicit GraphQL escape hatch, and health checking. There is no meaningful overlap or ambiguity between them.
All tools share a uniform thumbtack_ snake_case prefix and mostly follow a verb_noun pattern such as resolve_service, search_pros, get_pro, and get_pro_reviews. Minor deviations like thumbtack_healthcheck and thumbtack_graphql are still clear and predictable.
Six tools is a well-scoped size for a focused Thumbtack read-only server. Each tool covers a distinct step in the workflow without redundancy or bloat.
The core journey—resolve a service name, search pros by ZIP, view a pro's profile, and read their reviews—is fully supported. The GraphQL escape hatch and healthcheck cover edge cases and operational verification, leaving no obvious dead ends.
ProxyLink MCP server for finding and booking home service professionals
Search 33,000+ MCP servers by job, see safety grades and reviews, and call them from one endpoint.
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
Public MCP server for discovering open jobs. Search, filter, and get application links.
