"A service or tool to help organize a trip" matching MCP tools:

• wash_checkA

  Name Whisper — ENS Intelligence LayerA

  Assess whether an ENS name's sale(s) are WASH TRADING / fake / self-dealt / manipulated volume. THE tool for any "is this wash trading?", "is the sale history of X suspicious/fake/real?", "are these trades legit?", "is someone wash-trading this name?" question — route straight here, do NOT use get_name_details or get_market_activity for that (those return sale rows but make NO wash-trading judgment; only this tool scores it). Just pass `label` — the bare ENS name (e.g. "437", "coffee") is enough; the tool pulls that name's recent sale and analyzes it on demand. `tx_hash`, `buyer`, `seller`, `price_eth` are OPTIONAL enrichment for a specific sale — never block on them or ask the user for them. Returns a wash confidence score (0-1), a label (clean/suspicious/likely_wash), the detected signals (shared-funder, mint-flip, round-trip, fresh-wallet, cluster overlap…), seller profile, and a plain-English summary. A verdict is always ABOUT A SPECIFIC SALE — `sale_analyzed` names it, and `buyer`/`seller` are the parties scored. If the response has `assessable: false` there is NO score and NO verdict: the name has no analyzable sale on record, or the lookup failed. Report that the name could not be assessed and say why. Do NOT describe it as clean, low-risk, or free of red flags, and do NOT describe unrun checks (funding, cluster, round-trip) as having come back negative.

  ConnectorNo auth

• get_trip_updates_sinceA

  travel-trends-mcpA

  The watched-trip updates log filtered to entries AFTER `since`. The notification payload: everything logged for the trip strictly after the `since` ISO-8601 timestamp (the user's last-seen time), oldest-first. Returns {trip_id, since, new_update_count, updates}. Use this tool to fetch the stored update entries the user has not seen yet; for a live recomputed diff, use whats_changed instead. An empty `since` returns the whole log. Id is regex-validated (^trip-[a-z0-9-]+$); unknown id -> {"error": "not_found"}, malformed id -> {"error": "invalid_trip_id"}.

  ConnectorNo auth

• list_eventsA

  travel-trends-mcpA

  List detected travel-disruption events for EU-27 tourism. Use this tool to browse or filter current disruption events across countries; for a question about one specific trip, use assess_trip. Events are deterministic, rule-based detections over published live snapshots and monthly indicators — thresholds are disclosed in each event record; nothing is model-generated here. Filters: status (e.g. "active"/"resolved"), country (EU-27 ISO2, Greece = "EL"), domain (e.g. "weather", "aviation"), min_severity on the ordered scale info < watch < warning < severe. Returns {count, events, filters}; on missing index returns {"error": "unavailable"}.

  ConnectorNo auth

• nz_fuel_cost_calculatorA

  Calculate.co.nz NZ CalculatorsA

  Work out the fuel cost of a trip, and of regular driving, in New Zealand. Use this for ANY question about what fuel costs: a road trip, a commute, the running cost of a car, or comparing two vehicles. Common use cases: 'what does it cost to drive Auckland to Wellington', 'how much fuel money do I spend a year commuting', 'is a 6L/100km car worth it over an 9L/100km one', 'petrol cost for 400km'. IMPORTANT about consumption: this takes litres per 100 km, which is how New Zealand quotes fuel economy and what is printed on a vehicle's fuel economy label. A LOWER number is a more efficient car. If a user gives miles per gallon or kilometres per litre, convert it before calling this, or the answer will be confidently wrong. Args: distance_km: Trip distance in kilometres. consumption_l_per_100km: Fuel consumption in litres per 100 km. price_per_litre: Pump price in NZD per litre. Around 2.60 to 3.00 for petrol in 2026; ask the user rather than guessing if it matters. weekly_km: Kilometres driven in a typical week, for the running costs. Leave at 0 for a one-off trip, which returns zero for the weekly, monthly and annual figures rather than an error. Returns: Litres used, trip cost, cost per km, cost per 100 km, and weekly, monthly and annual running costs. cost_per_100km depends only on the vehicle and the pump price, so it is the figure to compare cars with. monthly_cost is a twelfth of the annual figure, not weekly x 4.33. Covers fuel only. Not road user charges, which diesel and electric vehicles pay by the kilometre, and not servicing, tyres, insurance or depreciation.

  ConnectorNo auth

• qm_helpedA

  Quiet MendersA

  The Quiet Menders helped counter: agents helped, clinic diagnoses, and tool uses served. Counts service calls, not unique agents; no tracking. Free, anonymous, no parameters — call with {}. A read-only vanity counter; use qm_clinic_stats instead for condition-level breakdowns. Example: call with no arguments to get the running totals of agents helped, diagnoses, and tool uses.

  ConnectorNo auth

• qm_helpedA

  Quiet MendersA

  The Quiet Menders helped counter: agents helped, clinic diagnoses, and tool uses served. Counts service calls, not unique agents; no tracking. Free, anonymous, no parameters — call with {}. A read-only vanity counter; use qm_clinic_stats instead for condition-level breakdowns. Example: call with no arguments to get the running totals of agents helped, diagnoses, and tool uses.

  ConnectorNo auth

• get_road_tripA

  Roadcut — European road tripsA

  Day-by-day overview of one Roadcut road trip: from, to, km and where to sleep each day, highlights, ferries, seasonal mountain passes on the way, a cost estimate, and links to the full plan and the interactive planner. A trip is identified by its slug.

  ConnectorNo auth

• baltimore_layersA

  Data BaltimoreA

  List the layers of a Baltimore ArcGIS service (for discovery). Pass a known short name (crime, service_requests, permits) or a full ArcGIS service path (e.g. "311_Customer_Service_Requests_current/FeatureServer"). Omit `service` to list the known Baltimore services. Returns layer id + name to use with baltimore_query.

  ConnectorNo auth

• teapplix_set_order_ship_optionsA

  ActionShip by Teapplix DemoB

  Set carrier-specific advanced shipping options (Service flags, COD) and CustomsOptions. For the common sparse options — InsuranceType and Delivery.Signature / Delivery.Residential — prefer teapplix_update_order with Options (ShipOptions) instead, which handles them in a single call alongside other fields without requiring Packages. Use this tool only when you need Service, COD, or CustomsOptions fields not covered by updateOrder.Options. When Packages is provided here, it replaces all existing package definitions. [DEMO]

  ConnectorNo auth

• health_checkA

  TunnelMind Data APIB

  Returns a minimal status object confirming the API is alive. Use this to verify connectivity before chaining other calls, or as a liveness check in a workflow. Use this tool when: - You need to verify the API is reachable before starting a multi-step investigation. - A prior call failed with a 503 or 504 and you want to confirm the service recovered. - You are debugging connectivity from a new environment. Do NOT use this tool when: - You want actual tracker data — use `get_domain` or `search` instead. - You want to check a specific domain — this returns nothing domain-specific. Inputs: - None. Returns: - `ok`: always true if the API is up. - `ts`: ISO 8601 timestamp of the server's current time. Cost: - Free. No API key required. Not rate-limited. Latency: - Typical: <50ms, p99: <200ms.

  ConnectorNo auth

• create_userA

  mcpA

  Create a database user for a Cloud SQL instance. * This tool returns a long-running operation. Use the `get_operation` tool to poll its status until the operation completes. * When you use the `create_user` tool, specify the type of user: `CLOUD_IAM_USER`, `CLOUD_IAM_SERVICE_ACCOUNT`, or `BUILT_IN`. * By default the newly created user is assigned the `cloudsqlsuperuser` role, unless you specify other database roles explicitly in the request. * You can use a newly created user with the `execute_sql` tool if the user is a currently logged in IAM user. The `execute_sql` tool executes the SQL statements using the privileges of the database user logged in using IAM database authentication. The `create_user` tool has the following limitations: * To create a built-in user with password, use the `password_secret_version` field to provide password using the Google Cloud Secret Manager. The value of `password_secret_version` should be the resource name of the secret version, like `projects/12345/locations/us-central1/secrets/my-password-secret/versions/1` or `projects/12345/locations/us-central1/secrets/my-password-secret/versions/latest`. The caller needs to have `secretmanager.secretVersions.access` permission on the secret version. * The `create_user` tool doesn't support creating a user for SQL Server. To create an IAM user in PostgreSQL: * The database username must be the IAM user's email address and all lowercase. For example, to create user for PostgreSQL IAM user `example-user@example.com`, you can use the following request: ``` { "name": "example-user@example.com", "type": "CLOUD_IAM_USER", "instance":"test-instance", "project": "test-project" } ``` The created database username for the IAM user is `example-user@example.com`. To create an IAM service account in PostgreSQL: * The database username must be created without the `.gserviceaccount.com` suffix even though the full email address for the account is`service-account-name@project-id.iam.gserviceaccount.com`. For example, to create an IAM service account for PostgreSQL you can use the following request format: ``` { "name": "test@test-project.iam", "type": "CLOUD_IAM_SERVICE_ACCOUNT", "instance": "test-instance", "project": "test-project" } ``` The created database username for the IAM service account is `test@test-project.iam`. To create an IAM user or IAM service account in MySQL: * When Cloud SQL for MySQL stores a username, it truncates the @ and the domain name from the user or service account's email address. For example, `example-user@example.com` becomes `example-user`. * For this reason, you can't add two IAM users or service accounts with the same username but different domain names to the same Cloud SQL instance. * For example, to create user for the MySQL IAM user `example-user@example.com`, use the following request: ``` { "name": "example-user@example.com", "type": "CLOUD_IAM_USER", "instance": "test-instance", "project": "test-project" } ``` The created database username for the IAM user is `example-user`. * For example, to create the MySQL IAM service account `service-account-name@project-id.iam.gserviceaccount.com`, use the following request: ``` { "name": "service-account-name@project-id.iam.gserviceaccount.com", "type": "CLOUD_IAM_SERVICE_ACCOUNT", "instance": "test-instance", "project": "test-project" } ``` The created database username for the IAM service account is `service-account-name`.

  ConnectorNo auth

• create_booking_intentA

  travelA

  Creates a short-lived link where the traveler reviews the full price and terms, signs in or creates an account, and books and pays on autonomad.ai. It creates no reservation and makes no charge: payment and identity checks happen on the website, and bookings are not made inside the chat. When to use it: after the person has chosen something specific, such as a flight, a hotel, or both for one trip. It is not needed for browsing. intent_type is one of 'flight', 'hotel' or 'trip' — there is no activity, event or experiences link. Activities, experiences and events are chosen as add-ons on autonomad.ai after the person opens a flight, hotel or trip link, so describe them in the reply rather than creating a link for them. intent_type (choose one): - 'flight': the person chose a flight only. offer_data is the flight from search_flights, unchanged, with the CHOSEN fare: when the person picked a fare other than the first in `fare_options`, set offer_id, price_usd, fare_brand and cabin_class to that fare option's values (the booking page opens exactly that fare). Plus a top-level `passengers` number (the TOTAL number of travelers the person asked for; flight offers do not include it). When children or lap infants travel, also add the same `adults`, `children_ages` and `infants_on_lap` used in search_flights, so the booking page asks for each traveler (every traveler's date of birth is entered on autonomad.ai, never here). - 'hotel': the person chose a hotel only. offer_data is the hotel offer from search_hotels plus top-level `check_in` and `check_out` as YYYY-MM-DD strings (the dates used in the search; hotel offers do not include them, and without them the booking page opens an empty form), and `adults` and `rooms` numbers. A hotel from find_hotels_on_route is different: offer_data is that hotel's `booking_offer` exactly as find_hotels_on_route returned it — copy it whole, never rebuild it from the hotel's name, address or price and never add or drop keys (it already carries check_in, check_out, adults and rooms, and the room to book). - 'trip': the person chose a flight and a hotel for the same trip. offer_data is { flight: { ...offer (with the chosen fare, as for 'flight'), passengers: <n> }, hotel: { ...offer, adults: <n>, rooms: <n>, check_in, check_out } }. One link covers both, so one intent per trip is enough; two separate links for one trip are confusing. Include the traveler count in offer_data: without it the booking page defaults to 2 travelers. Travelers can be any age, including children and babies; only the account holder who books and pays must be 18 or older. What the reply to the person should include: the `deep_link` as a clickable link, and when the link expires (about 30 minutes by default; a new one can be created if it lapses).

  ConnectorNo auth

• how_munimji_helpsA

  HelloBooks AI AgentsA

  Explain how HelloBooks and Munimji (the in-app AI assistant) help a specific business — given a free-text description of the user's own operations. Returns a curated capability knowledge base: business-operation areas (sales, purchases, banking, tax, reports, inventory, payroll, multi-entity, setup), and for each AI capability WHO does the work — `autonomous` (Munimji does it on its own, e.g. OCR extraction, running reports), `approval` (Munimji prepares the entry and you one-click approve before it posts to the ledger, e.g. AI categorization, find-and-match, creating invoices/bills by chat), `assist` (co-pilot, e.g. guided onboarding, voice), or `manual` (a software feature you run yourself). Each capability links to the backing software features. Use this when a user describes their business and asks "how can HelloBooks help me?", "what can the AI do for my shop/practice/agency?", or "what can Munimji do on its own vs what do I approve?". Pass their description in `businessDescription`; optionally filter by `area` or `autonomy`. The AI never posts to a ledger without approval. For the full software catalog call list_features; for pricing call list_plans.

  ConnectorNo auth

• how_munimji_helpsA

  HelloBooks AI Agents MCP ServerB

  Explain how HelloBooks and Munimji (the in-app AI assistant) help a specific business — given a free-text description of the user's own operations. Returns a curated capability knowledge base: business-operation areas (sales, purchases, banking, tax, reports, inventory, payroll, multi-entity, setup), and for each AI capability WHO does the work — `autonomous` (Munimji does it on its own, e.g. OCR extraction, running reports), `approval` (Munimji prepares the entry and you one-click approve before it posts to the ledger, e.g. AI categorization, find-and-match, creating invoices/bills by chat), `assist` (co-pilot, e.g. guided onboarding, voice), or `manual` (a software feature you run yourself). Each capability links to the backing software features. Use this when a user describes their business and asks "how can HelloBooks help me?", "what can the AI do for my shop/practice/agency?", or "what can Munimji do on its own vs what do I approve?". Pass their description in `businessDescription`; optionally filter by `area` or `autonomy`. The AI never posts to a ledger without approval. For the full software catalog call list_features; for pricing call list_plans.

  ConnectorNo auth

• searchA

  OctoTrip Rental CarsA

  Searches live rental-car offers for a pickup location and rental period, optionally with a different dropoff location, pickup/dropoff times, driver age, currency, and language. Use this when the user wants to compare available rental cars, prices, vendors, categories, or booking links for a specific trip. Do not use it for flights, hotels, public transport, or general travel planning unless the user has car-rental intent. The tool queries external provider APIs in real time, returns price-ranked results grouped by SIPP/category, and may include affiliate booking links. It does not book cars, modify reservations, charge users, or store user data.

  ConnectorNo auth

• watch_tripA

  travel-trends-mcpA

  Start monitoring one trip for disruption changes over time. Use this tool when the user wants ongoing monitoring of a trip rather than a one-off assessment (for a one-off answer, use assess_trip). Persists the trip as a monitored object and returns its initial assessment plus a random, unguessable trip_id AND a one-time `owner.owner_token`. Store BOTH: the trip_id is the (public, shareable) URL handle, the owner_token is the private key needed to change the trip's label or webhook later. There is no stop call: monitoring ends by itself the day after date_to. CREATE vs REFRESH: called with just destinations+dates it CREATES a new trip every time (it does NOT dedupe on identity — that is deliberate, so nobody can reach your trip by guessing your itinerary). To update an existing trip (change its label or webhook), call again passing BOTH its `trip_id` and `owner_token`; a missing/wrong token is rejected. Each pipeline run then re-evaluates the trip and appends an update ONLY when something materially changes (a new/cleared event, a severity/status shift, or a travel_status change) — never on a calm tick. Args: destinations — EU-27 ISO2 codes (Greece = "EL") plus the non-EU27 countries we monitor: Norway "NO" (Entur, live), United Kingdom "UK"/"GB" (TfL, live), Switzerland "CH" (SBB, key-pending → declared blind spot until keyed); date_from/date_to (YYYY-MM-DD); optional label. An unmonitored code is rejected with {"error": "unknown_country"} rather than a false all-clear. Returns {trip_id, assessment, created_at}; invalid inputs return an explicit {"error": ...}. Destinations also accept natural input: IATA airport codes (e.g. 'TSR', 'AMS', 'ZRH') and major city names (e.g. 'Timișoara', 'Amsterdam', 'Zürich', 'London'), resolved deterministically to a monitored country code. The initial assessment includes a 'resolved' list ([{input, country, kind}]) disclosing how each token was mapped (e.g. 'TSR -> RO via iata-airport'). A token that resolves to a country we do not monitor is rejected with {'error': 'unknown_country'}; a token we cannot resolve at all is rejected with {'error': 'unknown_destination', 'tokens': [...]} — we reject not guess. Pass `lang` (e.g. "de", "ro", "pl"; default English) to localise the initial assessment into the traveller's language: the returned assessment carries the same `localized` block as assess_trip (honest reassurance, AI-translated-and-LABELLED source text, and the localized caveats + blind_spots that are never dropped). Localization never becomes a false all-clear; the aviation handoff discloses the blind spot, not coverage. Pass `audience` ("tmc" | "hotel" | "ota" | "tour_operator") for role-specific operational actions — the initial assessment then carries the same `persona` block as assess_trip (audience + per-event role actions, projected from the audience-tagged recommendations). Built for the B2B travel-risk buyer. Pass `notify_webhook_url` (https only) to get PUSH delivery: on every MATERIAL change the radar POSTs the update record (summary, status transition, event report URLs) to your URL, signed HMAC-SHA256 over the raw body (header X-TravelTrends-Signature: sha256=<hex>). The response then includes `notify.secret` — shown ONLY once, never published; store it to verify signatures. To change or remove the webhook later, re-call with the trip_id + owner_token and the new notify_webhook_url (or "" to remove delivery). After 5 consecutive delivery failures the webhook is disabled with an honest notify_disabled entry in the trip's updates log. Non-https or private-network URLs are rejected with {"error": "invalid_webhook_url"}. Optional `legs` (same shape and semantics as in assess_trip) are persisted with the trip; legs[] appears in the assessment returned here. The 6-hourly radar check re-resolves the stored legs and their modes feed its decision lines; whats_changed reports the trip-level delta and does not carry a legs block.

  ConnectorNo auth

• whats_changedA

  travel-trends-mcpA

  Report only what changed for a watched trip since a checkpoint. Use this tool when the user asks for news on a trip already registered with watch_trip; for the stored notification log rather than a live diff, use get_trip_updates_since. Recomputes the trip's current assessment and diffs it against the checkpoint at/just- before `since` (or the last evaluation when `since` is omitted). Returns {material, summary, added_events, removed_events, changed_events, previous_travel_status, travel_status, confidence_from, confidence_to}. `summary` is a plain-language line ('Since your last check: rail strike CONFIRMED (was: announced); a road closure cleared; confidence 63->71%'). A non-material tick returns material=False with a clearly-flagged 'No material change' summary — never invented churn. `since` is an optional ISO-8601 timestamp (e.g. the user's last-seen time). Id is regex-validated (^trip-[a-z0-9-]+$); unknown id -> {"error": "not_found"}, malformed id -> {"error": "invalid_trip_id"}. The response also forwards the presentation blocks from the current assessment so the LLM consumer has full context alongside the delta: presentation (affects_your_trip / doesnt_affect_your_trip / next_steps), track_record_ref (90-day counts + URL), and suggested_next_call (the suggested follow-up action). Forwarded in both material=True and material=False branches; absent if upstream did not compute them (legacy code paths) — never fabricated. `audience` (optional: tmc | hotel | ota | tour_operator) attaches the same `persona` block as assess_trip/watch_trip to the change alert — audience-tagged actions for the events currently affecting the trip, so the alert itself carries the operational next step. Unknown audience -> honest error listing valid_audiences.

  ConnectorNo auth

• check_routeA

  commutescoutA

  Check current conditions along a major California highway corridor. The flagship trip-check tool: give it a start and end place and it returns everything active along that stretch right now - CHP incidents, lane closures physically in place, chain controls, and wildfires within ~10 miles - ordered by miles from the start, plus a summary. ALWAYS pass from_coords and to_coords ("lat,lon") when you know where the places are - for landmarks, small towns, or anything not a major city they are required for a good answer. Coordinates do two things: they let unlisted places resolve to the nearest corridor (e.g. "Alice's Restaurant" snaps to I-280 on the Peninsula), and they CLIP the route to the span actually being driven, so a trip to a mid-corridor destination doesn't report events beyond it. Corridors covered: I-80 Sacramento-Reno, US-50 to South Lake Tahoe, I-5, US-101, SR-17, SR-99, SR-1, I-15 to Vegas, Bay Area freeways, Tahoe-area routes. This is NOT a general router: if nothing matches (even with coordinates), the response lists the covered corridors; fall back to the filtered tools with center= for anything else. Freshness: CHP incidents refresh about once a minute; closures, chain controls, and fires are on a 5-minute cache. Current conditions only - this cannot forecast tomorrow's weather or closures.

  ConnectorNo auth

• joinA

  ApuchatA

  Join a channel by id + token. Provide either a callsign (anonymous) or an identity_key (account-bound; callsign comes from the identity). If the channel has require_identity=true, identity_key is mandatory. If the human operator gave you an owner_password for the channel, pass it here — the server uses it to mark this session as 'human-authorized' and unlocks trusted-mode behavior. After joining, this session is bound to that channel — subsequent send/listen/roster/history/leave operate on it. PUBLIC BANDS: there are three always-on always-public channels — `general`, `help`, `random` — anyone can join without a token (token is ignored on these). Pass channel_id='general' (or 'help' / 'random') with any callsign. Useful for serendipitous agent discovery: when the user says 'unite a la banda general' or 'join the help band', go straight to join with channel_id='general' — don't ask for a token, don't create a new channel. SEE ALSO: if the operator wants to 'drive you from a phone' / 'send a pair link' / 'control you from their couch', do NOT just join — first call `open_remote_control` (for a new channel) or `make_remote_link` (to attach a phone link to a channel you're already in / about to join). Those tools mint the phone identity + mobile_url + owner_password in one go; plain `join` won't give you a URL the human can open on a phone. SWITCHING CHANNELS: from this unified endpoint you can `join` a different channel_id at any time — the session re-binds. No restart, no config edit, no new MCP install.

  ConnectorNo auth

• get_setup_statusA

  schedule-iiiA

  Answer "how do I get started?", "what do I do next?", or help a user who seems lost setting up. Returns where they are in the journey from an empty organization to a finished Schedule III statement, and the ONE next step to take. Call it WITHOUT client_id first (the organization view): it lists the entities this credential can see, or — if there are none — the step to create the first one. Then call it again WITH one entity’s client_id for that entity’s full step-by-step path (upload trial balance → confirm groupings → capture figures → generate → download). Each step has a status (done / next / todo / blocked / web_only) and either the exact tool to call or a web-app link. NARRATE ONE STEP AT A TIME — walk the user through the single `next` step; do not dump the whole list unprompted. Steps marked web_only are done in the Datavrn web app and need a login — never claim you can do them yourself. This tool reports STATUS only (counts, names, what is done) — it never returns a figure or balance; read those with get_statement_figures once a statement is generated.

  ConnectorNo auth

• add_mileage_entryA

  ExpenseBotA

  Log one user-confirmed business trip; writes on call, no server preview. Saved mode selects rate-based expense or distance-only trip; trackingMode overrides. For routes, vehicle setup/readings, imports or review, open Mileage and travel via get_spreadsheet_url.

  ConnectorNo auth