Official MCP RegistryListed
Sonar Connections
Source-attributed events, open data and availability
First seen 2 Oct 2026. Evidence as of 2 Oct 2026.
33
Tools
From an anonymous probe
1
Source listings
Each with its own history
0
Recorded changes
Since first seen
Tools
| Tool | Description | Behaviour |
|---|---|---|
| biz_availability | 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. | Read-only |
| biz_book | BOOK one open slot at a business served through this connector. Give a slotId from biz_availability, a service from biz_info, and the FIRST NAME of the person the appointment is for. This tool writes: the slot is taken afterwards and a second attempt on the same slot is refused with alternatives. It accepts a first name and nothing else, by design: do not ask the user for a phone number, an email address or a surname, because there is nowhere to put one. 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 honest explanation with its hours instead of a booking. Booking a business whose `schedulingSystem` is Square writes the appointment 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 we cannot place is refused with the list of businesses we do serve, never answered about a different one. | Changes data |
| biz_info | 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. | Read-only |
| biz_menu | 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. | Read-only |
| biz_order | PLACE a pickup pre-order at a business served through this connector. Call it for checkout: placing an order, placing a pickup order, or confirming an order after biz_menu. Give items (id and qty) from biz_menu, a pickupWindowId from biz_menu, and the FIRST NAME of the person collecting. This tool writes: the order is in the book afterwards and the pickup window is one order fuller. It accepts a first name and an optional short note, and NOTHING ELSE, by design: do not ask the user for a phone number, an email address, a surname or a card, because there is nowhere to put one and the note is scrubbed of contact details server side. This connector never asks for a card and has nowhere to put one. 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 result comes back with 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. GIVE THE USER THE payUrl EXACTLY AS RETURNED and never a link to any other host; 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 honest 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 we cannot place is refused with the list of businesses we do serve, never answered about a different one. | Changes data |
| biz_order_status | 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. | Read-only |
| biz_set_item_availability | Mark one item on a business menu as sold out for today, or put it back on. Anyone reading that menu afterwards sees the change, and an order for a sold-out item is refused. TWO CALLS, ALWAYS: call it first with no `confirm` to get a preview of exactly which item will change and what it will read as, plus a `confirmToken`; show that preview to the person; then call it again with confirm true and that token to make the change. The token lasts two minutes, works once, and stops working if any argument changes. It requires a personal connector token: a shared one can read but cannot change anything. Only a business you are seated on as an owner or a manager can be changed, checked against live records every time. Name the item with `itemId` from biz_menu when you have one. `itemName` is accepted and is matched against that menu: a name that fits more than one item is REFUSED with the names it fits, never guessed at, because several items on one menu can share a word. | Changes data |
| biz_storefront | 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. | Read-only |
| booth_set_away | Mark a booth you staff as stepped away, or back. Attendees looking at that booth see the presence state change. TWO CALLS, ALWAYS: call it first with no `confirm` to get a preview of exactly what will change plus a `confirmToken`, show that preview to the person, then call it again with confirm true and that token to make the change. The token lasts two minutes, works once, and stops working if any argument changes. It requires a personal connector token: a shared one can read but cannot change anything. Only a booth you own, administer or staff at that event can be changed, checked against live records every time. | Changes data |
| city_calendar | 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. | Read-only |
| city_datasets | 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. | Read-only |
| city_gis | 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-only |
| city_records | 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. | Read-only |
| city_sweeping | 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. | Read-only |
| event_accept | Accept a hello the person has received, which opens a conversation with that person. Use it for "accept Dana", "yes, connect me with Jo", "say yes to her". Name the hello with `firstName` exactly as an event_requests row spelled it, or with that row's `requestId`; never invent either. CONFIRM FIRST: say whose hello you are accepting and get a yes. A `firstName` that matches two waiting hellos comes back AMBIGUOUS_NAME and accepts nothing, and you ask which one they mean. It accepts only hellos addressed to the caller: the server re-checks that and refuses with NOT_RECEIVER otherwise. Accepting twice is harmless. On ok:true say the conversation is open and that they can read and reply with event_inbox and event_reply; do not say anything about what the other person will do. It requires a personal connector token. | Changes data |
| event_find_matches | The people at an event the person is at whose stated intent fits theirs. Use it for "who should I meet", "who here is looking for investors", "who is checked in that matches what I am here for", "any buyers on the floor". Each row carries a first name, their intent, the one line they wrote about what they are looking for, and the booth they staff when they are a vendor. It carries no phone number, no email address, no surname, no account id and no photo: those are not on this surface. It answers only about people who finished a badge at that event and chose to be findable by other attendees, and it returns at most 20 of them, so a longer floor comes back as the first 20 with `truncated` true. Rows are RANKED by what each person actually WROTE on their badge, not only by their category: the server scores the one line and the interests they declared against the caller's own, and each row carries `fit` and `why`. `fit` IS ONE OF THREE WORDS and it is the whole of what the strength of a match may be called: "strong" means most of what the caller declared is echoed on the other side, "good" means a real overlap worth walking over for, and "some" means they are on the list for a reason and no more than that. `why` is one sentence composed by the server: it OPENS with that same fit and then names the words the two of them share and how the categories relate. When they share no word at all the `why` names the TOPIC they both wrote about instead, from the server's own list of topics, so a person who wrote about swimming pools and a person who wrote about pool accessories are told they both wrote about pools. READ THE `fit` AND THE `why` OUT, exactly as the row gives them, and never invent a different reason, and never guess a topic the `why` did not name. SAY ONLY WHAT THIS REPLY CARRIES: do not add how to find a person, whether the list is complete, who else might be there, what will happen next or why somebody is or is not on it, because every one of those is a guess about a floor this reply does not describe. Two buyers whose lines agree ARE matches for each other; a buyer and a vendor with nothing written still surface, because the complementary pair (buyers with vendors and networkers, vendors with buyers and networkers) counts toward the ranking. THERE IS NO NUMBER ON THIS SURFACE, and none may be supplied for it: never state a score, a percentage, a rating out of anything, a rank or a place in the list for anybody, and never turn a fit word back into one. The rows are already ordered, best fit first, which is all the ordering anyone needs to be told. If the person has not said what they are there for it comes back with `needsIntent` true and no rows: call event_set_intent first. Reading this list does not require being findable oneself, and the reply says which the caller is. WHEN IT COMES BACK EMPTY IT SAYS WHY, and the reason is the server's rather than yours: a reply with no rows carries `emptyReason`, one of four words, and a `message` that states it in plain language. STATE THAT REASON AS GIVEN AND NEVER SUBSTITUTE ONE OF YOUR OWN. `none_findable` means nobody else at that event has chosen to be findable by other attendees. `none_present` means people there are findable but none of their badges has been set or updated inside the event's own window, so none of them counts as being there. `event_not_live` means the event is not inside its own dates right now and no badge was set inside them. `no_text_match` means there are people there but none of them is close enough to what this person said they are there for. Do not infer a reason the reply does not give: not the dates, not who has arrived, not travel, not timing. | Read-only |
| event_inbox | The person's own conversations with people they have connected with at an event, and the last few lines of one of them. Use it for "any messages", "did Jo reply", "what did Dana say", "read my inbox". Called 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 they have not read. Called with `firstName` or `chatId` it returns the last few lines of that one conversation, oldest first, each line saying only whether it was theirs, what it said and when. It carries no phone number, no email address, no surname, no account id and no photo: those are not on this surface. IT READS ONLY THE CALLER'S OWN CONVERSATIONS and the server re-checks that on every call, so a conversation they are not in comes back refused with NOT_PARTICIPANT rather than empty. A `firstName` is matched against THEIR OWN THREADS ONLY: if two of them answer to it the reply is AMBIGUOUS_NAME and names neither, and you ask which one they mean rather than choosing. If none does it is NAME_NOT_IN_THREADS, and you say you cannot see a conversation with that person. SHOW FIRST NAMES AND READ THE LINES OUT AS GIVEN. Say only what the reply carries: never guess who somebody is, what they meant, whether they are still at the event, or what is in a thread this reply did not return. Reading a conversation MARKS IT READ for that person, exactly as opening it in the app or on the web does. It requires a personal connector token: a shared one cannot reach anybody's conversations at all. | Read-only |
| event_redeem_code | Join an event with a code the person was given, on a badge, a poster, an email or at a door. THE CODE IS THE ONLY THING TO PASS: it names its own event, so never ask which event a code is for and never ask for an event id. TWO CALLS, ALWAYS: call it first with no `confirm` to get back the event the code opens and the seat it gives plus a `confirmToken`, show that to the person, then call it again with confirm true and that token to take the seat. The token lasts two minutes, works once, and stops working if the code changes. It requires a personal connector token: a shared one can read but cannot change anything. Redeeming works from anywhere, not only at the venue. | Changes data |
| event_reply | Send one message into a conversation the person already has with somebody they connected with at an event. Use it for "reply to Dana", "tell Jo I am on my way", "answer her". Name the conversation with `firstName`, exactly as event_inbox spelled it, or with the `chatId` event_inbox returned; never invent either, and never send to a name you have not read off a thread. `text` is the PERSON'S OWN WORDS: send what they said and do not tidy it, shorten it or improve it. CONFIRM BEFORE SENDING, ALWAYS: show the person the message and the first name it is going to and get a yes, because the message is delivered the moment this returns and nothing can unsend it. If they have not said what to send, ask them - never write a message on somebody's behalf. It sends as that person, into their own conversation, and it can reach nobody they are not already talking to: the server re-checks that on every call and refuses with NOT_PARTICIPANT otherwise. A `firstName` that matches two of their conversations comes back AMBIGUOUS_NAME and sends nothing, and you ask which one they mean. The same cooldown, flood limit and content rules the app's own send has apply here, because it is the same send: RATE_LIMITED means they are sending too fast and should wait a moment. On ok:true say it was sent and nothing more - do not promise a reply, do not say when one will come, and do not claim the other person has read it. It requires a personal connector token: a shared one can read nothing here and can send nothing. | Changes data |
| event_requests | Who wants to meet the person: the hellos waiting on them at an event, newest first. Use it for "who wants to meet me", "any requests", "did anyone say hello". Each row carries the other person's FIRST NAME, their here-for line in their own words, and when the hello landed, plus a requestId to accept it with. It carries no phone number, no email address, no surname, no account id and no photo. It reads only the CALLER'S OWN pending hellos. Name people by the first name on the row and read the here-for line as given; never guess who somebody is or why they said hello. To accept one, confirm the first name with the person and call event_accept. It requires a personal connector token. | Read-only |
| event_say_hello | Say hello to somebody the person has been shown in their event matches: it sends that person a connection request from them, and when it is accepted a conversation opens that both can read and answer from the app, the web page or an assistant. Use it for "say hello to Jo", "introduce me to her", "how do I message him". Pass the FIRST NAME exactly as an event_find_matches row spelled it and nothing else: there is no account id on this surface and you must never invent one. The person must be in their CURRENT MATCH POOL and the server re-checks that on every call. CONFIRM FIRST: say who the hello is going to and get a yes, because it reaches another person. Reasons to read out as given: "not_in_pool" means you cannot see them in their matches, so offer to list them again; "ambiguous" means two people there answer to that name, so ask which one and never pick; "already_sent" means the hello is already out; "no_seat" means they are not seated at an event; "rate_limited" means they have said hello to a lot of people today. On success say the reply's own `message` and nothing more: do not promise they will accept, do not say when, and do not claim a conversation is open. It requires a personal connector token. | Changes data |
| event_set_intent | Set what the person is at an event for, and whether other attendees there may find them. Use it for "set my intent", "I am here to buy", "tell people I am looking for investors", "make me findable". ASK TWO QUESTIONS AND PASS BOTH ANSWERS IN THEIR OWN WORDS: "What are you here for?" is `headline`, and "Who do you want to meet?" is `lookingFor`. THOSE TWO SENTENCES ARE THE BADGE. Together with their name they are the whole of what makes a person findable at this event, and they are what the matcher reads to decide who they are shown to, so ask both, pass both, and do not compress them, tidy them or invent them. `intent` is OPTIONAL and is a quick pick rather than a question you owe: pass one of Buyer, Vendor, Networker or Social only when the person actually said one of those words, and otherwise leave it out, because the server works the category out from what they wrote and falls back to Networker exactly as their badge in the app does. IF THEY NAME A CATEGORY OF THEIR OWN - "investor", "director", anything - pass it as `label` and it is kept as their word rather than refused; never talk them out of it and never map it onto one of the four yourself. `discoverable` is a SEPARATE and REQUIRED answer and is never inferred from the intent: ask the person, because true puts them in the list other attendees can see and false keeps them out of it. TWO CALLS, ALWAYS: call it first with no `confirm` to get back a sentence saying exactly what will change plus a `confirmToken`, show that sentence to the person, then call it again with confirm true and that token. The token lasts two minutes, works once, and stops working if any argument changes. It requires a personal connector token: a shared one can read but cannot change anything. It changes that one person's badge at one event and reaches nobody else's. A badge with one of the two sentences still blank cannot be found by anybody yet, so it is refused naming the sentence that is missing rather than written. CLOUD 181a: `firstName` IS THE THIRD THING THE BADGE IS MADE OF, beside the two sentences above, and it is OPTIONAL in the same way they are. Pass it when the person has just told you their name or asked to change it and leave it out every other time: an omitted name leaves theirs alone and an invented one would rename them. Until this unit there was no door onto that field outside the app, which is why a person who had only ever used an assistant or a browser could not finish a badge however many sentences they wrote. A name the badge cannot take refuses the whole call rather than writing half of it, and the refusal says which thing was wrong with it. | Changes data |
| events_booth_detail | 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. | Read-only |
| events_booths | 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). | Read-only |
| events_floor_card | 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. | Read-only |
| events_get | 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. | Read-only |
| events_list | 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. | Read-only |
| events_offers | Live and scheduled public offers at an event: title, which booth, the time window in minutes and remaining-count style numbers. | Read-only |
| events_overview | 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. | Read-only |
| events_speaker_detail | 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. | Read-only |
| events_speakers | 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. | Read-only |
| events_whats_on | 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. | Read-only |
| ui_card_diag | Used only by the interactive cards this connector draws, never to answer a question. A card view posts its own lifecycle markers here in small batches: that it mounted, which display mode and safe-area insets the host gave it, the heights it reported, whether a keyboard opened, and the outcome of the one action a person took on it. It accepts a closed vocabulary of markers and integer counts only, no free text of any kind, and it returns nothing but an acknowledgement. NOT FOR A MODEL TO CALL: it answers no question and looks nothing up. Call a data tool instead. | Changes data |
Change history
No changes since the first observation. The first snapshot is the baseline.
| Source | Listing | First seen | Last seen | Versions |
|---|---|---|---|---|
| Official MCP Registry | com.sonarconnections/sonar-connections | 2 Oct 2026 | 2 Oct 2026 | 1 |