Overview
A Tool Pack is a named bundle of Connectors and the specific tools inside them. It is the unit of tool access in Workforce: you do not grant an employee a Connector, you grant them a Tool Pack, and you do it by assigning the pack to a Group from your identity provider rather than to a person or an agent.
Most organizations have several. The same Workforce organization might run a support pack (read-only Salesforce, Zendesk, Jira), a revenue-ops pack (write access to Salesforce and HubSpot), and an IT pack (Okta, Slack, GitHub). Different jobs, different packs, different blast radius.
When to create one pack vs many
Use one Tool Pack per job function, and reach for more than one when:
- Different teams should see different tools. Support has no reason to write to your billing system.
- The same Connector needs different exposure in two places. A read-only Salesforce pack and a write-enabled one are two packs, not one pack with a caveat.
- You want a staging surface. A pack with a couple of Connectors, assigned to a pilot Group, before it goes to the whole company.
Tool Packs are cheap. Every pack is one bounded surface you can reason about, audit, and lock down.
Creating a Tool Pack
From Tool Packs, click Add tool pack, name it, describe what it is for, and add Connectors. For each Connector, pick the specific tools you want exposed. Most Connectors expose 30 to 80 tools and you usually want a subset.
The search box in that dialog matches on Connector name and on tool name, so you can type a Connector like Salesforce or jump straight to a tool like search_files. It matches the tool’s short name, not the fully qualified connector__tool form.
A Connector that cannot authenticate anyone until you register your own OAuth app is left out of the picker, as is a Connector with no tools. If a Connector you know exists is not in the list, that is usually why: set up its Application credentials and it becomes selectable. On an existing pack, Edit tools keeps showing a Connector already in the pack even when it reaches that state, so an edit elsewhere in the pack does not silently drop it.
Creating a pack grants nobody anything. It reaches employees when you assign it to a Group.
The three tabs
Calls always run under the employee’s own credentials for the Connector, so a pack widens what an employee’s AI may attempt, never what the employee themselves can reach. See Connectors.
Editing a pack employees are already using
Edits take effect on the next tool call. No token rotation, no reauthentication.
- Adding a tool. Employees on this pack see it the next time their client calls
tools/list. Most clients refresh on a fixed cadence, so it can take a minute. - Removing a tool. The tool stops being callable immediately. A call to it comes back as
tool_not_found, which is a404on the REST path and a JSON-RPCTool not foundover MCP. - Changing description or input overrides. Same as adding, picked up on the next
tools/list. - Removing a Connector. The Connector and all its tools stop being callable. Stored credentials are not deleted, so if you re-add it later employees do not reauthenticate.
On a pack a lot of people use, prefer adding tools to removing them mid-flight. A removal can break a run that picked the now-missing tool off a stale list.
Rule overrides per pack
Your organization’s guardrail rules apply everywhere, and the Rules tab changes the action for one pack only. The org-level rule still exists. The usual pattern is to block credit card numbers organization-wide and allow them on the finance team’s pack, which legitimately needs to read them. See Security.
Shaping what the model sees
Two levers change how a tool presents itself to an employee’s AI, both set on the Connector and applied organization-wide rather than per pack:
- Description overrides rewrite a tool’s description so the model picks it correctly when your terms differ from the provider’s. See Tool description overrides.
- Input overrides pin a tool’s input fields to fixed values, so every call lands on the workspace or project you chose. See Tool input overrides.
Next steps
Assign this pack to a Group, layer it per team, override it per person
Rewrite a tool’s description so the model picks it correctly
Pin a tool’s input fields to values you choose
Authorize the integrations a pack draws its tools from