Skip to main content
Connectors give Copilot and your agents the ability to act in systems outside DualEntry. Each one exposes a set of tools over the Model Context Protocol, and Copilot can call those tools inside a conversation once the connector is authenticated. Use this guide to install a connector from the registry, connect your own account to it, add a connector of your own, or work out why an installed connector reports no tools.

​
Before you start

Installing a connector and using one are separate steps with different requirements, so check which half applies to you before starting. Installing a connector for your organization requires a role that can create, edit, and archive integrations. Installation affects everyone, because it fixes the server address and decides which of that server’s tools are allowed to run at all. Connecting your own account to an already-installed connector requires no special role. Any user can do it for themselves, and it only ever touches their own credentials. Some connectors also need an OAuth client that belongs to your organization rather than to DualEntry. Gmail is the common case: it runs against Google’s hosted Gmail MCP server and requires a Google Cloud OAuth web application client that you own. Create that client in the Google Cloud console before you begin, or the consent step fails for everyone. Decide which tools the connector should be allowed to run before you install it, because read-only and write access are separate decisions. Installing a connector does not by itself let Copilot change anything in the external system.

​
How connectors work

A connector has two layers: organization and personal. The organization installs the connector once, and each person then connects their own account to it. The organization-level install holds the server address, the OAuth client configuration, and the list of tools allowed to run. Someone with the integrations permission sets it up, and it is shared. Credentials are not shared. Every user who wants to use the connector completes the provider’s authorization flow themselves, and DualEntry stores that person’s tokens against their own user record. Copilot loads a connector’s tools only for users who have personally connected, so an installed connector does nothing for a colleague who has not authorized it yet. This is why the Gmail connector drafts into the mailbox of whoever is asking. There is no single organization mailbox behind it. If you and a colleague both connect Gmail, each of you gets drafts in your own mailbox, and neither of you can read the other’s mail through Copilot. Connectors authenticate one of three ways, decided by the connector rather than by you: OAuth with credentials DualEntry registers automatically, OAuth with a client your organization owns, or a static bearer token you supply. Servers are reached over Streamable HTTP, or over SSE for older servers.

​
Install a connector from the registry

The registry lists connectors DualEntry has already integrated, Gmail among them. Installing one records the server for your organization and opens it for individual users to connect.
  1. Open the Agents panel and select Connectors. Connectors already installed for your organization appear under Installed.
  2. Select Add connector to open Browse Tools, then filter to the MCP category and find the connector you want.
  3. Read the detail pane. It shows the connector description, the author, a View docs link, and a Tools count.
  4. Supply the OAuth client details if the connector requires an organization-owned client, as Gmail does.
  5. Review the permissions on the connector page you land on, and change them if the defaults are not what you want. Tools are grouped into Interactive Tools, which change something in the external system, and Read-Only Tools, which only read. Each tool can be set to Enable, so Copilot uses it as needed, Opt-in, so Copilot asks before each use, or Disable, so Copilot never uses it. Expand a tool to see what it does, and use Allow all or Disable all to set a whole group of read-only tools at once.
  6. Select Connect and complete the provider’s authentication flow.
  7. Return to the connectors page and confirm the connector appears under Installed.
Read what a connector can do rather than what you plan to use it for. The Gmail connector reads and searches the mailbox each user authorizes, so connecting a mailbox grants Copilot read access to everything in it. Connect a functional AR or billing mailbox rather than an inbox holding unrelated confidential mail.

​
Connect your account and enable the tools you need

An installed connector is inert until two more things happen: you connect your own account, and someone with the integrations permission allows the tools you intend to use. Open Connectors in the Agents panel, find the connector under Installed, and complete the provider’s authorization flow for yourself. This is the step that creates your credentials and makes the connector’s tools visible to your conversations. Read-only tools are available as soon as you connect. Tools that change something in the external system start disabled and have to be set to Enable or Opt-in by someone with the integrations permission, under Interactive Tools in the connector’s Permissions section. Drafting a Gmail message is one of these, so a dunning workflow returns nothing useful until Gmail’s draft tool is turned on, even though searching mail already works. Choose Opt-in rather than Enable for anything customer-facing. It keeps a person in the loop on each use, which is the difference between a tool that drafts when you ask and a tool that drafts whenever Copilot judges it useful. Newly enabled tools appear on your next message rather than requiring a restart, because Copilot re-reads the allowed tool list on every turn.
The Gmail connector is authorized for reading, searching, drafting, and sending. Copilot can send mail from your account when you ask it to, using the access you granted when you connected Gmail. Sent messages appear in your Gmail Sent folder like any other message you send.

​
Add a custom connector

A custom connector points DualEntry at an MCP server you supply by URL rather than one from the registry. Use it for a server your team runs internally, or for a third-party server that is not in the registry yet.
  1. From the connectors page, select Add custom connector.
  2. Provide the server URL and a display name. The display name is what appears in the connector list and what you refer to when asking Copilot to use it.
  3. Choose how the server authenticates: OAuth, or a static bearer token with the header name the server expects.
  4. Save, then connect your own account and confirm the tool count populates.
A custom connector behaves like a registry connector once it is connected, including the per-user credentials and the read-only default. The tool list comes from the server itself, so the tools available to Copilot are whatever that server exposes, and they change when the server changes without any corresponding action in DualEntry. Adding a custom connector requires the same integration permissions as installing a registry connector.

​
Confirm the tools reach Copilot

A connector listed under Installed is not necessarily one Copilot can use for you, so confirm the tools reach the assistant before building a workflow on them. Open a Copilot conversation and ask what it can do with the connector by name. Copilot lists the tools it can see. If it reports nothing, either you have not personally connected or your authorization has expired. A tool count of 0 tools available means the same thing from the other direction. It is the state of a connector nobody has authorized yet rather than a fault, and it resolves when authentication succeeds. Check from the surface you plan to work in. Connectors are available to conversations in the Agents panel and to the scheduled agents you own, and an agent that calls a connector you have since disconnected fails at run time with nobody present to notice. Tool calls run under the permissions of the credential you authenticated with, not under DualEntry’s role model. A credential with broad access in the external system gives Copilot that same breadth, regardless of the DualEntry role of the person asking. Every call is logged with the tool name, who ran it, whether it succeeded or was denied, and how long it took. Argument values are deliberately not recorded, so the log shows that a draft was created without storing its recipient or its text.

​
Troubleshooting

Most connector failures are authentication problems that often trace to the per-user layer. The table below maps what you see to what to do about it.
Last modified on August 14, 2026