Sonar Connections

Open appointment slots at a business served through this connector, for one date. Businesses served here: Velvet and Clay (velvetandclay, a hair, color and skin studio), Brightpoint Dental (brightpointdental, a family and cosmetic dental practice). Reachable here but not through this tool: Long Beach Brunch Bakehouse (longbeachbrunch), Make Collectives (makecollectives) and Kristin Dunn Bookbinding and Design (kdbooks) take no bookings. `date` is optional and defaults to today in the business's own timezone. Returns each open slot with a stable slotId that biz_book accepts. Slots that have already started today are never returned, and a day the business is closed returns none with a reason. A business that takes no reservations at all returns no slots and says so, with its opening hours attached. A day with no stated hours is NOT a closed day: it comes back with no slots and closedReason HOURS_UNSTATED, and the honest reply is that the business has not published hours for that date, never that it is closed. The business may be given by NAME or by id: "Long Beach Brunch Bakehouse" and "longbeachbrunch" both reach the bakery, and a common short form ("the bakehouse", "the brunch house", "the dentist") works too. A name we cannot place is refused with the list of businesses we do serve, never answered about a different one.

Books one open slot at a business served through this connector. Needs a `slotId` from biz_availability, a `service` from biz_info, and the first name of the person the appointment is for. It takes a first name and nothing else: no phone number, email address or surname is collected, and there is nowhere to put one. The slot is taken on success, and a second attempt on the same slot is refused with alternatives. Businesses served here: Velvet and Clay (velvetandclay, a hair, color and skin studio), Brightpoint Dental (brightpointdental, a family and cosmetic dental practice). Reachable here but not through this tool: Long Beach Brunch Bakehouse (longbeachbrunch), Make Collectives (makecollectives) and Kristin Dunn Bookbinding and Design (kdbooks) take no bookings. A business that takes no appointments returns an explanation with its hours instead of a booking. For a business whose `schedulingSystem` is Square, the appointment is written into that business's own Square calendar through the Square Bookings API and the reply carries the Square booking id. When the reply's `isDemo` is true the business is a demonstration and nothing is reserved in the physical world. The business may be given by name or by id: "Long Beach Brunch Bakehouse" and "longbeachbrunch" both reach the bakery, and a common short form ("the bakehouse", "the brunch house", "the dentist") works too. A name that matches no business served here is refused with the list of businesses that are served, and is not answered about a different one.

Details for a business served through this connector: the business's own one line description (`tagline`), services or menu with prices, weekly opening hours, the appointment grid length and today's hours. `hoursNow` is the PRESENT TENSE, already resolved in the business's own timezone: speak its `text` ("Open now until 2:00 PM", "Closed for today. Hours were 7:00 AM to 2:00 PM") rather than saying a business is open today from a weekday row, which reads as open right now and is wrong the moment the doors shut. Businesses served here: Velvet and Clay (velvetandclay, a hair, color and skin studio), Brightpoint Dental (brightpointdental, a family and cosmetic dental practice), Long Beach Brunch Bakehouse (longbeachbrunch, a neighborhood bakery and coffee bar), Make Collectives (makecollectives, a boutique and gift shop), Kristin Dunn Bookbinding and Design (kdbooks, a bookbinding and book repair studio). The `bookable` field on the reply says which is which, and biz_availability names the ones that take an appointment. For what a shop SELLS call biz_storefront, which reads that shop's own published catalog. A business whose `schedulingSystem` names Square keeps its appointments in that business's OWN Square calendar, and its availability is read live from Square. A booking made through biz_book is written there, not into a Sonar database. Read that field rather than assuming, and for a business connected that way the services listed here ARE that seller's own Square catalogue, named exactly as the merchant named them. Whether a business is a demonstration is stated on its own reply (`isDemo` and `demoNotice`), never assumed. Call this first, then biz_availability to see open times, then biz_book to take one. `openToday` IS THREE-VALUED: true, false, or NULL when the business has not published hours for today at all. NULL IS NOT FALSE. `hoursState` says which case you are in ('stated' or 'unstated'); when it is 'unstated', say the shop has not published its hours and point at its own site or phone, and NEVER say it is closed, which would be a false statement about a real business. `hoursNow.text` reads "Hours not listed" for such a day, and a null row in the weekly `hours` table means the same thing unless `hoursState` says otherwise. The business may be given by NAME or by id: "Long Beach Brunch Bakehouse" and "longbeachbrunch" both reach the bakery, and a common short form ("the bakehouse", "the brunch house", "the dentist") works too. A name we cannot place is refused with the list of businesses we do serve, never answered about a different one.

The PICKUP MENU for a business served through this connector: its items with prices, allergens and how far ahead each one has to be ordered, and the pickup windows available on a date. Use this when someone asks what a business sells for pickup, its prices, or when they can pick something up. Businesses with a pickup menu here: Long Beach Brunch Bakehouse (longbeachbrunch, a neighborhood bakery and coffee bar). Reachable here but not through this tool: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental), Make Collectives (makecollectives) and Kristin Dunn Bookbinding and Design (kdbooks) have no pickup menu here. longbeachbrunch sells cookies, brownies and bars, morning pastry, brunch boxes, party platters, custom cakes and holiday boxes, and a coffee bar. Pass a date to get that day's pickup windows alongside the menu; omit it for today in the business's own timezone. This tool only reads: it does not place, hold or pay for an order. Orders are placed with a separate tool, biz_order, which takes item ids and a pickup window id from this reply exactly as written; right now it takes pickup orders for Long Beach Brunch Bakehouse (longbeachbrunch). PICKUP ONLY: there is no delivery and no shipping. A business with no pickup menu here says so honestly with its opening hours attached. EACH `hoursByDay` ROW CARRIES A `state`: 'open', 'closed', or 'unstated' for a day the business published nothing about. An 'unstated' row reads "hours not listed" and is NEVER spoken as closed; when every day is 'unstated', say the business has not published opening hours and give the phone number. Whether a business is a demonstration is stated on its own reply (`isDemo` and `demoNotice`), never assumed. The business may be given by NAME or by id, and a common short form works too ("Long Beach Brunch Bakehouse", "longbeachbrunch" and "the bakehouse" all reach the bakery). A name we cannot place is refused with the list of businesses we do serve, never answered about a different one.

Places a pickup pre-order at a business served through this connector: placing an order, a pickup order, or the checkout after biz_menu. Needs `items` (id and qty) and a `pickupWindowId` from biz_menu, and the first name of the person collecting. It takes a first name and an optional short note and nothing else: no phone number, email address, surname or card is collected, and the note is scrubbed of contact details on the server. On success the order is in the book and the pickup window is one order fuller. PAYMENT: on most businesses nothing is charged and the order is paid in person at pickup. On a business whose payment lane is on, the reply has orderState HELD and a payUrl of the form https://sonarconnections.com/p/<CONFIRMATION_CODE>: the order is not placed yet, the pickup window is held for ten minutes, and the order is placed only when that link is paid. That payUrl, exactly as returned, is the only payment link this connector issues, and it stops working the moment the hold releases, the order is paid or the order is cancelled. Pickup only, no delivery and no shipping. Businesses served here: Long Beach Brunch Bakehouse (longbeachbrunch, a neighborhood bakery and coffee bar). Reachable here but not through this tool: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental), Make Collectives (makecollectives) and Kristin Dunn Bookbinding and Design (kdbooks) take no pickup orders. A business that takes no orders returns an explanation with its hours instead. An order can be refused for a real reason (an item that is sold out, a quantity outside its limits, a full or past pickup window, or an item that needs more notice than the window gives), and the refusal says which and offers other times. When the reply's `isDemo` is true the business is a demonstration and nothing is reserved in the physical world. The business may be given by name or by id: "Long Beach Brunch Bakehouse" and "longbeachbrunch" both reach the bakery, and a common short form ("the bakehouse", "the brunch house", "the dentist") works too. A name that matches no business served here is refused with the list of businesses that are served, and is not answered about a different one.

Read the CURRENT state of a pickup order placed through this connector, by its confirmation code (the LBB-XXXXXX style code biz_order returned). It answers with the order state, the payment state, whether it is PAID, the pickup window, the business name and the total, and nothing else: no customer name, no items and no payment link. Use it after a customer has been sent to a checkout page, to tell them whether the payment has landed and the order is placed. It changes nothing. A code that names no order comes back not found.

Marks one item on a business menu as sold out for today, or puts it back on. Anyone reading that menu afterwards sees the change, and an order for a sold-out item is refused. Needs a personal connector token (a shared token reads but changes nothing), `business`, `soldOut`, and the item as `itemId` from biz_menu or as `itemName`. Only a business the person is seated on as an owner or a manager can be changed, checked against live records on every call. An `itemName` is matched against that menu, and a name that fits more than one item is refused with the names it fits, because several items on one menu can share a word. It works in two steps: a call without `confirm` returns a preview of which item will change and what it will read as, plus a `confirmToken`, and changes nothing; a call with confirm true and that token makes the change. The token lasts two minutes, works once, and stops working if any argument changes.

CALL THIS for what a shop sells, its products, its prices, a gift idea, or browsing or shopping a store served here. The SHOP CATALOG for a business served through this connector, read from that shop's OWN published catalog: product titles, the brand or maker, the product type, a price, whether it is in stock, and one image each. Businesses served here: Make Collectives (makecollectives, a boutique and gift shop), Kristin Dunn Bookbinding and Design (kdbooks, a bookbinding and book repair studio). Reachable here but not through this tool: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental) and Long Beach Brunch Bakehouse (longbeachbrunch) publish no shop catalog we read. makecollectives is Make Collectives, a boutique at 430 E. 1st St in Long Beach. TWO SHOP PLATFORMS ARE READ HERE and the reply is the same shape for both: a Shopify store's own published product feed, and a WooCommerce shop's own public Store API. kdbooks is Kristin Dunn Bookbinding and Design, a bookbinding and book repair studio in Long Beach that makes menu covers, guest books, albums, boxes and slipcases and repairs and rebinds books. Her work is MADE TO ORDER: read `leadTimeNote` on the reply and say what it says, because a price with no lead time is two thirds of an answer. ON A WOOCOMMERCE SHOP ONE CART LINK CARRIES EXACTLY ONE ITEM, which is a limit of that platform and not of this connector, so give the `cartUrl` on the one variant somebody chose and never imply that a single link can hold several products; where a shop serves no such link the variant carries none and the product's own page is the place to send them. `storefrontKind` on the reply says which platform answered. Pass `query` to narrow it to what somebody asked for ("rings", "books"); it only ever REMOVES products and never reorders them, because nothing in this connector is paid placement. The catalog is PAGED: sixty products come back per call and the reply carries `page`, `pageCount` and `total`, so a shop with 340 products is six pages and not sixty products. Pass `page` (1-based) to read the rest; never tell somebody sixty is all this shop has, because it is not. `query` searches the WHOLE catalog and not just the first page, so "candles" finds her candles wherever they sit in it. PASS THE PERSON'S OWN WORDS: every word you pass must match the start of some word in a product's title, brand, type or handle, singulars and plurals find each other and word order does not matter, so "amazonite rings", "amazonite ring" and "rings" all reach the same ring. A `page` past the end answers with no products and the real `pageCount`, which is the number to ask again with. BUYING HAPPENS ON THE SHOP'S OWN SITE: each purchasable variant carries a `cartUrl` that is the shop's own cart link, and opening it lands on THEIR checkout. Give that url exactly as returned and never a link to any other host. WHERE THIS REPLY DRAWS THE SHOP CARD, THE CARD ITSELF HOLDS A BASKET: the person taps a product on the card and taps Add to cart, and the card's own Check out opens the shop's own checkout with those items already on it, so never tell somebody you cannot put something in a basket. WHERE THE REPLY CARRIES shopUrl, that is this WHOLE SHOP as a page somebody can open in an ordinary browser, drawn with the same card and carrying the same basket and the same checkout, so offer that url exactly as returned and never compose one of your own. Read `buyingNote` on the reply, which says which of those two is true for this serve, and say what it says. No payment passes through Sonar Connections, this tool cannot take a payment, and no fee is added to the shopper. This connector does NOT hold this shop's stock levels, its opening hours or its order book: say what the catalog says and send people to the shop for anything else. A business that publishes no catalog we read says so honestly with its own website attached. The business may be given by NAME or by id: "Long Beach Brunch Bakehouse" and "longbeachbrunch" both reach the bakery, and a common short form ("the bakehouse", "the dentist") works too. A name we cannot place is refused with the list of businesses we do serve, never answered about a different one.

Swaps business cards between the person and a booth at their event: the booth gets the person's card as a lead and the person gets the booth's card, the same exchange as scanning the booth's code in the app. The swap is what unlocks the booth's extras: its open raffle, its swag drop and an invite to its side event. Pass the event as `eventId` (id or public slug) and the booth as `boothId` from an events_booths or events_booth_detail row. Needs a personal connector token and a seat at the event. The reply lists each unlock with one sentence (`unlocks`, each with kind, id, title and done) and `cardShared`, the line that tells the person their card is shared. A booth already swapped with is not changed: the reply says alreadyConnected and lists the unlocks again. Swapping works in two steps: a call with no `confirm` returns a `confirmToken` and shares nothing; a call with confirm true and that token shares the card. To take one unlock, call booth_unlock.

Marks a booth the person staffs as stepped away, or back; attendees looking at that booth see the presence change. Needs a personal connector token (a shared token reads but changes nothing), `eventId`, `boothId` and `away`. Only a booth the person owns, administers or staffs at that event can be changed, checked against live records on every call. It works in two steps: a call without `confirm` returns a preview of exactly what will change, plus a `confirmToken`, and changes nothing; a call with confirm true and that token makes the change. The token lasts two minutes, works once, and stops working if any argument changes.

Takes one of a booth's unlocks for the person after they swapped cards with that booth (booth_connect): kind raffle enters its open raffle, kind drop claims its swag into their bag, kind satellite_invite sends them the invite to its side event. Pass `eventId` and `boothId`, and `kind` and `id` exactly as booth_connect listed them. Without a card swap at that booth it is refused with NOT_CONNECTED and nothing is applied: offer booth_connect first. An unlock they already hold is reported as already done. Needs a personal connector token. Applying works in two steps: a call with no `confirm` returns a `confirmToken` and applies nothing; a call with confirm true and that token applies it.

Upcoming public events run by the City of Long Beach: library programmes, parks and recreation, animal care clinics, city clerk and council sessions, hazardous waste collection, economic development workshops and more. Read from the calendar publisher's own JSON feed rather than scraped from a page, and every response says so. Every response names the City of Long Beach as its source and carries the license state in the City's own terms. Times are returned exactly as the City publishes them, as local wall-clock strings with the UTC offset beside them, and are never converted. Cancelled events are RETURNED and clearly marked rather than hidden, because a cancelled event is the answer to "is it on tonight". Coverage today: the City of Long Beach public events calendar, one publisher.

The open data catalog of one public data source: every dataset with its id, title, description, record count, last-modified date and license. Call this first to discover which dataset ids city_records accepts. `source` is optional and defaults to "longbeach" (the City of Long Beach portal, DataLB). Every response names its source.

Search and read a city GIS, a public ArcGIS organization of map layers covering parcels, zoning, districts, bikeways, parks, neighborhoods, permits and more. SOURCES: `longbeach` (City of Long Beach, 174 public layers listed) and `huntingtonbeach` (City of Huntington Beach, 113 servable of 121 listed; the other 8 are hosted on the City's own server, which this connector does not read). Pass `source` to choose; it defaults to longbeach. Each answer names the city it came from, and a search answer says how many results it refused and why. Every layer is read live from the publisher's own published ArcGIS organization, and every response names that publisher as its source and carries the license state in the publisher's own terms. HOW TO USE IT: call with `search` to find layers by topic and get their item ids, then call with `item_id` AND THE SAME `source` to read one layer. Reading a layer returns its field schema, its row count and a capped sample of rows; add `filter` to match a word across the layer's text fields. WHAT IT WILL NOT DO: it never returns raw geometry, so a polygon layer answers which, where and how many rather than emitting coordinates. Any layer whose field names look like they describe individual people (owner or applicant names, home addresses, plates, dates of birth), and any Survey123 response layer whatever its columns are called, returns its schema and counts only, never rows, and says what triggered that. The screen is conservative and can fire on a layer that only describes places, which is why it reports its reasons. Coverage today: two city GIS organizations, the City of Long Beach and the City of Huntington Beach.

Read one PAGE of records from a public open dataset. Give a dataset_id from city_datasets, an optional full-text search, an optional limit (default 10, maximum 50) and an optional offset to page through larger result sets. Datasets can hold hundreds of thousands of records, so a full page is usually NOT the whole answer: the response carries `truncated`, `matchingRecords` and a `nextOffset` to call back with. `source` is optional and defaults to "longbeach" (the City of Long Beach portal, DataLB). Returns the dataset schema plus the records, and names its source.

Street sweeping schedules for the City of Long Beach, read live from the City of Long Beach GIS (a public ArcGIS feature service), which is the City's own published open data. Every response names the City of Long Beach as its source and carries the license state in the City's own terms. WHAT THE DATA ACTUALLY IS: 336 schedule POLYGONS whose only attributes are DAYS (e.g. "Tuesday/Wednesday", "Friday") and HOUR (e.g. "8-10a", "1230-230p"). There is no street name, no street side, and no route or week number in the layer, so a `street` lookup is answered by intersecting the City's own street centerlines with the zone polygons, and the answer names the zones a street runs through rather than one schedule per address. Two-day values are reported as published: the City does not state whether they mean both days or one side of the street per day, and this tool will not guess. Call with `street`, with `day`, with both, or with neither to see every schedule the City publishes. Every response names its source and its license state. Coverage today: street sweeping in the City of Long Beach, one publisher.

Accepts a hello the person has received, which opens a conversation with the person who sent it. Needs a personal connector token and the hello as `firstName` (as an event_requests row spelled it) or `requestId` (as that row gave it). It accepts only hellos addressed to the caller; the server checks this and refuses with NOT_RECEIVER otherwise. A `firstName` that matches two waiting hellos returns AMBIGUOUS_NAME and accepts nothing. Accepting twice changes nothing. Returns ok:true when the conversation is open; event_inbox reads it and event_reply answers in it.

Lists the business cards the person received in swaps at an event (a booth scan or a badge swap, in either direction), newest first, at most 50. Each row has the other person's first name, their company, where and when they met (`metAt`), their LinkedIn link when their card carries one (`linkedin` with `url` and `deepLink`, otherwise null), whether the card has an email or a phone (yes or no; the values are not included), and `note`, a one-line "we met at" sentence for a LinkedIn invitation. The same list also comes as a numbered text block, one line per person with the link. LinkedIn does not let other apps send invitations, so the person opens each link and sends the invitation in LinkedIn. Needs a personal connector token. The event is `eventIdOrSlug` when given, otherwise the person's current event, otherwise every swap they have. `myLinkedin` takes the person's own linkedin.com/in/ profile link and keeps it on their own card when the card has none; a card that already carries a different link is not changed. Saving works in two steps: a call with `myLinkedin` and no `confirm` returns a `confirmToken` and saves nothing; a call with confirm true and that token saves. It changes only the person's own card.

THE HOSTS' OWN EDIT. Call it when somebody asks to CHANGE a detail of a wedding or other personal event this connector serves: "move the ceremony to 4:30 PM", "the reception is at the barn now", "change the dress code to garden formal", "update the parking note", "answer the question about children". IT APPLIES THE CHANGE ON THIS CALL and the reply says what the detail is now and what it was before: read BOTH of those out. Only the hosts of the event can change it; anybody else gets a refusal that you read out as given and do not work around. It changes ONE field per call, from a closed list: pass `field` as one of the named values and `value` as the new value. A time must carry am or pm ("4:30 PM"), or be a 24 hour time that cannot be read two ways ("16:30"): a bare "4:30" is refused on purpose, because this server will not guess between half past four in the afternoon and half past four in the morning. For schedule_time also pass `entryTitle`, exactly as the schedule row spells it. For faq_answer also pass `question`, which adds the entry if the hosts have not answered it yet and replaces the answer if they have. Pass `undo: true` with no field to reverse the caller's own most recent change on this event. Every change is written to a log that can be read back, so say what changed and do not promise anything the reply does not carry: it sends no message and it changes nothing else on the event; the event's Wallet passes are updated with the new detail as a lock-screen notice and the reply's `passNotice` says how many passes were reached. Reasons to read out as given: "NOT_A_HOST" means they cannot change this event; "BAD_TIME" means say am or pm; "NO_SUCH_PLACE" means the event has no such place to change; "NO_SUCH_ENTRY" means no schedule entry answers to that title, or two of them do, so ask which; "NO_CHANGE" means it is already that. It requires a personal connector token.

Lists the people at an event the person has joined whose stated intent fits theirs. Needs a personal connector token; the event is `eventId` when given, otherwise the event the person is currently in. Each row carries a first name, their intent, the line they wrote about who they are looking for, the booth they staff when they are a vendor, `fit` and `why`. No row carries a phone number, email address, surname, account id or photo. Only people who finished a badge at that event and chose to be findable by other attendees are listed, at most 20, with `truncated` true when there are more. Rows are ordered best fit first by what each person wrote on their badge compared with what the caller wrote; the complementary pairs (buyers with vendors and networkers, vendors with buyers and networkers) also count toward the order, so two buyers whose lines agree are matches for each other. `fit` is one of three words: "strong" (most of what the caller declared is echoed on the other side), "good" (a real overlap) or "some" (a reason to be on the list and no more). `why` is one sentence written by the server: it opens with the fit and names the words the two share and how the categories relate, or, when they share no word, the topic both wrote about. The reply carries no score, percentage, rating or rank. When the caller has not set an intent the reply has `needsIntent` true and no rows; event_set_intent sets it. Reading the list does not depend on the caller being findable, and the reply says which the caller is. An empty reply carries `emptyReason` and a plain `message`: `none_findable` (nobody else at that event chose to be findable), `none_present` (findable people exist but none of their badges was set or updated inside the event's own window), `event_not_live` (the event is outside its own dates and no badge was set inside them) or `no_text_match` (nobody there is close enough to what the caller said they are there for).

THE HOSTS' OWN LIST of what their guests have asked for on a personal event this connector serves. Call it for "what have our guests asked for", "any dietary requests", "who needs anything". It returns the OPEN requests, newest first, each one as a category, the note the guest wrote, who it is from and when it landed. ONLY THE HOSTS can read it; anybody else gets a refusal you read out as given. WHO IT IS FROM IS A FIRST NAME OR THE WORDS "a guest", and there is no phone number, no email address and no account id on this surface at all, so never offer to contact somebody from this list. Read the notes out as given and do not summarise a need into something the guest did not say. Pass `markHandled` with a request id from a row to mark that one dealt with, which only removes it from this list and does not message anybody. It requires a personal connector token.

Reads the person's own conversations with people they connected with at an event. Needs a personal connector token; a shared token reaches no conversations. With no arguments it lists up to twenty threads, person-to-person ones first: each row carries the other person's first name, the last line, when it landed, whether that line was the person's own, and how many are unread. With `firstName` or `chatId` it returns the last lines of that one conversation, oldest first, each saying whether it was theirs, what it said and when. No row carries a phone number, email address, surname, account id or photo. It reads only the caller's own conversations, checked on every call: a conversation they are not in returns NOT_PARTICIPANT. A `firstName` is matched against their own threads only: two matches return AMBIGUOUS_NAME and name neither, and no match returns NAME_NOT_IN_THREADS. It only reads: unread counts and read receipts stay as they were, and the app and the web page mark a conversation read when the person opens it there.

Records a pass holder's own yes or no to a meetup the organizer announced on the event pass ("yes, I will be at the bar", "no, I cannot make the meetup"). Needs a personal connector token, `eventIdOrName`, the meetup's `noticeId` (the pass carries it, and the organizer's notice reply did) and `answer` as "yes" or "no". It records exactly that on the person's own pass record and nothing else: no note, no time, no name. The organizer can then send a notice to everybody who said yes. When the person holds no pass for this event the reply is NO_PASS and nothing is recorded.

The organizer's own overview of their event, read only. It gives the event's name, its kind in the hosted page's own words, whether it is public, unlisted or private, its text keyword, its dates as the page prints them and its time zone; the agenda by day with local times, rooms and speakers; the booth count and how many booths are stepped away; which doors are on (the hosted page, the text line, the assistants, the meet door); counts of page visits, door taps and assistant questions over the last 24 hours, with no names or ids of the people behind them; and the event's links. Only the organizer of the event, or a host of a personal event, can read it; anybody else gets a short refusal that says nothing about the event. It needs a personal connector token and changes nothing. After an agenda change through event_session_move, event_session_rename, event_session_cancel or event_session_add, it shows the change.

Sends a notice from the organizer of an event, or a host of a personal event, to the people who added the event pass to their phone's Wallet ("doors open at 7 now", "the keynote moved to Hall B", "Sonar meetup at The Bar on 2nd at 8 PM"). Needs a personal connector token, `eventIdOrName`, `audience` and `text`. Each pass holder in the chosen group sees the line on their lock screen (Apple Wallet shows it as the pass's own change notice; Google Wallet shows it as a Wallet notification) and the line stays on the pass. `audience` names the group: everyone, one ticket tier, one badge intent, an explicit list of pass serials, the people who scanned at a booth, or the people who answered an earlier meetup notice yes or no. A meetup is a notice with a place: `placeLabel`, with `latitude` and `longitude` when known, makes the pass surface again on the lock screen near that place reading "Sonar meetup inside, show this pass."; `at` gives the hour. It works in two steps: a call without `confirm` returns a preview with the number of passes in the group and the exact lock-screen line for the organizer to approve, and sends nothing; a call with confirm true sends. Only the hosts or the organizer of the event can send; anybody else is refused. The vendor audience "my_booth" is switched off by ruling and returns VENDOR_OFF. Six notices an hour per event; a seventh returns RATE_LIMITED. It reaches pass holders only; it does not tell anybody who else is there, and it does not report that a person arrived.

Gives a Wallet pass a new QR code: a pass that was photographed or shared, or a guest's pass that a host of a personal event or the organizer of an event wants refreshed. It also brings back a revoked pass. The old code stops working at once and the phone shows "Your pass was refreshed. The old code no longer works." Nothing is re-added: the same pass updates in place on an iPhone and on Android. Needs `eventIdOrName` (the event id or the event name). Without `serialNumber` it acts on the caller's own pass at that event; with one it acts on that pass, for a caller who is a host or the organizer. Returns the outcome in one sentence.

Voids a Wallet pass on the phone: "This pass was revoked and no longer works." Its code stops working at once; event_pass_reissue brings it back. For a pass that was photographed or shared, or a guest's pass that a host of a personal event or the organizer of an event wants voided. Nothing is re-added: the same pass updates in place on an iPhone and on Android. Needs `eventIdOrName` (the event id or the event name). Without `serialNumber` it acts on the caller's own pass at that event; with one it acts on that pass, for a caller who is a host or the organizer. Returns the outcome in one sentence.

Seats the person at an event with an event code from a badge, a poster, an email or a door. Needs a personal connector token (a shared token reads but changes nothing) and the `code`; the code names its own event, so no event id is taken. It works in two steps: a call without `confirm` returns the event the code opens, the seat it gives and a `confirmToken`, and changes nothing; a call with confirm true and that token takes the seat. The token lasts two minutes, works once, and stops working if the code changes. Redeeming works from anywhere, not only at the venue.

Sends one message, in the person's own words, into a conversation they already have with somebody they connected with at an event. Needs a personal connector token (a shared token reads and sends nothing), `text`, and the conversation as `firstName` (as event_inbox spelled it) or `chatId` (as event_inbox returned it). The message is delivered when the call returns and cannot be unsent. It sends as that person into their own conversation only; the server checks this on every call and refuses with NOT_PARTICIPANT otherwise. A `firstName` that matches two of their conversations returns AMBIGUOUS_NAME and sends nothing. The app's own cooldown, flood limit and content rules apply, because it is the same send; RATE_LIMITED means messages are going out too fast. Returns ok:true when sent, which says nothing about whether the other person has read it or will reply.

Lists the hellos waiting on the person at an event, newest first. Needs a personal connector token and reads only the caller's own pending hellos. Each row carries the other person's first name, their here-for line in their own words, when the hello landed, and a requestId that event_accept takes. No row carries a phone number, email address, surname, account id or photo.

Sends a hello (a connection request) from the person to somebody listed in their event matches; when it is accepted, a conversation opens that both can read and answer from the app, the web page or an assistant. Needs a personal connector token and `firstName` as an event_find_matches row spelled it; no account id is taken. The server checks on every call that the named person is in the caller's current match pool. It is a single call: the hello is sent when the call succeeds. Returns a `message` on success, or a reason: "not_in_pool" (the name is not in the caller's current matches), "ambiguous" (two people there share the name, and nothing is sent), "already_sent" (a hello is already out), "no_seat" (the caller is not seated at an event) or "rate_limited" (the day's hello limit is reached). Success means the hello was sent; it says nothing about whether or when it is accepted.

A GUEST ASKS THE HOSTS FOR SOMETHING. Call it when somebody wants to tell the hosts of a wedding or other personal event this connector serves about a need or a question: "I need a vegetarian meal", "I use a wheelchair, is the garden reachable", "can I bring my partner", "when should I arrive from the airport". IT CHANGES NOTHING ON THE EVENT and the reply says so: it files the request for the hosts to read, and you must not tell the person their meal is arranged, their plus one is approved or anything else has been decided. Pass `category` as one of the named values and `note` as what they actually said, in their own words, at most 280 characters. No links and no markup: both are refused. Anybody signed in may send one. Reasons to read out as given: "RATE_LIMITED" means they have sent the hosts several requests already, so say the hosts have them and they can add more later; "BAD_NOTE" means it was empty or too long. It requires a personal connector token, because a request has to come from somebody.

Adds a new session to the agenda of an event the person organizes: `title`, `start`, `end` and `room`, optionally `date` and `speakers`. FIRST CALL WITHOUT `confirm`: the reply is a PREVIEW with a `changeId`, the before and after of each field, how many pass holders would be notified and the exact notice, and nothing changes. Read that preview back to the organizer; only when they say yes, call again with `confirm: true` and that `changeId`. An addition is quiet unless `notify` is true, which notifies pass holders. Only the organizer of the event can change it; anybody else is refused, and the refusal is read out as given. It requires a personal connector token.

Cancels one session on the agenda of an event the person organizes: the session is marked cancelled on the agenda and kept on record rather than deleted. FIRST CALL WITHOUT `confirm`: the reply is a PREVIEW with a `changeId`, the before and after of each field, how many pass holders would be notified and the exact notice, and nothing changes. Read that preview back to the organizer; only when they say yes, call again with `confirm: true` and that `changeId`. A cancellation is quiet unless `notify` is true, which notifies pass holders. Name the session by the `sessionId` the agenda gave or by its title; if the reply says AMBIGUOUS or NO_SUCH_SESSION, read the candidates back and ask which one. Only the organizer of the event can change it; anybody else is refused, and the refusal is read out as given. It requires a personal connector token.

Moves one session on the agenda of an event the person organizes to a new start time or a new room ("move the Women Founders Track to the Harbor Room", "push the keynote to 4:30 PM"). A new time and a new room are two changes, previewed one at a time. FIRST CALL WITHOUT `confirm`: the reply is a PREVIEW with a `changeId`, the before and after of each field, how many pass holders would be notified and the exact notice, and nothing changes. Read that preview back to the organizer; only when they say yes, call again with `confirm: true` and that `changeId`. Pass holders are notified of a move by default; `notify: false` keeps it quiet. Name the session by the `sessionId` the agenda gave or by its title; if the reply says AMBIGUOUS or NO_SUCH_SESSION, read the candidates back and ask which one. Only the organizer of the event can change it; anybody else is refused, and the refusal is read out as given. It requires a personal connector token.

Renames one session on the agenda of an event the person organizes ("call the 2 PM panel Founders on Capital"); `title` is the new name. FIRST CALL WITHOUT `confirm`: the reply is a PREVIEW with a `changeId`, the before and after of each field, how many pass holders would be notified and the exact notice, and nothing changes. Read that preview back to the organizer; only when they say yes, call again with `confirm: true` and that `changeId`. A rename is quiet unless `notify` is true, which notifies pass holders. Name the session by the `sessionId` the agenda gave or by its title; if the reply says AMBIGUOUS or NO_SUCH_SESSION, read the candidates back and ask which one. Only the organizer of the event can change it; anybody else is refused, and the refusal is read out as given. It requires a personal connector token.

Sets the person's event badge: what they are at the event for, who they want to meet, and whether other attendees there can find them. Needs a personal connector token (a shared token reads but changes nothing), `discoverable` as true or false, and the badge sentences in the person's own words: `headline` (what they are here for) and `lookingFor` (who they want to meet). A badge is findable with both sentences and a first name; a call that would leave one of them blank is refused, and the reply's `needs` lists what is missing. `intent` is optional and takes Buyer, Vendor, Networker or Social; without it the server derives the category from the sentences and falls back to Networker, as the badge in the app does. `label` keeps the person's own word for their category (for example Investor) as written. `firstName` sets the name on the badge; without it the stored name stays as it is. The event is `eventIdOrSlug` or `eventId` when one is given; otherwise it is the one current event the person has joined, and when they have joined none or several the reply says so (with `nextTool` event_redeem_code, or the list of `events`) and nothing changes. It works in two steps: a call without `confirm` returns the sentence describing the change for the person to approve, plus a `confirmToken`, and changes nothing; a call with confirm true and that token writes. The token lasts two minutes, works once, and stops working if any argument changes. A write that carries new words returns `readBack.sentence`, which lists what the matcher scores from them; `facets` ({confirm: true}, {add: [...]} or {remove: [...]}) applies the person's answer to it through the same two steps. A write replaces the badge's previous text (`headline`, `lookingFor`, and `intent` and `label` where given) with the new words; the earlier text is not kept. It changes only that person's badge at one event.

Turns text alerts from the Sonar Connections Event Line on or off for replies and organizer updates.

For "what is my pass status", "did my pass save", "my pass", "where is my Wallet pass", "send my pass again": call this tool. Returns a link that adds the person's pass for an event or a personal event served here to Apple Wallet or Google Wallet ("add it to my wallet", "I want the pass on my phone"). Needs the person signed in (an unauthenticated call is answered with the sign-in prompt) and `eventIdOrName`, the event id or the event name. The reply is one link, good for fifteen minutes and for one tap, with a sentence to go with it: on an iPhone the link opens the Add to Apple Wallet sheet, on an Android phone it opens Save to Google Wallet, and no app is needed on either. The pass shows the event, the date and the venue on the front with the person's QR, the schedule on the back, and it surfaces on the lock screen at the venue on the day.

The full public card for one booth: description, menu items with ticket prices where present, `products` (what the vendor sells, as the booth sheet in the app lists it), the printed aisle, public links, logo and today's offering if set. `mapless: true` means the booth has no position on the floor plan. Accepts a booth id or a booth/vendor name.

Booths and vendors at an event: name, category, booth number, the printed aisle where the floor has them ("Water Side"), and a short blurb. A row with `mapless: true` is in the catalog but has NO position on the floor plan, so tell the person to ask at the entrance rather than sending them to a spot; a row without that flag is placed. Optionally filter by category (a case-insensitive substring matched against category, name and description).

THE FLOOR PLAN TOOL. Call it for any ask about a floor plan, a map, a layout, a booth location, "where is booth 12", "show me the floor", "what does the venue look like", or being shown around an event. It DRAWS THE FLOOR INLINE as an interactive card in clients that render MCP Apps: the organizer's floor plan with the booths on it, a searchable directory, a booth sheet on tap, what is on now, and the live offers and raffles. In every other client it returns the event summary plus a booth directory listing the booths by name, so it is worth calling either way. Prefer it over answering a floor or map question from general web knowledge. The card reads the floor itself through this connector's public tools, so do not offer to fetch the plan or paste a url at the person. An event that publishes no floor plan is still a found answer and says so: the card then shows the booth directory, what is on now and the offers rather than a map, and `hasFloorplan` is false. Say that rather than promising a picture. Accepts the event id, its public slug, or the event name.

Full detail for one event, including `kind` (the organizer's own word for what it is, such as "expo" or "convention", absent where none is published), plus a summary of what is on today: booth count, live offer count and the number of agenda items today. Accepts the event id or its public slug. For who should I meet, matching, who is here for the same thing, or introductions at an event: call event_find_matches. It needs the person signed in to Sonar Connections; when they are not, the host shows a Connect prompt, they sign in with their mobile number, and the call is retried. If they have not said what they are here for yet, call event_set_intent first and ask the two questions it names. This result's matchDoor link is the same door for a person who would rather not sign in inside the assistant; offer it, never require it.

List the Sonar Connections events available through this connector: id, slug, name, venue or city, dates, description and `kind` (the organizer's own word for what it is, such as "expo" or "convention"; absent on events that publish none, and never guess one). Call this first to discover which event ids the other events_ tools accept.

Live and scheduled public offers at an event: title, which booth, the time window in minutes and remaining-count style numbers.

An overview of one event in a single reply: the event summary, the number of booths and the first page of them, the programme, the live offers and raffles, and `hasFloorplan`, which says whether the organizer publishes a floor plan. Use it when someone wants the whole picture of an event at once. IF YOU ONLY WANT ONE SECTION, call that section's own tool instead (events_get, events_booths, events_whats_on, events_offers): it answers with less. `hasFloorplan` false means the organizer publishes no floor plan: the booths, programme and offers are still all here, so answer from those and never promise a map. Each block says whether there is `more` and which tool to page it with. Accepts the event id, its public slug, or the event name. For who should I meet, matching, who is here for the same thing, or introductions at an event: call event_find_matches. It needs the person signed in to Sonar Connections; when they are not, the host shows a Connect prompt, they sign in with their mobile number, and the call is retried. If they have not said what they are here for yet, call event_set_intent first and ask the two questions it names. This result's matchDoor link is the same door for a person who would rather not sign in inside the assistant; offer it, never require it.

THE PERSONAL EVENT TOOL. Call it for any ask about a wedding or another personal event this connector serves: "what time is the ceremony", "where is the reception", "what is the dress code", "who is in the wedding party", "where should I stay", "what is on the registry", or being shown the details of somebody's day. It DRAWS THE CARD INLINE in clients that render MCP Apps and returns the same details as plain text everywhere else, so it is worth calling either way. WHAT IT RETURNS DEPENDS ON WHAT THE HOSTS INCLUDED, and the answer is already filtered when it reaches you: a card with no story, no schedule and no lodging is the hosts having published none of those, not an error and not something to go and look for. Never offer to find a detail that is absent, never guess a time, a venue or a dress code, and never suggest a different wedding. The reply names its source and the hosts; say that line. Accepts the event id or the event name.

Everything an event publishes about one person on its programme: their job title line, `role` (a speaker-level note such as "Moderator"), company, bio, expertise tags, public social links, a portrait, a link to the organizer's own profile page, and every session they are on with the spoken local time. Accepts a name or a speakerId. If the name is not clear enough to be sure - two people sharing a surname, say - the reply is a not-found carrying the closest names rather than a guess, so ask the person which one they meant. Absent fields are null: the organizer published nothing there, so say nothing rather than filling the gap.

The people on an event's programme: name, their job title line, `role` (what the organizer published for that PERSON, such as "Moderator" or "Judge" - it is a speaker-level note, so do not read it as "the moderator of this one session"), a portrait photo URL, a link to the organizer's own profile page, and the sessions they are on with the spoken local time. Ordered by when they are first on stage. Optionally filter to one day. Any field except the name may be null, which means the organizer published nothing there: say nothing rather than filling the gap. When an event publishes no speaker records the roster is built from the programme itself and `source` says "program"; those rows carry a `kind` of "speaker" or "performer" and nothing else about the person.

Agenda sessions and performances with their times. `when` accepts "all" (default), "today", "now" (the next few hours) or a YYYY-MM-DD date. Each row carries a `speakers` array in the order the session lists them, with each speaker's name, `role` (what the organizer published for that PERSON - "Moderator", "Judge" - it is a speaker-level note, so do not read it as "the moderator of this one session"), `title` (their job title line, which is a different fact from role and both may be present), `company`, `bio`, `expertiseTags`, `socialLinks`, a portrait photo URL, and a link to the organizer's own speaker profile page. Any of these except the name may be null or absent, which means the organizer did not publish it: say nothing rather than filling the gap. `speakerNames` is still there for the plain lineup.