Personal connectors

A personal connector is a remote MCP service — Granola, Gmail, Outlook, and more — that you connect to your own identity, not to a single workspace. You authenticate once, and the connection follows you across every workspace you belong to. It is owned by you, not shared with a workspace’s other members.

This is the counterpart to a workspace Connector, which is shared by everyone in a workspace and owned by that workspace. Same catalog of services; different owner.

Where personal connectors live

Open Profile → Connectors. The page has two lists:

Your connectors — what you’ve already connected. Each row shows the account it’s connected as and where it is on (for example, On in 2 of 3 workspaces). Click a row to open it and manage that connector.
Add a connector — the curated set of services offered for a personal connection you haven’t added yet.

Which services appear under Add a connector is set by the platform operator (a connector is flagged as personal in the catalog). Personal connectors authenticate by standard OAuth (dcr) or through Composio.

Connecting a service

Under Add a connector, find the service and click Connect.
You’re redirected to the vendor’s sign-in page (for a Composio connector, through Composio’s hosted flow).
Sign in and approve access. You’re returned to Profile → Connectors, and the service moves into Your connectors as Connected.

When the service reports which account you signed in with, the row reads Connected as that account (for example, an email address). A service whose sign-in supports OpenID Connect reports it, since the platform asks it for your email address, and so does a Composio connection. A service without OpenID Connect has no standard way to report the account, so its row reads Connected. So does a service that supports OpenID Connect but won’t share your email address with the platform: the sign-in goes ahead without it. To switch accounts, Disconnect and connect again with the other account.

Connecting installs the connector on your identity and runs the sign-in in one step. Nothing runs on the platform host except the connection itself; your tokens are stored against your identity, outside any workspace.

Grants — the key idea

A personal connector is yours, so you decide which of your workspaces may use it. Until you grant it into a workspace, the agent in that workspace has none of its tools. This is deliberate: a grant is explicit, audited, and revocable, so a connection you hold personally never leaks into a shared workspace’s agent without your say-so.

The rule has no exception for a workspace only you belong to — you grant the connector there too before your agent can use it. There is no “free at home”.

In Your connectors, click the connector’s row to open it.
Under Workspaces, switch the connector on in each workspace where you want your agent to use it. Switching it on grants it there; switching it off revokes the grant.

Granting into a workspace makes that connector’s tools appear to the agent there on its next turn. Revoking removes them just as immediately. Grants are per-workspace and independent — granting into one never affects another.

You can also grant from chat: ask the agent to “grant Granola to this workspace,” and it will (a grant only ever widens your own reach, so any member may grant their own connector — no admin role needed).

Using it in a workspace

Once a personal connector is granted into the workspace you’re chatting in, its tools are available to the agent there, namespaced to that workspace. Ask the agent to use the service (“summarize my last three Granola meetings”) and it will call the connector’s tools. In a workspace where you haven’t granted it, those tools simply aren’t present.

Tool permissions

Open a connected personal connector’s row and click Show tools under Tool permissions. A table lists the connector’s tools, each set to Allow or Disallow, with Allow all and Disallow all for the whole set. A tool with no setting is allowed.

The policy is yours, like the connector: it applies in every workspace you grant the connector into, and no admin role is needed to change it. It is separate from a workspace connector of the same name, whose policy the workspace’s admins set under Settings → Connectors. From chat, ask the agent to set it; the agent addresses your personal connector with scope: "identity".

In a notification route

A notification route may deliver through one of your my_ tools — so a connector’s report can reach your Slack, not a shared one. Two conditions, and they are the ordinary grant rule rather than anything new:

You have to be the route’s author. A route dispatches under whoever last saved it, and a personal connector answers only to its owner. Somebody else saving that route re-stamps it to them, and it stops working — the delivery is recorded as refused on the item, with the missing grant named.
The connector has to be granted into that workspace. Same grant as for chat; without it the tool is not present there for anyone, including a route.

Revoking the grant, or disconnecting the connector, stops the route the same way it stops the agent — immediately, and visibly in the item’s delivery ledger.

Disconnecting

Disconnect, at the bottom of a connector’s opened row, fully removes it from your identity in one step:

revokes every workspace grant,
deletes the connection’s stored credentials,
stops and removes the running connection, and
drops the install record.

The connector leaves Your connectors and returns to Add a connector. There is no “de-authenticate but keep it” half-state — disconnect is a clean removal. To use the service again later, connect it again and re-grant it where you want it. Disconnecting asks you to confirm first, and tells you how many workspaces will lose access.

Where your credentials live

A personal connector’s credentials are identity-owned: they live at users/<userId>/credentials/ on the platform, outside any workspace, so leaving or being removed from a workspace never orphans them. They are never echoed back to the UI. For a Composio connector, the platform-wide Composio API key stays in the platform environment and only an opaque account pointer is stored against your identity — never the vendor key. See Credentials for the full model.

Personal vs. workspace connectors

	Personal connector	Workspace connector
Owned by	You (your identity)	The workspace
Managed under	Profile → Connectors	Settings → Connectors (per workspace)
Who can use it	Only you, and only in workspaces you grant it into	Every member of that workspace
Credentials	`users/<userId>/credentials/`	`workspaces/<wsId>/credentials/`
To use in a workspace	Grant it in	Already shared with all members

What’s next

Connectors — workspace-shared connectors and the auth kinds
Notifications — routing a connector’s report through one of your tools
Workspaces — how membership and per-workspace scoping work
Chat — talking to the agent
Credentials — how secrets are stored