> This page is for Workforce. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.merge.dev/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.merge.dev/_mcp/server. # Overview > What a Tool Pack is in Merge, how to build one, how the Overview, Rules, and Settings tabs work, and how a pack reaches employees through a Group. 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](/merge-workforce/provisioning/groups) 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](https://wf-develop.merge.dev/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](/merge-workforce/connectors/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 | Tab | What it holds | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **Overview** | The Connectors and tools in the pack, the pack's ID, its Connector and tool counts, and **Test in Playground** to call a tool as the pack sees it | | **Rules** | Per-pack overrides of your organization's Standard Entity Rules and Custom Regex Rules | | **Settings** | The pack's name and description, and deleting it | 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](/merge-workforce/connectors/overview). ## 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 a `404` on the REST path and a JSON-RPC `Tool not found` over 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](/merge-workforce/security/overview). ## 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](/merge-workforce/tool-packs/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](/merge-workforce/tool-packs/tool-input-overrides). ## Next steps #### [Groups and access](/merge-workforce/provisioning/groups) Assign this pack to a Group, layer it per team, override it per person #### [Tool description overrides](/merge-workforce/tool-packs/tool-description-overrides) Rewrite a tool's description so the model picks it correctly #### [Tool input overrides](/merge-workforce/tool-packs/tool-input-overrides) Pin a tool's input fields to values you choose #### [Connectors](/merge-workforce/connectors/overview) Authorize the integrations a pack draws its tools from