Sonar Connections

Server Details

Source-attributed events, open data and availability

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 20 days
Last Tested: 2026-10-11 17:44
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-10-07 10:20 across 37 tools

Disambiguation4/5

Most tools have clearly distinct purposes—booking vs ordering vs event matching vs city data—and descriptions actively cross-reference each other (biz_info points to biz_storefront; events_overview says to call section tools instead). Some overlap remains among the many events_* content tools (events_get vs events_overview, events_speakers vs events_speaker_detail) and the singular event_ / plural events_ split could trip an inattentive agent, but the descriptions largely resolve it.

Naming Consistency4/5

All tool names are snake_case with consistent domain prefixes (biz_, city_, event_, events_, booth_, ui_), and no mixed conventions appear. The singular event_ vs plural events_ distinction is subtle but appears intentional, and a few names are noun-only rather than verb_noun, so it is not quite a perfect pattern.

Tool Count2/5

37 tools is a heavy surface that exceeds the 25+ threshold for an oversized set, even given the server's broad multi-domain scope across local businesses, city open data, and events. Including a diagnostic tool the model is explicitly told never to call (ui_card_diag) further weakens the set's focus.

Completeness4/5

The surface covers a great deal: business info/availability/booking/menu/orders/storefront, city datasets/GIS/calendar/sweeping, and event content plus attendee matching, messaging, wallet passes, and booth interactions. Minor lifecycle gaps remain—no booking or order cancellation/reschedule and limited write paths for business owners—but core workflows are well represented.

Available Tools

43 tools

biz_availabilityList open appointment slots

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`date`	No	YYYY-MM-DD, defaults to today in the business timezone
`business`	No	Which business, BY NAME OR BY ID. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental). Optional, defaults to velvetandclay. A common short form works too ("the bakehouse", "the dentist"). A name that does not clearly match one of these is REFUSED with the list, and it is not answered about a different business.
`businessId`	No	Alias for `business`, accepted because every reply carries this name. Takes a NAME OR AN ID, exactly like `business`. Ignored when `business` is also given.

biz_bookBook an appointment slotInspect

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.

ParametersJSON Schema

Name	Required	Description
`slotId`	Yes	A slotId from biz_availability, e.g. 2026-08-31T10:00
`service`	Yes	A service id or name from biz_info, e.g. "Cut and finish"
`business`	No	Which business, BY NAME OR BY ID. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental). Optional, defaults to velvetandclay. A common short form works too ("the bakehouse", "the dentist"). A name that does not clearly match one of these is REFUSED with the list, and it is not answered about a different business.
`firstName`	Yes	First name only. No surname, phone number or email address.
`businessId`	No	Alias for `business`, accepted because every reply carries this name. Takes a NAME OR AN ID, exactly like `business`. Ignored when `business` is also given.

biz_infoBusiness details, services and hours

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`business`	No	Which business, BY NAME OR BY ID. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental), Long Beach Brunch Bakehouse (longbeachbrunch), Make Collectives (makecollectives), Kristin Dunn Bookbinding and Design (kdbooks). Optional, defaults to velvetandclay. A common short form works too ("the bakehouse", "the dentist"). A name that does not clearly match one of these is REFUSED with the list, and it is not answered about a different business.
`businessId`	No	Alias for `business`, accepted because every reply carries this name. Takes a NAME OR AN ID, exactly like `business`. Ignored when `business` is also given.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`found`	No
`isDemo`	No
`message`	No
`bookable`	No
`business`	No
`hoursNow`	No
`servedBy`	No
`available`	No
`openToday`	No
`sourceUrl`	No
`businessId`	No
`todaysHours`	No
`otherBusinesses`	No

biz_menuPickup menu and times

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`date`	No	YYYY-MM-DD, defaults to today in the business timezone. Pickup windows for this date ride along with the menu.
`business`	No	Which business, BY NAME OR BY ID. Available: Long Beach Brunch Bakehouse (longbeachbrunch). The default (velvetandclay) has no pickup menu here, so NAME THE BUSINESS: an omitted argument is refused. A common short form works too ("the bakehouse", "the dentist"). A name that does not clearly match one of these is REFUSED with the list, and it is not answered about a different business.
`businessId`	No	Alias for `business`, accepted because every reply carries this name. Takes a NAME OR AN ID, exactly like `business`. Ignored when `business` is also given.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`open`	No
`error`	No
`found`	No
`notes`	No
`isDemo`	No
`message`	No
`servedBy`	No
`available`	No
`sourceUrl`	No
`businessId`	No
`categories`	No
`closedReason`	No
`pickupWindows`	No
`openWindowCount`	No

biz_orderPlace a pickup orderInspect

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/: 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.

ParametersJSON Schema

Name	Required	Description
`note`	No	Optional short preparation note, 140 characters, e.g. "no nuts" or "happy birthday Ada". Contact details are removed server side: this is not a message channel.
`items`	Yes	The order lines. At least one.
`business`	No	Which business, BY NAME OR BY ID. Available: Long Beach Brunch Bakehouse (longbeachbrunch). The default (velvetandclay) takes no pickup orders, so NAME THE BUSINESS: an omitted argument is refused. A common short form works too ("the bakehouse", "the dentist"). A name that does not clearly match one of these is REFUSED with the list, and it is not answered about a different business.
`firstName`	Yes	First name only. No surname, phone number or email address.
`businessId`	No	Alias for `business`, accepted because every reply carries this name. Takes a NAME OR AN ID, exactly like `business`. Ignored when `business` is also given.
`pickupWindowId`	Yes	A window id from biz_menu, e.g. 2026-09-10T10:00

biz_order_statusCheck pickup order paymentA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`confirmationCode`	Yes	The order confirmation code, e.g. LBB-KKA8Y2. Case does not matter.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/destructiveHint=false, and the description reinforces 'It changes nothing' plus adds genuinely new behavioral detail: the exact set of returned fields, explicit exclusions (no customer name, items, payment link), and the not-found outcome for an unknown code. It does not cover rate limits or latency, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the return payload, then usage, then the negative case; every clause carries information. It is a single dense paragraph with colon-separated lists, which is slightly harder to scan than a tighter two- or three-sentence form, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-shape burden and does so fully (state, payment state, PAID flag, pickup window, business name, total), plus the not-found behavior and the read-only guarantee. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents the format (LBB-KKA8Y2) and case-insensitivity, so the baseline is 3. The description adds provenance the schema lacks — that the code is the one returned by biz_order — which meaningfully helps an agent obtain a valid value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read the CURRENT state of a pickup order ... by its confirmation code') and pins the scope to orders placed through this connector. The mention of the 'LBB-XXXXXX style code biz_order returned' cleanly distinguishes it from the sibling that creates the order.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear triggering condition: use it after a customer has been sent to a checkout page, to confirm whether payment landed and the order is placed. It does not explicitly name when-not to use it or point to a named alternative, so it stops just short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

biz_set_item_availabilitySet menu item availability

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`itemId`	No	The menu item id, as biz_menu returned it. An id matches exactly one item.
`confirm`	No	Absent on the first call, which changes nothing. true, together with confirmToken, makes the change.
`soldOut`	Yes	true to mark the item sold out for today, false to put it back on the menu.
`business`	Yes	Which business, by name or by id, as biz_menu returned it. Only a business the person is seated on can be changed.
`itemName`	No	The item by name, when no id is at hand. Matched against that menu; a name that fits more than one item is refused with the names it fits.
`requestId`	No	An id for this change chosen by the caller, at least 8 characters. A repeat with the same id and the same arguments returns the first result without changing anything a second time.
`confirmToken`	No	The token the first call returned. Needed when confirm is true.

biz_storefrontShop catalog, prices and availability

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`page`	No	Which page of the catalog, 1-based. Optional, defaults to 1. Each page holds up to 60 products; the reply carries pageCount and total so you can say which page you are reading and ask for the next one. A page past the end answers with no products and the true pageCount rather than an error.
`limit`	No	How many products to return, 1 to 60. Optional, defaults to 60. A larger number is clamped rather than refused.
`query`	No	Free text to narrow the catalog to, matched against the product title, the brand, the product type and the handle. Optional; omit it for the whole shop. It only ever removes products and never reorders them.
`business`	No	Which business, BY NAME OR BY ID. Available: Make Collectives (makecollectives), Kristin Dunn Bookbinding and Design (kdbooks). The default (velvetandclay) publishes no shop catalog we read, so NAME THE BUSINESS: an omitted argument is refused. A common short form works too ("the bakehouse", "the dentist"). A name that does not clearly match one of these is REFUSED with the list, and it is not answered about a different business.
`businessId`	No	Alias for `business`, accepted because every reply carries this name. Takes a NAME OR AN ID, exactly like `business`. Ignored when `business` is also given.

booth_set_awayMark a booth away

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`away`	Yes	true to mark the booth stepped away, false to mark it back.
`boothId`	Yes	The booth id, exactly as events_booths returned it. Not the booth name.
`confirm`	No	Absent on the first call, which changes nothing. true, together with confirmToken, makes the change.
`eventId`	Yes	The event the booth is at, exactly as events_list returned it.
`requestId`	No	An id for this change chosen by the caller, at least 8 characters. A repeat with the same id and the same arguments returns the first result without changing anything a second time.
`confirmToken`	No	The token the first call returned. Needed when confirm is true.

city_calendarPublic events calendarA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`days`	No	How many days ahead to read, 1 to 60 (default 14)
`limit`	No	Events to return, 1 to 50 (default 10)
`search`	No	Match a word across event title, description, location and department
`department`	No	Filter by city department or calendar, e.g. "Long Beach Public Library"

TDQS

A3.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, yet the description adds substantial context beyond them: data comes from the publisher's JSON feed rather than scraping, responses carry source and license state, times are wall-clock strings with UTC offset and are never converted, and cancelled events are returned and marked rather than hidden. That is exactly the kind of return-behavior disclosure annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the provenance point is stated twice ('every response says so' and 'Every response names the City of Long Beach as its source') and the sentence about the license state is vague. Several sentences earn their place (time format, cancelled events), yet the redundant provenance claims dilute it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does well: it covers provenance, license, time encoding and cancelled-event handling, plus explicit coverage limits. It stops short of describing the response's overall shape or how limit/days interact with the returned set, which keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and all four parameters (days, limit, search, department) are documented with ranges and defaults in the schema itself. The description adds no parameter-level detail such as search semantics or department naming conventions, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Upcoming public events run by the City of Long Beach') and enumerates the event categories covered, so an agent knows exactly what domain this serves. It never names or contrasts against siblings such as events_list or events_whats_on, so the differentiation is left to inference from the city scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The closing 'Coverage today: the City of Long Beach public events calendar, one publisher' implies when the tool is applicable, but there is no explicit when-to-use/when-not statement and no alternative named for non-city events. Usage is implied rather than guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

city_datasetsList public open datasetsA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`source`	No	Data source id, e.g. "longbeach" (default)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnly/openWorld/non-destructive; the description adds behavioral context by specifying the default source ('longbeach'/DataLB), that every response names its source, and that it returns all datasets with specific fields. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler: purpose, usage, and parameter default are each addressed once and front-loaded. Every sentence adds information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only catalog tool with one optional parameter and no output schema, the description covers return fields, default source, and relationship to city_records. It doesn't specify response envelope or pagination, but annotations and low complexity keep that from being a critical gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already documents source with a default example. The description reinforces that source is optional and defaults to 'longbeach', adding minor context (DataLB portal name) but not carrying the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('public open datasets'/'open data catalog'), enumerates the returned fields, and distinguishes itself from city_records by framing it as the discovery step for dataset ids. This is more than the title alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'Call this first to discover which dataset ids city_records accepts,' giving a clear when-to-use. It doesn't enumerate exclusions or alternatives beyond city_records, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

city_gisCity map layersA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`layer`	No	Layer index within the service (default 0)
`limit`	No	Results to return, 1 to 50 (default 10)
`filter`	No	Match a word across the layer text fields, e.g. a street or a name
`search`	No	Find layers by topic, e.g. "zoning", "parks", "bike"
`source`	No	Which city GIS: "longbeach" or "huntingtonbeach" (default longbeach)
`item_id`	No	ArcGIS item id from a search result, to read that layer

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/openWorld/non-destructive, and the description adds substantial context beyond them: it never returns raw geometry, privacy-screening logic that returns schema+counts only for person-like fields and Survey123 layers, live reads from the publisher, and license/source attribution per response. It even explains false-positive behavior of the screen.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but well-organized with labeled sections (SOURCES, HOW TO USE IT, WHAT IT WILL NOT DO). Front-loads the purpose. It is longer than strictly necessary and the closing coverage sentence repeats earlier content, but nearly every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by describing what a read returns (field schema, row count, capped sample rows) and what search returns (result count with refused-result reporting). For a 6-parameter, open-world read tool this is complete enough to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning: `source` defaults to longbeach and must match between search and read calls, `item_id` comes from a search result, and `filter` matches a word across text fields while `limit` caps rows. It goes beyond restating the schema by explaining how parameters interrelate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Search and read a city GIS') and names the concrete coverage (parcels, zoning, permits, etc.) plus the two ArcGIS organizations. It is clearly distinguishable from siblings like city_datasets and city_records, which cover different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit workflow: call with `search` to find layers and item ids, then call with `item_id` AND the same `source` to read one layer. It also states the default source and the fallback behavior, leaving nothing to inference about when to use which mode.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

city_recordsRead open data recordsA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Rows to return, 1 to 50 (default 10)
`offset`	No	Rows to skip, for paging. Use the `nextOffset` from a previous call. 0 to 1000; deeper paging is not served (download the full file from the city portal instead).
`search`	No	Optional full-text search across the records
`source`	No	Data source id, e.g. "longbeach" (default)
`dataset_id`	Yes	Dataset id from city_datasets, e.g. "service-requests"

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds crucial non-obvious behavior: truncation indicators in the response, pagination via nextOffset, a limit ceiling, deeper-paging limit (offset max 1000) with fallback instruction (download full file). This is rich behavioral context beyond structured fields and absent an output schema, which is exactly what the description must supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then the required parameter, then pagination behavior, then optional source. Efficient and ordered for an agent. Slightly dense but every clause carries information (defaults, caps, pagination fields, source default).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A read/pagination tool with sibling city_datasets and no output schema. The description covers the required input source, pagination mechanics (truncated/matchingRecords/nextOffset), limits, and the source default. This is complete for correct invocation and continuation without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents limit (1-50, default 10), offset semantics, search, source default, and dataset_id source. The description echoes the defaults and the limit ceiling but adds no syntax or format beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (read) and resource (one page of records from a public open dataset), and distinguishes from city_datasets by name and role ('Give a dataset_id from city_datasets'). An agent can tell this is the record-fetching tool versus the dataset-listing tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains when pagination is needed ('a full page is usually NOT the whole answer') and names the fields to use for continuation ('truncated', 'matchingRecords', 'nextOffset'). Names the dependency on city_datasets for dataset_id. No exclusions but the usage path is fully specified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

city_sweepingStreet sweeping scheduleA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`day`	No	Day filter, e.g. "Tuesday". The published data covers Monday to Friday only.
`limit`	No	Distinct schedules to return, 1 to 25 (default 10)
`street`	No	Long Beach street name, e.g. "Pine Ave" or "East Ocean Blvd". Resolved against the City street centerline layer.

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, yet the description adds substantial non-obvious behavior: responses carry source attribution and license state, the layer lacks street name/side/route attributes, street lookups are answered via centerline-to-polygon intersection, and ambiguous two-day values are reported as published rather than guessed. These are real operational constraints an agent could not infer from the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is valuable but the prose is bloated and partly repetitive, stating twice that every response names its source and license state, and opening with provenance before the core purpose. It is reasonably front-loaded but several sentences could be compressed without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of explaining returns, and it does describe the semantic content of an answer (named zones, uninterpreted two-day values, source and license). It does not enumerate concrete response fields, but for a single-publisher read-only tool it is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all three parameters and the baseline would be 3. The description adds genuine meaning beyond that: it clarifies the resolution mechanism for `street` (City street centerlines intersected with zone polygons) and the shape of the result, and reinforces that `day` is limited to the published Monday-Friday range.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns City of Long Beach street sweeping schedules read live from the City's published ArcGIS feature service. It also pins down exactly what the data is (336 polygons with only DAYS and HOUR attributes). It stops short of naming a sibling (e.g. city_gis or city_datasets) as the alternative for broader queries, so it does not fully differentiate within the city_* family.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete invocation guidance: call with `street`, with `day`, with both, or with neither to see every published schedule, and explains that a street lookup returns the zones a street runs through rather than one schedule per address. That is clear usage context, but there is no explicit when-not or pointer to an alternative tool for cases this tool can't answer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

event_acceptAccept a hello

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`firstName`	No	Optional. The first name as an event_requests row spelled it, matched against the caller's own pending hellos only. Two matches return AMBIGUOUS_NAME and nothing is accepted.
`requestId`	No	Optional. The requestId as an event_requests row gave it. When both this and firstName are sent, this one is used.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`error`	No
`chatId`	No
`message`	No
`requests`	No
`servedBy`	No
`candidates`	No

event_changeChange an event's agenda (organizers only)

Idempotent

Inspect

THE ORGANIZER'S OWN CHANGE TO THEIR EVENT. Call it when the organizer of an event wants to change its agenda: move a session to a new time or room, rename it, cancel it, or add a session ("move the Women Founders Track to the Harbor Room"). 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 and ask; only when they say yes, call again with confirm: true and that changeId. 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. Never invent a sessionId. Only the organizer of the event can change it; anybody else is refused, and you read the refusal out as given. It requires a personal connector token.

ParametersJSON Schema

Name	Required	Description
`at`	No	OPTIONAL. The session's current start ("10:30 AM"), to tell apart sessions with the same title.
`end`	No	The new end, same forms. Left out on move_time, the session keeps its length.
`date`	No	OPTIONAL. The day, YYYY-MM-DD, when the event runs more than one day or the session moves to another day.
`kind`	No	REQUIRED for a preview. move_time (pass `start`, optionally `end` and `date`), move_room (pass `room`), rename (pass `title`), cancel, add_session (pass `title`, `start`, `end`, `room`, optionally `date` and `speakers`).
`room`	No	The room or place label, plain words.
`start`	No	The new start: "4:30 PM", or a full timestamp with a time zone. Read in the event's own time zone.
`title`	No	The new or added session's title.
`notify`	No	OPTIONAL. A time or room move notifies pass holders by default; cancel, rename and add are quiet unless this is true. False keeps any change quiet.
`confirm`	No	Leave out for the PREVIEW. Only after the organizer says yes to the preview, call again with confirm: true and the changeId.
`changeId`	No	REQUIRED with confirm: the changeId the preview returned.
`speakers`	No	OPTIONAL, for add_session: speaker names; a name that matches the event's speakers is linked, any other is kept as a plain name.
`sessionId`	No	The session's id exactly as the agenda or a candidates list gave it. Never made up.
`sessionTitle`	No	Or the session's title as the agenda spells it, when there is no sessionId.
`eventIdOrName`	Yes	REQUIRED. The event id or the event name as the organizer spells it.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`kind`	No
`error`	No
`applied`	No
`changes`	No
`message`	No
`preview`	No
`session`	No
`changeId`	No
`servedBy`	No
`candidates`	No
`lockScreen`	No
`passUpdate`	No

event_change_detailChange one detail of a personal event (hosts only)

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`undo`	No	OPTIONAL. True reverses the CALLER'S OWN most recent change on this event, through the same validation and into the same log. It cannot reverse somebody else's change, cannot reverse an undo, and cannot reverse the same change twice.
`field`	No	WHICH detail to change, one of the named values and nothing else. Required unless `undo` is true. ceremony_time and reception_time take a clock time; ceremony_place and reception_place take the place label in `value` and optionally a venue name in `venueName`; dress_code and arrival_note take a sentence; schedule_time takes a clock time plus `entryTitle`; faq_answer takes an answer plus `question`.
`value`	No	The NEW value, as the hosts would say it. A clock time for the time fields, the place label for the place fields, one sentence for dress_code and arrival_note, the answer for faq_answer. No links and no markup: both are refused. Required unless `undo` is true.
`question`	No	REQUIRED for faq_answer: the question being answered. An exact existing question replaces that answer; a new one is added.
`venueName`	No	OPTIONAL, and only for ceremony_place and reception_place: the name of the venue, when the hosts named one. Left out, the venue already stored is kept rather than cleared.
`entryTitle`	No	REQUIRED for schedule_time: the TITLE of the schedule entry to move, exactly as a schedule row spells it. If two entries answer to it the reply is NO_SUCH_ENTRY and nothing moves, and you ask which one they mean rather than choosing.
`eventIdOrName`	Yes	REQUIRED. The event id (test_wedding_a_garden) or the event NAME as the hosts spell it ("Susie and John").

event_find_matchesFind matching attendees

Read-only

Inspect

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).

ParametersJSON Schema

Name	Required	Description	Default
`eventId`	No	Optional. An event the person has joined. When absent, the event the person is currently in.

event_guest_requestsRead the guests' requests (hosts only)

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`markHandled`	No	OPTIONAL. The `id` of one request, exactly as a row from this same tool gave it. Never construct one. It marks that request handled so it leaves this list; it messages nobody and changes nothing on the event.
`eventIdOrName`	Yes	REQUIRED. The event id or the event NAME as the hosts spell it.

event_inboxRead my messages

Read-onlyIdempotent

Inspect

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. Reading a conversation marks it read for that person, as opening it in the app or on the web does.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Optional. How many lines of one conversation to return, at most 50; 30 when absent. Not used when listing threads, which returns at most 20.
`chatId`	No	Optional. The id of one conversation, as a thread row from this tool gave it. When both this and firstName are sent, this one is used.
`firstName`	No	Optional. The first name of the person whose conversation to read, as a thread row spelled it, matched against the caller's own conversations only. Two matches return AMBIGUOUS_NAME and nothing is read.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`error`	No
`chatId`	No
`unread`	No
`message`	No
`threads`	No
`messages`	No
`returned`	No
`servedBy`	No
`candidates`	No

event_meetup_rsvpAnswer a meetup notice (yes or no)

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`answer`	Yes	REQUIRED. "yes" they are coming, "no" they are not. Nothing else is recorded.
`noticeId`	Yes	REQUIRED. The noticeId of the meetup notice being answered, as the pass or the organizer gave it.
`eventIdOrName`	Yes	REQUIRED. The event id or name.

event_pass_noticeSend a notice to a group of pass holders (hosts and organizers only)

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`at`	No	OPTIONAL, for a meetup: the hour, as a full timestamp with a time zone ("2027-06-12T20:00:00-07:00").
`text`	Yes	REQUIRED. The notice, one plain line of up to 120 characters, in the organizer's words. This exact line is what the lock screen shows. No links, no markup.
`tier`	No	For audience "tier": general, vendor or host.
`intent`	No	For audience "intent": Buyer, Vendor, Networker or Social.
`boothId`	No	For audience "booth" or "my_booth": the booth id.
`confirm`	No	Absent for a preview: the reply gives the number of passes in the group and the exact lock-screen line, and nothing is sent. true sends the notice.
`serials`	No	For audience "serials": the pass serial numbers, at most fifty.
`audience`	Yes	Who the notice is for. "everyone" is every pass of the event; "tier" one ticket tier (with `tier`); "intent" one badge intent (with `intent`); "serials" an explicit list (with `serials`); "booth" the people who scanned at a booth the organizer names (with `boothId`); "meetup_yes" or "meetup_no" the people who answered an earlier meetup notice (with its `noticeId`). "my_booth" is a vendor sending to their own leads; it is switched off by ruling and returns VENDOR_OFF.
`latitude`	No	OPTIONAL, for a meetup: the place's latitude. Both coordinates or neither.
`noticeId`	No	For audience "meetup_yes" or "meetup_no": the noticeId an earlier meetup notice answered with.
`longitude`	No	OPTIONAL, for a meetup: the place's longitude. Both coordinates or neither.
`requestId`	No	Optional. An id for this notice chosen by the caller; one id sends once.
`placeLabel`	No	OPTIONAL, for a meetup: the name of the place ("The Bar on 2nd"). With `latitude` and `longitude` the pass surfaces on the lock screen when the person is near it.
`relevantText`	No	OPTIONAL, for a meetup with coordinates: the line the lock screen shows NEAR the place. Default: "Sonar meetup inside, show this pass."
`eventIdOrName`	Yes	REQUIRED. The event id or the event name as the organizer or the hosts spell it.

event_pass_reissueRefresh or revoke a Wallet pass

DestructiveIdempotent

Inspect

Refreshes or revokes a Wallet pass: 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 or revoked. Needs eventIdOrName (the event id or the event name) and action. action "reissue" gives the pass a new QR code and brings a revoked pass back; the old code stops working at once and the phone shows "Your pass was refreshed. The old code no longer works." action "revoke" voids the pass on the phone: "This pass was revoked and no longer works." Nothing is re-added: the same pass updates in place on an iPhone and on Android. 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.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	REQUIRED. reissue (a new code, and a revoked pass comes back) or revoke (the pass is voided).
`serialNumber`	No	OPTIONAL. The pass serial (on the pass, ps_ and 24 characters). Omit for the caller's own pass.
`eventIdOrName`	Yes	REQUIRED. The event id or the event NAME as the organizer or the hosts spell it.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`error`	No
`action`	No
`message`	No
`reached`	No
`revoked`	No
`servedBy`	No
`idempotent`	No
`tokenVersion`	No

event_redeem_codeRedeem an event code

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`code`	Yes	The code exactly as the person said or read it. Case, spaces and dashes are normalized, so "tie-24" and "TIE24" are the same code.
`confirm`	No	Absent on the first call, which changes nothing. true, together with confirmToken, makes the change.
`requestId`	No	An id for this redemption chosen by the caller, at least 8 characters. A repeat with the same id and the same code returns the first result without redeeming a second time.
`confirmToken`	No	The token the first call returned. Needed when confirm is true.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`seat`	No
`error`	No
`changed`	No
`message`	No
`preview`	No
`replayed`	No
`servedBy`	No
`suggestions`	No
`confirmToken`	No

event_replyReply to a messageInspect

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.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The message in the person's own words, up to 1000 characters. It is sent as given.
`chatId`	No	Optional. The id of the conversation, as an event_inbox thread row gave it. When both this and firstName are sent, this one is used.
`firstName`	No	Optional. The first name of the person to answer, as an event_inbox thread row spelled it, matched against the caller's own conversations only. Two matches return AMBIGUOUS_NAME and nothing is sent.

event_requestsWho wants to meet me

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`error`	No
`message`	No
`requests`	No
`returned`	No
`servedBy`	No

event_say_helloSay hello

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`firstName`	Yes	The first name of the person, as an event_find_matches row spelled it, up to 40 characters; no surname and no account id. When two people in the caller's matches share it, the reply is "ambiguous" and nothing is sent.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`sent`	No
`error`	No
`mutual`	No
`reason`	No
`message`	No
`servedBy`	No
`firstName`	No
`candidates`	No

events_booth_detailGet one booth's details

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`boothNameOrId`	Yes	Booth id (stall_frosted_cupcakery) or name
`eventIdOrSlug`	Yes	Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it ("Summer Stroll & Savor"). Common short forms work too ("the stroll", "tie summit").

Output Schema

ParametersJSON Schema

Name	Required	Description
`booth`	No
`error`	No
`found`	No
`eventId`	No
`message`	No

events_boothsList booths and vendors

Read-only

Inspect

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).

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Optional category filter, e.g. "dessert"
`eventIdOrSlug`	Yes	Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it ("Summer Stroll & Savor"). Common short forms work too ("the stroll", "tie summit").

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	No
`error`	No
`found`	No
`booths`	No
`filter`	No
`eventId`	No
`message`	No
`eventName`	No

event_send_requestSend the hosts a request about a personal eventInspect

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.

ParametersJSON Schema

Name	Required	Description
`note`	Yes	REQUIRED. What they are asking for, in their own words, at most 280 characters. Do not add anything they did not say and do not include a phone number, an email address or a link: a link is refused.
`category`	Yes	REQUIRED. What the request is about, one of the named values: dietary, accessibility, plus_one, travel, other. Pick the one that fits what they said and use other rather than forcing one of the first four.
`eventIdOrName`	Yes	REQUIRED. The event id or the event NAME as the hosts spell it.

event_set_intentSet my event goal

Idempotent

Inspect

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. It changes only that person's badge at one event.

ParametersJSON Schema

Name	Required	Description
`label`	No	Optional. The person's own word for their category when none of the four fits ("Investor", "Director", "Press"). Up to 24 characters of letters, spaces and hyphens. It is kept and shown as written; the server still files one of the four behind it.
`facets`	No	Optional. The person's answer to the read-back: {confirm: true}, {add: [their words]} or {remove: [their words]}. The server maps the words onto the read-back's own list.
`intent`	No	Optional. One of Buyer, Vendor, Networker or Social, as the person said it; case and surrounding spaces are ignored. When absent, the server derives the category from the two sentences and falls back to Networker. A word outside the four belongs in `label`.
`confirm`	No	Absent on the first call, which changes nothing. true, together with confirmToken, makes the change.
`eventId`	No	Optional. An event id the person has joined. When this and eventIdOrSlug are both absent, the event is the one current event the person has joined.
`headline`	No	What the person is here for, in their own words, up to 280 characters. The first of the two badge sentences: the matcher reads it and other attendees see it, so a full sentence ("raising a seed round for a logistics startup") matches better than a word. Phone numbers, email addresses and links are removed on the server. When absent, the stored sentence is kept.
`firstName`	No	Optional. The first name the badge shows, 2 to 40 characters of letters, spaces, hyphens and apostrophes. A badge without a name is not findable. When absent, the stored name is kept; a name the badge cannot take refuses the whole call and the reply says why.
`requestId`	No	An id for this change chosen by the caller, at least 8 characters. A repeat with the same id and the same arguments returns the first result without changing anything a second time.
`intentText`	No	Optional. The older name for `lookingFor`; it writes the same badge sentence, up to 280 characters. When both are sent, `lookingFor` is used. Phone numbers, email addresses and links are removed on the server. An absent or empty value leaves the stored sentence as it is.
`lookingFor`	No	Who the person wants to meet, in their own words, up to 280 characters. The second badge sentence, the same field the older `intentText` writes. Phone numbers, email addresses and links are removed on the server. When absent, the stored sentence is kept.
`confirmToken`	No	The token the first call returned. Needed when confirm is true.
`discoverable`	Yes	true lists the person where other attendees at that event can find them; false keeps them off that list. It is a separate answer from the intent and is not inferred from it; a missing or non-boolean value is refused rather than defaulted.
`eventIdOrSlug`	No	OPTIONAL. Event id (tie_la_demo), public slug, or the event name, as the events tools accept it. When this and eventId are both absent, the event is the one current event the person has joined.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`badge`	No
`error`	No
`needs`	No
`changed`	No
`message`	No
`preview`	No
`readBack`	No
`replayed`	No
`servedBy`	No
`confirmToken`	No

events_floor_cardShow the event floor

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`eventIdOrSlug`	Yes	Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it ("Summer Stroll & Savor"). Common short forms work too ("the stroll", "tie summit").

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`event`	No
`found`	No
`source`	No
`eventId`	No
`message`	No
`cardTools`	No
`floorSummary`	No
`hasFloorplan`	No
`floorPlanInstruction`	No

events_getGet one Sonar event

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`eventIdOrSlug`	Yes	Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it ("Summer Stroll & Savor"). Common short forms work too ("the stroll", "tie summit").

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`event`	No
`found`	No
`message`	No
`todaysSummary`	No
`floorPlanInstruction`	No

events_listList Sonar events

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	No
`error`	No
`events`	No
`message`	No

events_offersList live offers

Read-only

Inspect

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

ParametersJSON Schema

Name	Required	Description	Default
`eventIdOrSlug`	Yes	Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it ("Summer Stroll & Savor"). Common short forms work too ("the stroll", "tie summit").

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`found`	No
`offers`	No
`drawing`	No
`eventId`	No
`message`	No
`raffles`	No
`endedCount`	No
`offerCount`	No

events_overviewEvent overview

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`eventIdOrSlug`	Yes	Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it ("Summer Stroll & Savor"). Common short forms work too ("the stroll", "tie summit").

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`event`	No
`found`	No
`booths`	No
`offers`	No
`source`	No
`eventId`	No
`message`	No
`whatsOn`	No
`timezone`	No
`floorSummary`	No
`hasFloorplan`	No
`floorPlanInstruction`	No

events_personal_cardShow a personal event card

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`eventIdOrName`	Yes	Event id (test_wedding_a_garden) or the event NAME as the hosts spell it ("Susie and John").

Output Schema

ParametersJSON Schema

Name	Required	Description
`faq`	No
`kind`	No
`tabs`	No
`tier`	No
`brand`	No
`dates`	No
`error`	No
`found`	No
`hosts`	No
`links`	No
`people`	No
`places`	No
`source`	No
`tabbed`	No
`eventId`	No
`message`	No
`registry`	No
`schedule`	No
`personalType`	No

events_speaker_detailGet one speaker

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`speaker`	Yes	A speaker name ("Aasif Mandvi", or just a surname) or a speakerId as events_speakers returns it
`eventIdOrSlug`	Yes	Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it ("Summer Stroll & Savor"). Common short forms work too ("the stroll", "tie summit").

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`found`	No
`source`	No
`eventId`	No
`message`	No
`speaker`	No
`timezone`	No
`eventDayCount`	No

events_speakersList an event's speakers

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`day`	No	Optional day filter: "today" or YYYY-MM-DD, read in the event's own timezone
`eventIdOrSlug`	Yes	Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it ("Summer Stroll & Savor"). Common short forms work too ("the stroll", "tie summit").

Output Schema

ParametersJSON Schema

Name	Required	Description
`day`	No
`count`	No
`error`	No
`found`	No
`roster`	No
`source`	No
`eventId`	No
`message`	No
`timezone`	No
`eventName`	No

events_whats_onGet the agenda or lineup

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`when`	No	"all" \| "today" \| "now" \| YYYY-MM-DD
`eventIdOrSlug`	Yes	Event id (belmont_stroll), public slug (cba26), or the event NAME as events_list spells it ("Summer Stroll & Savor"). Common short forms work too ("the stroll", "tie summit").

Output Schema

ParametersJSON Schema

Name	Required	Description
`when`	No
`count`	No
`error`	No
`found`	No
`eventId`	No
`message`	No
`sessions`	No
`timezone`	No

event_text_alertsText alerts on or off

Idempotent

Inspect

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

ParametersJSON Schema

Name	Required	Description	Default
`on`	Yes	REQUIRED. true turns text alerts on, false turns them off.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`code`	No
`error`	No
`changed`	No
`message`	No
`servedBy`	No
`textAlerts`	No
`confirmationText`	No

event_wallet_passAdd the event pass to Apple Wallet or Google WalletInspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`eventIdOrName`	Yes	REQUIRED. The event id (lbtw_2026, test_wedding_a_garden) or the event NAME as the organizer or the hosts spell it.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`link`	No
`error`	No
`state`	No
`message`	No
`servedBy`	No
`walletLink`	No
`suggestions`	No
`expiresInMinutes`	No

ui_card_diagReport card diagnosticsA

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`seq`	Yes	Which batch this is for that mount, 1 to 6. Past the budget it is refused.
`card`	Yes	Which card is speaking: menu, order, floor or storefront.
`host`	No	Which surface drew this card when it is not an MCP host: "standalone" for the connector's own shop page. Omit it inside a host. Any other value refuses the batch.
`events`	Yes	Up to 40 markers: {t, kind} plus optionally code, n, c, span, mode, w, h, top, bottom, tplEpoch. An off-vocabulary kind, an unknown key or a non-integer number refuses the whole batch.
`sessionKey`	Yes	A random id the card minted for THIS mount. Not a user id, not a device id, 6 to 24 lowercase alphanumerics.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=false, the description adds valuable context: it posts telemetry in small batches, accepts a closed vocabulary of markers and integer counts only, no free text, and returns only an acknowledgement. This is rich beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and every sentence contributes to preventing misuse, but there is some repetition: 'never to answer a question' and 'it answers no question' restate the same guardrail. Still appropriately sized for a tool that must be kept away from the model.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a non-model-facing diagnostic tool with no output schema, the description explains what it accepts, what it returns (an acknowledgement), its constraints, and its intended caller. Annotations cover the safety profile, and the schema covers parameters, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents each parameter and its constraints. The description adds only a high-level note about closed vocabulary and integer counts, which is useful but does not provide per-parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: card views post lifecycle markers to this endpoint, and it explicitly says it is never for answering questions. It distinguishes itself from data tools by naming the correct alternative ('Call a data tool instead').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly limits usage to interactive cards drawn by the connector, states the tool is 'NOT FOR A MODEL TO CALL,' and directs the agent to call a data tool instead. When-not-to-use is as clear as when-to-use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 11, 2026
- Addedevent_change

22 tool updatesOct 11, 2026

Changedbiz_info1 field changed