elaichi__connection__list
List the authenticated third-party accounts the caller can use — their own, plus anything explicitly shared with them or their teams. A connection with NO shares is private to its owner and is never listed for anyone else, whatever permission they hold — this cannot answer "what has Priya connected" and must not be reported as if it could; only its owner can. There is no org-wide listing: an org owner or admin sees exactly this same set, never every connection in the organization, whatever permission they hold. A connection is one account of one connector with a credential held in the vault; this is what "are we connected to Slack" means. Each row carries a conn_… id, name, connector_slug, owner_user_id with an owner: { id, name, email } beside it — say who owns a shared connection by name, never by id — and status: "active" is usable, "pending" means nobody ever finished the provider login, "needs_reauth" means it broke and connection.reconnect is the repair. Every row also carries access_summary, a BOUNDED who-else-can-reach-it rollup — { org_level, team_count, user_count, total, preview } — never a full grant list however many grants exist, so answer from its counts ("shared with 3 people and 1 team") and send the user to the connection’s Manage access tab when they need every name. There is no shares key on a row. Every row also carries access_via — how the CALLER reaches that connection: "owner", "direct" (shared with them by name), "team" (with access_via_team: { id, name } naming the team) or "org" (shared organization-wide). It is about the caller alone, never about anyone else, so it is present on every row including ones where access_summary is withheld — and it answers "why can I see this" without disclosing who else can. Credentials are never included. Narrow before paging rather than walking every page: connector_slug answers "do we have Slack" exactly (one slug, or several) and is the right choice when the caller names a provider, owner_user_id narrows to one owner within what the caller can already see (it never reaches a private connection, so it still cannot answer "what has Priya connected"), status takes one lifecycle value, and q is a case-insensitive substring match against the connection’s name, its account label, its connector slug, and the connector’s catalog label — so q: "slack" finds a Slack connection even if a person renamed it to something else, and q: "sheets" finds one on google-sheets even though the slug does not spell it that way. Unrelated to sso_connection.*, which is how people log IN to Elaichi. Returns { result: [...], nextCursor, prevCursor } — camelCase here, unlike the REST API’s next_cursor. Page by sending nextCursor back as cursor until it is null.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Case-insensitive substring match on the connection’s name, its account label, its connector slug, and the connector’s catalog label, applied before paging. `connector_slug` below is still the right choice for an exact "only these connectors" filter. | |
| limit | No | Rows per page, 1–200 (default 50). Larger values are clamped, not rejected. | |
| cursor | No | Opaque cursor taken verbatim from a previous call’s `nextCursor`. Omit for the first page. | |
| status | No | Narrow to one lifecycle status, applied before paging. | |
| owner_user_id | No | Narrow to connections owned by one user, within what the caller can already see. It is a filter, not a way in: another member’s private connections stay invisible, so this cannot enumerate what someone has connected. An id nobody owns returns an empty page. | |
| connector_slug | No | One or more connector slugs (e.g. ["slack"]) — take a slug from a row you have already seen or from connector.list, and do not invent one. This is the right way to ask "are we connected to X"; it matches exactly, applied before paging. |