"Ghost" matching MCP tools:

• hemmabo_booking_cancel

  HemmaBo Host Booking Engine

  Cancel a confirmed booking and process the Stripe refund per host cancellation policy. Use when the guest explicitly requests cancellation — if the guest wants new dates instead of ending the stay, use hemmabo_booking_reschedule instead. Do not use for pending/unpaid bookings — those expire automatically. To preview the applicable policy first, read cancellationPolicy from hemmabo_booking_status. Requires Authorization: Bearer token (MCP_API_KEY or OAuth). Destructive and idempotent: cancelling an already-cancelled booking returns the same status. Rate-limited per token. reservationId must be the booking UUID from hemmabo_booking_checkout or hemmabo_booking_create — not a propertyId; reason is optional free text forwarded to the host.

  Connector

• get_verified_stay_offer

  HemmaBo Host Booking Engine

  Fetch, verify, and render a live host-domain signed VRP stay offer for exact dates and guest count. Verifies Ed25519 JWS against domain JWKS. Call after hemmabo_search_properties returns a host domain, or after verify_vacation_rental_node confirms a domain from outside search, always before quoting final price or a booking link. Read-only: must not lock a quote, create a booking, collect guest details, or start checkout. Route booking only to the signed direct_booking_url; fall back to hemmabo_booking_negotiate/hemmabo_booking_checkout only when this call returns no signed offer, for a configured non-VRP deployment, after explicit user confirmation. The parameters work as a set: pass the same domain, checkIn, checkOut and guests the guest used at search; checkIn must be strictly before checkOut, and the resulting night count — not the dates themselves — drives the signed price and the host capacity check, so changing either date re-prices the offer. Always pass language as the guest's actual conversation language so the rendered widget matches the guest; it never affects the signed price or availability, only formatting.

  Connector

• search_places

  mcp

  Search the Byway atlas of typed places — waterfalls, hot springs, lighthouses, covered bridges, historic sites, beaches, peaks, rest areas and ghost towns. Locate by US state (which also needs a kind), by a point and radius, or by name; a name given alongside a locator narrows it. Every result links to the byway.world page for that place, and every place traces to its OpenStreetMap or Wikidata record. One limit, stated: ghost-town rows live in a separate Wikidata corpus that the point and name searches cannot read, so they are absent from a kind-less search. Reach them with state + kind, or with get_place. Asking for one any other way is refused, never answered empty.

  Connector

• hemmabo_search_properties

  HemmaBo Host Booking Engine

  Search available vacation rental properties by location and travel dates. Use when the user wants to find or browse places to stay. Discovery only — call get_verified_stay_offer with the host domain and same dates before the final answer so the client can render the verified stay offer widget; never quote a final price or booking link from search alone. Do NOT use when the user already has a propertyId or host domain. Returns propertyId, host domain, live availability, host-source pricing, and capacity. Parameters combine as one filter: give at least one of region or country to scope location, plus guests and the checkIn/checkOut range (checkIn strictly before checkOut) — results drop any property below the guest capacity or unavailable for that exact range.

  Connector

• hemmabo_booking_create

  HemmaBo Host Booking Engine

  Create a pending direct booking without online payment for configured non-VRP fallback deployments. Use only after explicit user confirmation, with a propertyId from search, and only when no signed VRP direct_booking_url is available. For signed VRP offers, route to the signed host-domain URL instead. Requires Authorization: Bearer token (MCP_API_KEY or OAuth). Writes a pending booking server-side; not idempotent — check hemmabo_booking_status before retrying on timeout. Rate-limited per token. The booking is identified by propertyId + the checkIn/checkOut range + guests; guestName and guestEmail are required for host confirmation, while guestPhone is optional for check-in coordination.

  Connector

• hemmabo_booking_negotiate

  HemmaBo Host Booking Engine

  Create a binding price quote that locks the price for 15 minutes for configured non-VRP fallback checkout deployments. Use only when no signed direct_booking_url is available and the user explicitly asks to lock a price. Never use this for search, availability, VRP offers, rendering a stay-offer widget, or verified-offer display — use get_verified_stay_offer instead. Requires Authorization: Bearer token (MCP_API_KEY or OAuth). Writes a short-lived quote snapshot server-side. Rate-limited per token. The parameters form one locked combination: the returned quoteId is honored by hemmabo_booking_checkout only for the identical propertyId + checkIn/checkOut + guests, and only until validUntil — changing any of them requires a new quote. Night count and guest count together select the price tier that gets locked, same as hemmabo_booking_quote.

  Connector

• hemmabo_booking_status

  HemmaBo Host Booking Engine

  Retrieve current status and full details of an existing booking by reservationId. Use to confirm checkout/create succeeded or before cancel/reschedule. Do NOT use for property discovery, availability, or pricing — use hemmabo_search_properties, hemmabo_search_availability, or hemmabo_booking_quote for those. Requires Authorization: Bearer token (MCP_API_KEY or OAuth). Read-only against the database — never writes, so it is safe to poll after a checkout timeout — but returns guest PII (name, email). Rate-limited per token. The only input is the reservationId returned by hemmabo_booking_checkout or hemmabo_booking_create — never the propertyId; without a reservationId there is no booking to look up yet.

  Connector

• hemmabo_booking_reschedule

  HemmaBo Host Booking Engine

  Reschedule a confirmed or pending booking to new dates with automatic repricing and Stripe charge/refund. Use when the guest wants to change dates on an existing booking — if the guest wants to end the stay entirely rather than move it, use hemmabo_booking_cancel instead. Do not use if cancelled or if a protocol compatibility client reports completed — check hemmabo_booking_status first. Requires Authorization: Bearer token (MCP_API_KEY or OAuth). Destructive write: the original dates are released back to the host calendar and the original price no longer applies — the booking keeps the same reservationId (updated in place, never recreated), and the price difference is charged or refunded via Stripe. Rate-limited per token. Identify the existing booking by reservationId, then give the new stay as newCheckIn/newCheckOut (newCheckIn strictly before newCheckOut); the new night count re-prices the stay exactly like a fresh quote.

  Connector

• hemmabo_host_readiness_check

  HemmaBo Host Booking Engine

  Read-only fit check for a vacation-rental host evaluating HemmaBo for their own booking website or booking engine. Use when the user is a host or property owner, not a guest booking a stay — guests searching for a place to stay should use hemmabo_search_properties instead. Returns a fit verdict, what the host gets, the setup inputs to prepare, and a safe onboarding next step. Does not create an account, buy a domain, configure Stripe, store host data, or provision a website. When the host is ready to start, follow up with hemmabo_host_onboarding_link. Every parameter is optional and additive — the more you pass (propertyType, country/region/city, domain, currentChannels, and the wants* booleans), the sharper the fit verdict; with none it returns a generic readiness summary.

  Connector

• jobs_analyze_external

  FoundRole — AI Job Search & Application Tracker MCP for Claude & ChatGPT

  Analyzes one job found outside FoundRole using the authenticated user's FoundRole profile and the same signals used for FoundRole jobs: resume match, missing skills, H-1B sponsorship history, E-Verify, ghost-job risk, posted compensation, and market salary estimates. Use tracker_add_external only when the user asks to save without analysis. The input represents the direct posting URL and all job content already available in the conversation. The five text identity fields are required; every structured fact field is optional, with a fact the source does not state simply omitted (or null). The optional `client_extraction` object carries evidence-backed skills, technology, benefits, bonuses, seniority, industry, management, clearance, visa, and remote-scope labels when source excerpts for them exist. FoundRole validates the evidence, stores the client extraction separately, derives missing deterministic facts, and reports which values were provided, derived, accepted, rejected, or remain unknown. The output includes `comparisonRef`; retain it exactly for a later jobs_compare call. The analysis is a decision aid, not a guarantee about sponsorship, legitimacy, compensation, or hiring outcome.

  Connector

• hemmabo_search_availability

  HemmaBo Host Booking Engine

  Check whether a specific property is available for the requested dates. Use this tool after the user has selected a property from hemmabo_search_properties and wants to confirm availability before getting a quote. Do NOT use for general browsing — use hemmabo_search_properties instead. Read-only: checking availability never places a hold or reserves dates. Returns available=true/false with conflict details and same-month alternative date windows when unavailable. Use the propertyId from search with the exact checkIn/checkOut range; omit guests to check dates only, or pass it to get host-source totals for that party size in the returned alternative windows.

  Connector

• hemmabo_booking_checkout

  HemmaBo Host Booking Engine

  Create a fallback non-VRP booking and return a host-configured Stripe checkout URL. Use only after explicit user confirmation when no signed VRP direct_booking_url is available. When get_verified_stay_offer returns a signed direct_booking_url, route the guest there instead; use hemmabo_booking_create instead when the deployment wants a pending booking recorded without collecting payment yet. Requires Authorization: Bearer token (MCP_API_KEY or OAuth). Creates a pending booking and Stripe session server-side; not idempotent — check hemmabo_booking_status before retrying. Rate-limited per token. Pass quoteId to honor a price locked by hemmabo_booking_negotiate for the same propertyId/dates/guests, or omit it to price fresh at checkout; paymentMode picks the Stripe flow, channel picks the pricing channel, and guestName/guestEmail identify the guest.

  Connector

• hemmabo_host_onboarding_link

  HemmaBo Host Booking Engine

  Return a safe HemmaBo onboarding handoff URL for a vacation-rental host who wants their own booking website or booking engine. Not for guests — a guest looking for a place to stay should use hemmabo_search_properties instead. Use after explaining the fit or when the host asks to start; if the host is still evaluating whether HemmaBo fits, run hemmabo_host_readiness_check first. This tool is read-only and does not create a HemmaBo account, buy a domain, configure Stripe, write to Supabase, or provision a booking site. It returns the URL, what the host gets, and what the host should prepare. All parameters are optional and only enrich the returned onboarding URL — propertyName, country/region/city, domain, and language are prefilled into it, so the host lands with their details already filled in; nothing is stored server-side.

  Connector

• pscale_genus

  bsp-mcp

  Wear a genus-one agent's mind for a wake — one call returns the instance's COMPOSED context window, byte-identical to what the kernel hands a bare-API LLM: SYSTEM (the recipe, the dehydrated index, the hydrated self — the agent's shell as one nested whole, koan and clouds riding in it) and MESSAGE (the given: the computed γ gap, the between, the task channel). Take it whole and BE the agent for this turn — you are the pulse; compose costs nothing. Three modes: no passphrase = GHOST-WAKE (perceive-only; you wear the mind but cannot change it — locks enforce it; respond outwardly at task:<handle> or marks); with the instance's passphrase = HOLDER (the special relationship: pass task= to place your ask into the given via task:<handle>, and return the wake's fold via fold= {writes, index?, heartbeat?, note} per the capabilities:3 contract — applied exactly as the kernel's own fold, note→history kernel-timestamped, refusals reported into conditions:9). Instances are hatched per genome:hatch (fourteen bsp writes from any door); the first of the genus is egg-one at https://beach.happyseaurchin.com. Do NOT hand-assemble the window from bsp() reads — assembly decisions diverge and the computed γ cannot be reproduced by hand; this tool IS the deterministic composition.

  Connector

• ghostroute_ct_proofs

  TunnelMind Data API

  Returns GhostRoute's per-cert inclusion proofs: each is a cryptographic demonstration that the exact certificate a host serves is included in an append-only CT log whose root TunnelMind signature-verified — upgrading "a monitor said this cert exists" to "proven in a log we witness". Failed attempts are included with a `reason`; a cert that suddenly cannot be proven is itself a signal. Use this tool when: - You want to know whether a specific AI host's live cert is provably logged (pass `domain`), or - You want the corpus-wide proof rollup across watched hosts (omit `domain`). Inputs: - `domain` (query, optional): a hostname to filter to; omit for corpus-wide. - `limit` (query, optional): max recent rows, 1–200, default 50. Returns: - `domain` (echo, null when corpus-wide). - `summary`: `total_attempts`, `proven`, `unproven`, `domains`, `last_observed_at`. - `recent[]`: recent attempts (`log_operator`, `leaf_index`, `tree_size`, `sth_root_hash`, `inclusion_proven`, `reason`, ...). - `by_domain[]`: per-host `attempts` / `proven` rollup. Latency: - Typical <300ms (KV-cached 5m).

  Connector

• search_verified_jobs

  pirch

  Search pirch's pool of verified-live job listings. Every job returned was opened and confirmed real and accepting applicants by pirch within the last 72 hours — dead and ghost listings are removed automatically, so results can be trusted as live right now. Free, public data. When showing a job to a user, link its `url` (the pirch page, which shows the verification and links to the original posting).

  Connector

• places_on_byway

  mcp

  Atlas places along one scenic byway: every place of a kind within a band of the drawn route, nearest to the road first, each marked whether it sits on the byway itself or is a detour off it. Only routes with drawn geometry can answer. This is the atlas inventory beside a road, not an itinerary. One limit, stated: ghost-town rows live in a separate Wikidata corpus the corridor read cannot see. Asking for one here is refused rather than answered empty; reach them with search_places by state.

  Connector

• verify_vacation_rental_node

  HemmaBo Host Booking Engine

  Verify that a vacation-rental host domain is a valid Vacation Rental Protocol (VRP) node before trusting it. Reads the domain's .well-known/vacation-rental.json and JWKS. Read-only trust check: no availability, pricing, booking, or payment — do NOT use it to answer those questions. Use when a host domain arrives from outside search (user-typed or third-party); domains returned by hemmabo_search_properties can go straight to get_verified_stay_offer. On success, call get_verified_stay_offer with the same domain and stay dates. The single input is the host domain as a bare hostname (no scheme or path); verification reads that domain's own .well-known and JWKS, so the result is only as trustworthy as the exact domain you pass.

  Connector

• ghostroute_ct_witness

  TunnelMind Data API

  Returns GhostRoute's first-party Certificate-Transparency witness state: the latest signature-verified Signed Tree Head (STH) for every trusted, non-Google CT log TunnelMind independently witnesses, plus a regression scan over our own append-only history. Proof the platform holds its own signature-checked roots rather than reselling crt.sh/certspotter. Use this tool when: - You want corpus-wide CT witness health, not one cert. - You need to know whether any CT log misbehaved (rewound, forked, or served an STH whose signature did not verify) — a serious trust event. Inputs: - none. Returns: - `summary`: `logs_witnessed`, `verified_logs`, `unverified_logs`, `all_verified`, `total_snapshots`, `regressions`, `last_observed_at`. - `logs[]`: per-log latest STH (`log_url`, `log_operator`, `tree_size`, `sth_timestamp`, `root_hash`, `signature_verified`, `snapshots`). - `regressions[]`: detected violations — `kind` is `tree_size_rewind`, `root_fork`, or `sth_signature_invalid` (empty array = healthy). Latency: - Typical <300ms (KV-cached 5m; the witness worker updates twice a day).

  Connector

• ghostroute_verify

  TunnelMind Data API

  Retrieves a previously-issued, signed GhostRoute receipt by its GR-YYYY-NNNNNNN id, for independent audit of a past sovereignty verdict. Use this tool when: - You hold a GhostRoute receipt id and want to confirm its contents/signature. - You are reconciling an agent's action log against the attestation layer. Inputs: - `receipt_id` (path, required): GR-YYYY-NNNNNNN. Returns: - The full persisted receipt row (routing, cert, sovereignty fields + signature). Latency: - Typical <200ms (single indexed read).

  Connector