Skip to main content
Glama

Well

by io.github.WellApp-ai

List connectors

well_list_connectors
Read-only

List the connectors a workspace can install AND everything it has already connected, each with a one-click install deep link.

ONE tool answers both halves of the connect question — "what can I connect to Well?" and "what is connected, still syncing, or broken?" — because every existing connection is overlaid onto its catalog row. Do NOT read workspace_connectors records to work out connection coverage; this tool is that answer.

Each entry has:

  • service_id: the connector's stable catalog id (e.g. "stripe"), used in the install link.

  • name, category_id, direction: what the connector is.

  • data_domains: the financial domains it serves — any of "bank", "accounting", "invoicing" — or null for a non-financial connector. One connector can serve several domains (Qonto serves all three). "bank" here means the connector delivers cash movements, which a payroll or billing platform also does; do NOT read it as "this is a bank". To list banks, pass kind: "bank", which the server scopes on its own bank classification.

  • status: "available" connectors are connectable now; "coming_soon"/"unavailable"/"maintenance" are not.

  • is_matched / is_selected: whether this workspace's detected tools matched this connector / already picked it.

  • match_score: 0..1 confidence of that match; null when unmatched. A high score is a tool Well is confident the workspace already uses.

  • is_connected: this workspace has a connection you should REPAIR or MANAGE, not install fresh. True for "enabled", "processing", "error", "need_reconnect" and "suspended"; false for "to_configure" and "disabled", where a fresh install IS the right next step.

  • connection_status: the existing connection's state, or null when this workspace has no connection row for the connector at all. One of:

    • "enabled" — connected and syncing.

    • "processing" — the grant is in and the FIRST sync is still running; data may be partial. Connected: do NOT ask the user to connect it again.

    • "error" — authenticated but its last real sync failed. Offer install_url as a reconnect.

    • "need_reconnect" — the grant is dead and only the user can restore it. Offer install_url as a reconnect, NOT a first install.

    • "suspended" — the connection is held back administratively; tell the user it is paused. The user cannot fix it by reconnecting.

    • "to_configure" — a connect attempt that never completed its handshake. Nothing is connected: offer install_url as a first install, and never claim the tool is connected.

    • "disabled" — the connection was torn down. Offer install_url as a first install. A "degraded" connector never appears: it is resolved server-side against its own sync history into "enabled" or "error", so you never surface a state that clears itself. A connection whose state this build cannot read also reports null, and there is_connected stays true — read the two fields together, and treat "null status, is_connected true" as an existing connection whose health is unknown.

  • workspace_connector_id: the connection instance's id, or null when there is no connection row. This is the id well_invoke_connector_tool and well_list_connector_tools need — resolve it HERE, never via well_query_records on workspace_connectors.

  • last_successful_sync_at: ISO timestamp of the last SUCCESSFUL sync, or null when none has landed yet. An "enabled" connector with null here has a valid grant but has never delivered data.

  • sync_in_progress: a data sync is running right now. Tell the user to wait rather than to act.

  • is_preselected: Well recommends connecting this one now (a high-confidence match with is_connected false). The interactive picker pre-checks exactly these. A "to_configure" or "disabled" row can still be pre-checked — installing it IS the fix. On kind: "accounting" at most ONE row carries it — the single highest-confidence accounting tool — because connecting the accounting software is a pick-one step; every other scope pre-checks each high-confidence match.

  • install_url: a one-click link that STARTS or REPAIRS the connection in Well. It works from any state — it signs the user in if needed, creates their workspace if they have none, then runs the connector's own auth flow — and it covers banks too (a bank opens its bank-login flow pre-selected). Null only when the connector is not "available". Hand this to the user to get started in one click.

install_all_url is a TOP-LEVEL field, not a per-connector one. It is ONE link that installs every installable connector in this result that is not already connected, in the order they are listed. Its reach is wider than the per-row links: a connector the catalog holds by service id alone carries a null install_url and is still installed by this link, so never read a null install_url as "cannot be installed". When the answer offers several connectors to install, hand the user install_all_url and do NOT list the per-connector install_url links beside it — the one link IS the whole offer, and a table of links beside it puts the reader back through several sign-ins. One link carries at most 10 connectors, and install_all_omitted names the service ids it left out, so offer those rows their own install_url. install_all_url is null when the result offers nothing to install. It is null too wherever the result names no set the user has chosen: the unfiltered catalog and the whole bank domain never carry the link, and a name search or an accounting or invoicing domain carries it only while the WHOLE result fits in one link and this page holds all of it — past that the link would stand for whichever rows the page happened to carry. from_selection always carries the link, however many vendors were picked, because the user named each one. Where install_all_url is null, the rows' own install_url links ARE the offer: list them, and never announce a batch link the result does not carry.

Scoping: pass kind ("bank" | "accounting" | "invoicing") to get only the connectors serving that domain — the whole set, server-ordered, including the long tail of bank institutions. Pass q to name-search the full catalog. Omit all three for the curated, matched-first view. Use well_list_connector_tools for a live connection's actions.

Pass from_selection: true for the connect step that FOLLOWS a vendor pick: it returns ONLY the connectors behind the counterparties the user picked on the missing-invoices card this session, every installable one pre-checked, because the user already chose them. It takes no q and no kind — those browse a catalog, and this names a set already decided. An empty list means the session holds no pick for this workspace, or no picked counterparty matched a connector.

Every result carries scope — "catalog", one of the three domains, or "picked_vendors" — naming what the list IS. The card words its title from that field, so a caller must not describe the result as a domain the scope does not name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoName search across the full catalog (e.g. a specific bank). Omit for the curated, matched-first view.
kindNoScope the catalog to one financial domain: "bank" (every bank and neobank, including the long tail of open-banking institutions, plus the platforms that hold an account like Qonto and Pennylane — never a payroll or billing tool that merely reports transactions), "accounting", or "invoicing". Use this for a connect-a-bank or connect-an-accounting-tool step instead of filtering the default view yourself. Omit for every connectable connector.
limitNoMax connectors to return (1-100, default 50).
titleNoHeading for the connect card shown to the user, OVERRIDING the wording the card otherwise derives from the scope/kind. Use it to frame the step in its flow (e.g. "Connect your accounting tool for the close"). At most 120 characters. Omit to keep the default wording for the requested kind.
offsetNoNumber of connectors to skip, for paging (default 0).
subtitleNoSupporting line under the connect card's heading, OVERRIDING the scope-derived subtitle. At most 240 characters. Omit to keep the default wording for the requested kind.
workspace_idNoTarget workspace. This read reports one workspace's own data. Omit it and the token's primary workspace answers, which may not be the one you mean; the result names the workspace that did.
from_selectionNoScope the card to the connectors behind the counterparties the user picked on the missing-invoices card this session, each installable one pre-checked. Use it for the connect step that FOLLOWS a vendor pick, where the user has already chosen and the card must offer only what they chose. Cannot be combined with `q` or `kind` — those name a catalog to browse, and this names a set already decided. Returns an empty list when the session holds no pick for this workspace, or when no picked counterparty matched a connector.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
limitNo
scopeNoWhat this result is a list OF: the requested kind, the picked vendors' connectors, or the curated catalog when neither was asked for. The card words itself from this, so it never describes the rows as a domain that was not requested.
totalNo
offsetNo
successYes
connectorsNo
install_all_urlYesOne link that installs every installable connector in this result. Null when the result offers nothing to install, or when its scope names a set the reader has not chosen. When it is non-null it is the ONLY install link the answer offers — do not list the rows' own install_url beside it. When it is null, the rows' own install_url is the offer instead.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
install_all_omittedYesThe service ids install_all_url could not carry, because one link names a bounded number of connectors. Offer these rows their own install_url instead of promising the batch link covers them.

TDQS

A4.9/5.0
Behavior5/5

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

Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description goes far beyond them, explaining nuanced behaviors: the seven connection_status states and their user-facing implications, how null status with is_connected=true should be interpreted, how 'degraded' is resolved server-side, install_all_url null conditions, and is_preselected rules. This is rich behavioral disclosure that annotations alone could never convey.

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?

The description is long, but every sentence earns its place given the tool's complexity: 8 parameters, nuanced connection states, install-all behavior, and scoping rules. It is front-loaded with the core purpose, then organized into clear sections for entry fields, install_all_url, and scoping. The structure makes the density navigable rather than overwhelming.

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?

The description covers the full decision space: parameter usage, return-field semantics, edge cases like null install_url and empty from_selection results, sibling-tool routing, and even how to word the card via the scope field. With annotations and output schema present, nothing an agent needs to call this tool 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?

The schema covers 100% of parameters with its own descriptions, so baseline is 3. The tool description adds meaningful workflow semantics on top: when to choose kind versus q versus from_selection, that from_selection cannot combine with q/kind, and what 'bank' means in the data_domains context. It does not merely restate the schema, but it also does not need to add much more given the schema's already strong parameter documentation.

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 opens with a specific verb and resource: list the connectors a workspace can install AND everything it has already connected, each with a one-click install deep link. It clearly distinguishes itself from siblings by explicitly naming well_list_connector_tools for live connection actions and telling the agent not to use well_query_records on workspace_connectors. The dual-scope purpose is unmistakable.

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?

The description gives explicit when-to-use guidance for every scenario: pass kind for a domain-scoped catalog, pass q for name search, omit both for the curated view, and use from_selection: true after a vendor pick. It also names exclusions and alternatives, such as 'Use well_list_connector_tools for a live connection's actions' and 'Do NOT read workspace_connectors records to work out connection coverage.' No inference is required.

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

All Well toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: CRUD for companies, people, and invoices; financial analytics (cash, cost, runway, holdings); connector management and invocation; schema discovery; querying; reconciliation; and contact channel management. No two tools could be confused for the same action.

Naming Consistency5/5

All tools follow the `well_verb_noun` pattern with consistent verb choices (create, get, list, update, delete, add, remove, run, resolve, query, invoke). The naming is predictable and makes the tool's purpose immediately clear.

Tool Count4/5

With 26 tools, the set is slightly above the ideal 3-15 range, but every tool earns its place given the breadth of the domain (CRM, invoicing, financial analytics, reconciliation, connector management). The count is well-scoped and not excessive.

Completeness4/5

The tool surface covers core CRUD, financial KPIs, reconciliation, and connector management. Minor gaps exist (e.g., no direct tool to update contact channels or manage accounts), but the query and schema tools allow agents to work around them, and the primary workflows are fully supported.

Resources