Platform · DRW · MCP connector
The answer layer for the physical world.
Sonar Connections publishes source-attributed data an assistant can read and act on: live events, public open data, and business menus, availability, booking and pickup ordering. Two doors reach it. DRW is our own concierge inside the Sonar Connections app, the one that orders, books and answers. The Model Context Protocol connector serves that same data outward to any other assistant. Every response names where the fact came from, and the two tools that write are gated behind a person's tap, never the model's judgement.
What an assistant can ask
Three lanes, two doors.
DRW is the door inside our own app. The Model Context Protocol connector is the door outside it, speaking streamable HTTP. Both read the same records from the same modules, so the app and a partner's assistant cannot answer one question two ways. Tool names are domain-prefixed so a new domain is an addition rather than a renaming, and the server identity carries no locality: the place is worn by the data, not by the company.
Door 1 · Inside the app
DRW, the concierge
Typed or spoken, DRW is the interface to every action the product has: find a booth, read a menu, hold a pickup window, place the order, book an appointment, get a route out of the building. It is the face of the Sonar Connections app rather than a feature inside it, and every new action ships with a DRW decision or it does not ship.
Door 2 · Outside the app
The connector, for everyone else
The same records served outward to any assistant a partner already uses. Fourteen read-only tools on the public lane with no account and no key, and the two that write are gated behind a person's tap.
One tap in Claude, then ask about events, open data and businesses. Every answer names its source.
Lane 1 · Live events
The event catalog, served outward
The same floor record the app reads on the street: events, booths and vendors, live offers with their time windows, and the agenda or lineup. An event is served only when it has been marked public with no venue veto, or named explicitly in the connector's own allowlist. Everything else is an honest not-found.
events_listevents_getevents_boothsevents_booth_detailevents_offersevents_whats_on"What is on at Summer Stroll and Savor tonight, and which booths have a vegetarian menu?"
Lane 2 · Public open data
Open data an assistant can cite
Datasets published by public bodies, structured for machines with the publisher, the license, the record count and the last-modified date attached to every answer. Fifteen datasets from the City of Long Beach open data portal today, with a readable page for each one at data.sonarconnections.com.
city_datasetscity_recordscity_giscity_calendarcity_sweeping"How many Go Long Beach service requests are in the city's 311 dataset, and how fresh is it?"
city_datasets and city_records are the shipped pair. The GIS, calendar and street sweeping tools say FOUNDER PREVIEW in their own descriptions and are labelled that way to the model.
Lane 3 · Businesses
Menus, availability, booking, ordering
A business's services and hours, its pickup menu with prices, allergens and lead times, and its open appointment slots read live from the merchant's own scheduling system. Two further tools book an appointment and place a pickup order, and both are off the public lane.
biz_infobiz_menubiz_availabilitybiz_bookbiz_order"What is on the pickup menu, and what is the earliest window I can collect at?"
The businesses on this lane today are our own demonstration properties, and every response about one carries a flag and a notice saying so. Each sits behind a Square sandbox seller, and one of them was connected through the same OAuth consent flow a production merchant would use. Onboarding a real merchant is that consent screen, not new code.
How an order actually happens
Five steps, and a person owns the one that spends money.
This is DRW taking an order inside the app, in screenshots of the shipped build taken on a phone on 10 September 2026. The lane runs end to end against Square's sandbox: nothing here has taken a real card yet, and the merchant's base URL travels on the merchant's own binding, so production is a binding change rather than a rewrite. The last card is the OUTSIDE door answering for the same order.
Step 1
The menu is read, not remembered
Items, prices, allergens and lead times come back from the merchant's catalog on the ask. The card names its source at the foot, every time.
Step 2
A real window, with real capacity
Windows carry how many orders each can still take. When today is full the answer says so and offers the next day rather than inventing a slot.
Step 3
A person confirms
The model assembles the basket and stops. Only a tap on Place Order reaches the order callable, so no phrasing and no jailbreak can spend money on its own.
Step 4
Payment happens on the processor's page
The order is created as a Square checkout link and the buyer pays on Square's own hosted page. No card number, expiry or security code passes through us at any point.
Step 5
The paid state is read back, not assumed
What the product relies on is a read: "is this paid" is answered by asking the processor at the moment somebody asks. A signature-verified webhook is wired alongside it to flip the state at the instant of payment. Two doors, one shared body, so nobody's money gets read two ways.
And afterwards
An outside assistant can answer for it
This one is not DRW: it is a third-party assistant on the connector, asking about the order DRW placed. "Is my order paid" is answered by reading the processor at the moment somebody asks, which is the only moment the answer matters. The reply names its source, which is why it credits us out loud here and DRW never does inside the app.
Built for partners
What an engineer wants to know first.
There is no user account, no App Check and no database rule between a third-party model and these records. The whole security argument is one pure module that every byte passes through on the way out, and it is unit-tested rather than trusted.
Read-only by default
Fourteen of the sixteen tools are read-only, declare readOnlyHint to the client, and have no write path in code. The public lane serves exactly those fourteen.
The model proposes, a person confirms
Booking and ordering are not model decisions. The model builds the request and renders a confirmation sheet; only the tap on that sheet reaches the callable that writes.
Merchant consent runs through the point of sale
A merchant connects through their own processor's OAuth consent screen. The scope list is a frozen constant, it is computed per business kind so a dentist is never asked for a bakery's permissions, the token lives in Secret Manager keyed by business, and there is a revoke door.
No card data ever touches us
Payment is taken on the processor's own hosted checkout page. We hold an order id and an integer of cents. There is no card field anywhere in the payment modules.
Every answer names its source
Responses carry the source, the source URL, the body that published it and a plain-language attribution line asking that both the publisher and Sonar Connections be credited. Attribution is structural: it is the only way a payload is built.
Telemetry carries no people
Action verbs, error codes, durations, booleans and integer counts. Never a name, a message body, a photo URL or a raw coordinate. A redactor enforces it and the call sites are held to it at review.
Honest negatives, never a guess
A thing the connector cannot serve returns a not-found with a reason. A refused order says which item or window refused it. A wrong credential, a missing credential and a path that does not exist all return the same bare 404, so the endpoint is not an oracle.
Sensitive public data is handled differently
Three of the fifteen open datasets carry records about people in circumstances they did not choose to publish. Those return the schema, aggregate guidance and a small sample instead of bulk rows, and they are flagged as such in the catalog.
What we never serve
- Coordinates. No latitude, longitude, geohash or floor-plan position. A human location hint is the substitute.
- People. No user ids, no attendee records, no staff or member lists. Ask who runs a booth and you get the booth's name.
- Credentials. No join codes, staff codes or booth codes. Those are doors, and this server does not hand out keys.
- Vendor analytics. No visit counts, dwell time, saves or redemption totals. That belongs to the vendor who earned it.
- Presence. Who is where, right now, is never an answer this connector gives.
- Card data. Never handled, never stored, never logged.
For point-of-sale and platform partners
We bring the demand. You keep the merchant.
A merchant's menu, hours and availability already live in their point of sale. What is missing is a machine-readable door an assistant can walk through, and a confirmation step a merchant trusts. That is the whole product.
- POS neutral
- Square is the live lane today. Other point-of-sale systems connect through their own partner programs, behind the same adapter seam: a per-merchant binding that carries the base URL, the scopes and the token.
- Merchant consent
- The merchant grants access on the processor's own consent screen and revokes it the same way. No merchant ever types a credential into our app, and we ask for the narrowest scope set that lets their business kind work.
- No marketplace fee
- The order is created in the merchant's own account and the money goes straight there. We add no application fee and take no cut of the ticket.
- Attribution
- Every answer built on a merchant's data names that merchant. An assistant quoting us is told, in the payload, to credit the source.
- Where it is listed
- The connector is listed in the Claude connectors directory under the slug sonar-connections, and its listing carries its own Connect button at claude.ai/directory/connectors/sonar-connections. It also runs today as a direct MCP endpoint for anyone we hand a URL to.
- Talk to us
- founders@sonarconnections.com. We will walk an integration team through the tool registry, the guard module and the order lane on a call, and hand over the connector documentation at sonarconnections.com/docs/connector.
Data: Sonar Connections platform record, verified 2026-09-11.
Source: the connector's own live tool listing (fourteen read-only tools returned by tools/list on the public endpoint, all carrying readOnlyHint), the tool registry in the backend repository (sixteen registrations), the open data catalog the connector returned on the same day (fifteen datasets from the City of Long Beach open data portal, three flagged as sensitive context), and a passing run of the four connector guard test suites (281 tests). The ordering screenshots were taken on a physical Android device on 2026-09-10 from the shipped build, against Square's sandbox environment. The DRW screenshot above was taken on the same physical device on 2026-09-11, and the answer in it was checked against the merchant record the connector returns for that business on the same day (open 07:00 to 15:00 today), so the sentence, the card beside it and the underlying record all agree. The directory listing named above, its slug and its Connect address were read on the Claude connectors directory on 2026-09-11. Facts this page could not verify on those dates are omitted rather than estimated. Corrections: founders@sonarconnections.com.
Bring your merchants an answer layer.
If you run a point-of-sale platform, an assistant you want connected, an event, a chamber, a convention bureau or a business improvement district, the fastest path is a short call and one test merchant. Tell us which one you are and the right person comes to the call.
Prefer your own mail? founders@sonarconnections.com