Connector

What it means

The product links a user account to a third-party service and exposes specific capabilities (search inbox, create event, post message) as tools the agent can invoke.

Why designers should care

Connector flows need in-context discovery (chips when email is implied), granular allow/deny per tool, connection health, and revoke paths—not a one-time OAuth buried in settings.

Example

Perplexity shows Gmail and Outlook chips in the composer when a query implies email; a modal splits read vs write tools with per-action Allow toggles before the agent runs.

Common mistakes

• • All-or-nothing OAuth with no per-tool granularity.
• • Connectors only in settings while the composer implies cross-app actions.
• • Tool failures with no integration name or reconnect path.

Related terms

• Tool Use: The model emits structured calls (name + arguments) that your app executes, then feeds results back into the conversation for the next step.
• Tool Permissions: The product maps each tool (API operation) to an allow/deny state, sometimes grouped by risk (read-only vs write vs delete), enforced before every invocation.
• MCP (Model Context Protocol): MCP servers expose capabilities (search files, query tickets, run commands) that compatible clients discover and call in a standardized way.
• Human-in-the-Loop: The product pauses at defined checkpoints for human judgment (approve send, merge PR, publish article, charge card), even if AI drafted the action.
• Capability Disclosure: Visible statements of scope, limits, data access, and known failure modes—not buried in terms of service or a one-time onboarding modal.