wick-connectors

Using wick connectors

A connector is wick's bridge to an external system (Slack, Notion, a database, an HTTP API). Each connector instance holds its own credentials and exposes a set of operations. You reach them over MCP.

Never guess a tool_id or a parameter name. Discovery is cheap; a wrong call is not.

The discovery cycle

Four tools, used in order:

Tool	Purpose
wick_list	Every connector instance visible to you. Returns id, connector, description, total_tools, status, kind.
wick_search	Substring search over label, name, description. Faster when you know roughly what you want.
wick_get	Operations for one connector, then the input schema for one operation.
wick_execute	Run an operation by tool_id + params.

wick_list deliberately does not return per-operation input schemas — you only pay that token cost when you commit to a specific operation via wick_get.

wick_list()                          → find the connector, note its id
wick_get({id})                       → see its operations
wick_get({tool_id})                  → input schema for the one you want
wick_execute({tool_id, params})      → run it

Shortcut when you already know roughly what you need:

wick_search({query: "loki query"})   → matched tool_id
wick_execute({tool_id, params})

Reading the list

Entries come in two kinds, and the difference is whose identity you act as:

• kind: "connector" — shared or bot credentials.
• kind: "account" — a specific user's connected OAuth account.

When several users have connected personal accounts to one instance, you see one connector entry plus one account entry per user. Pass a composite connectorID/accountID to wick_get and the returned tool_ids carry an @accountID suffix; wick_execute then injects that account's token automatically.

Pick account when the action should be attributable to that person, connector when it is the system acting.