event_find_matches

shallow

com.sonarconnections/sonar-connections · Verify this server

The people at an event the person is at whose stated intent fits theirs. Use it for "who should I meet", "who here is looking for investors", "who is checked in that matches what I am here for", "any buyers on the floor". Each row carries a first name, their intent, the one line they wrote about what they are looking for, and the booth they staff when they are a vendor. It carries no phone number, no email address, no surname, no account id and no photo: those are not on this surface. It answers only about people who finished a badge at that event and chose to be findable by other attendees, and it returns at most 20 of them, so a longer floor comes back as the first 20 with `truncated` true. Rows are RANKED by what each person actually WROTE on their badge, not only by their category: the server scores the one line and the interests they declared against the caller's own, and each row carries `fit` and `why`. `fit` IS ONE OF THREE WORDS and it is the whole of what the strength of a match may be called: "strong" means most of what the caller declared is echoed on the other side, "good" means a real overlap worth walking over for, and "some" means they are on the list for a reason and no more than that. `why` is one sentence composed by the server: it OPENS with that same fit and then names the words the two of them share and how the categories relate. When they share no word at all the `why` names the TOPIC they both wrote about instead, from the server's own list of topics, so a person who wrote about swimming pools and a person who wrote about pool accessories are told they both wrote about pools. READ THE `fit` AND THE `why` OUT, exactly as the row gives them, and never invent a different reason, and never guess a topic the `why` did not name. SAY ONLY WHAT THIS REPLY CARRIES: do not add how to find a person, whether the list is complete, who else might be there, what will happen next or why somebody is or is not on it, because every one of those is a guess about a floor this reply does not describe. Two buyers whose lines agree ARE matches for each other; a buyer and a vendor with nothing written still surface, because the complementary pair (buyers with vendors and networkers, vendors with buyers and networkers) counts toward the ranking. THERE IS NO NUMBER ON THIS SURFACE, and none may be supplied for it: never state a score, a percentage, a rating out of anything, a rank or a place in the list for anybody, and never turn a fit word back into one. The rows are already ordered, best fit first, which is all the ordering anyone needs to be told. If the person has not said what they are there for it comes back with `needsIntent` true and no rows: call event_set_intent first. Reading this list does not require being findable oneself, and the reply says which the caller is. WHEN IT COMES BACK EMPTY IT SAYS WHY, and the reason is the server's rather than yours: a reply with no rows carries `emptyReason`, one of four words, and a `message` that states it in plain language. STATE THAT REASON AS GIVEN AND NEVER SUBSTITUTE ONE OF YOUR OWN. `none_findable` means nobody else at that event has chosen to be findable by other attendees. `none_present` means people there are findable but none of their badges has been set or updated inside the event's own window, so none of them counts as being there. `event_not_live` means the event is not inside its own dates right now and no badge was set inside them. `no_text_match` means there are people there but none of them is close enough to what this person said they are there for. Do not infer a reason the reply does not give: not the dates, not who has arrived, not travel, not timing.

100.0/100

1 trials · measured 1 day ago

event_find_matches scores 100.0/100 on Vouch's measured behaviour index, from 1 real invocation trials against com.sonarconnections/sonar-connections, measured 6 Oct 2026 under methodology v0.2.0. Every measured component scored 100.

Component breakdown

ComponentWeightValue
Reliability35%not applicable
Schema integrity25%100.0
Failure behaviour15%not applicable
Latency15%not applicable
Concurrency10%not applicable

Tool details

Transport
remote
Credential class
self-provisionable
Input schema
not declared
Output schema
not declared
Side-effect classification
unclassified

Score history

DayScoreTierMethodology
2026-10-06100.0shallowv0.2.0

Probe evidence

ProbeOutcomes
schema_integritypass: 1

Raw request/response logs are not archived yet — the outcome counts above are drawn directly from every recorded trial.

Embed this score

Available for every tool, scored or not — not a verification perk. Always links back to this page.

Vouch score: event_find_matches
[![Vouch score](https://vouch.tools/api/tools/e8cddbe6-0d77-4acb-a262-97bbcebde859/badge.svg)](https://vouch.tools/tools/e8cddbe6-0d77-4acb-a262-97bbcebde859)
event_find_matches — Vouch