Connector tools and approvals

How a connector's actions become one tool for agents, how each action is marked read, write or destructive, and how approvals decide which calls ask a person first.

Enterprise module

Connectors is the enterprise connectors module. The tool a connector creates appears in Tools like any other tool.

From actions to a tool

A connector's actions become one managed tool in Tools. The tool holds all the actions of the connector, and agents add it like any other tool. The tool never holds the credential: Console supplies the connected account for each call.

The tool appears when the account is connected, and it follows the connector:

Connector state	Tool
Connected and enabled	Active
Disabled, disconnected, or reconnect required	Disabled
The settings turn off every action	Removed, so no agent keeps a tool the settings turned off.

Open the Tools tab of the connector to see it. The Managed tool card shows the tool's Name, Key, Status and number of Actions, and Open in Tools goes to it. Under Actions each action has its Access and its State (On or Off). An action is on while the current settings allow it. For example, the write actions of most packages are off while Read only is on.

Sync tools

Choose Sync tools to bring the tool in line with the package and the settings. Sync after you change settings, after a package update, or when a notice asks for it:

Notice	What to do
Tools are not synced yet	The account is connected. Sync tools creates the tool.
The tool is turned off	Sync tools turns it on again.
The connector is disabled	Choose Enable connector.
No tools with these settings	The connector offers no tools with its current settings or sign-in method. Change them.
Connect an account first / Connect the account again first	Tools are listed with the connector's account.

Connecting an account syncs the tools too. If the tool listing fails there, the connection stays and Sync tools retries it.

Action markings

Each action of a package declares what it does. The Tools tab shows it as Access:

Access	Meaning
Read	Looks at things and changes nothing.
Write	Creates or changes something.
Destructive	Changes something in a way that is hard to undo, such as merging a pull request, cancelling a meeting or silencing alerts.

The markings are stored on the tool's actions in the standard MCP tool-annotation shape: Read is read-only; Write is not read-only and not destructive; Destructive is not read-only and destructive.

Bind the tool to an agent

1. Open Build → Agents → your agent → Build.
2. In the Configuration card choose Add Tools, expand the connector's tool in the Select Tools dialog and tick the actions the agent should have.
3. Confirm, then publish the agent for API and portal traffic to see the change.

See Build and publish an agent and Tools overview. Give an agent only the actions it needs. Connector actions run as the organisation account, so the agent can do whatever that account can.

Approvals

The connector only marks what an action does. The agent decides whether a call asks for approval. A connector has no approval setting of its own; a package that declares one is accepted and the field is ignored.

The rule is the same as for every tool: see which tools ask. For connector tools:

• Read actions run without asking.
• Write and Destructive actions ask by default. A call that is not marked read-only asks.
• An action with no marking asks.
• The agent's owner can set a tool to Never ask on the agent, under Approvals & questions → Per-tool settings. Choosing it asks you to confirm, with a stronger warning for a destructive tool. A read-only tool shows that it does not ask; over the API it can still be set to always.
• Unattended runs (triggers, evaluations, and the OpenAI-shaped endpoints) have nobody to answer. With the default When nobody can answer setting, Deny the tool call, a call that would ask is refused, and the model is told that the tool needs human approval. The owner lets it run unattended by setting that tool to Never ask.

The Tools tab repeats the rule: Tools that are not read-only ask for approval before they run. The agent owner can change that per tool on the agent: Approvals & questions.

Two things limit what a call can do, whatever the approval says:

• Read only on the connector turns the write actions off. A call to an action that is off fails with a message that it is turned off in the connector's settings.
• The account's own permissions at the vendor.

Email as an example

The SMTP package has two actions. draft_email is Read: it shows exactly what would be sent and sends nothing. send_email is Write: it sends from the connector's fixed sender and asks by default. The draft runs without asking and the send asks, with no configuration. See Email.

Packages that are MCP servers

Some packages give agents the tools of the vendor's own MCP server rather than actions of their own. GitHub MCP is one: GitHub maintains the tool list. The catalog card shows an MCP badge for such a package, and the connector's tool holds the server's tools.

A connector offers either the package's own actions or the vendor's MCP tools, never both. On a package that can do both, the MCP tools win and the Tools tab says This connector uses the vendor's MCP server now, so its own actions are off.

How an MCP tool is marked:

• The marking the server sends (readOnlyHint, destructiveHint) is kept.
• The package can only tighten it. It lists patterns by tool name, each marked read, write or destructive. Names such as get_*, list_* and search_* are read, create_*, update_* and add_* are write, and merge_* and delete_* are destructive. If several patterns match, the most cautious one wins.
• A tool the package does not list is treated as destructive, so a tool the vendor adds later asks until the package knows it.
• A package marking never makes a tool less safe than the server says.

After that the same approval rule applies. The Read only setting of GitHub MCP is passed to the server, which then hides every tool that changes something.