Tool Packs

A Tool Pack is a named bundle of Connectors and the specific tools you want exposed to one agent surface. The Tool Pack ID is part of the MCP URL - it’s how Agent Handler knows which tools the agent on the other end is allowed to see and call.

Most teams have more than one Tool Pack. The same Agent Handler organization might serve a customer-support agent (read-only Salesforce, Zendesk, Jira), a revenue-ops agent (write access to Salesforce and HubSpot), and an internal IT agent (Okta, Slack, GitHub). Different jobs, different packs, different blast radius.

When to create one pack vs many

Use one Tool Pack per agent surface. Reach for more than one when:

• Different agent surfaces should see different tools. A support agent shouldn’t have write access to your billing system.
• Different customer tiers get different tools. Free-tier read-only; enterprise gets the full set.
• Different environments need different scoping. A test pack with mocked Connectors, a production pack with the real ones.

Tool Packs are cheap - every pack is one bounded surface area you can reason about, audit, and lock down.

Creating a Tool Pack

From the Tool Packs dashboard, click Register new Tool Pack, name it, and add Connectors. For each Connector, pick the specific tools you want the agent to see. Most Connectors expose 30–80 tools; you usually want a subset.

Save the pack and copy its ID from the URL. That ID goes into the MCP URL: /tool-packs/<TOOL_PACK_ID>/registered-users/<REGISTERED_USER_ID>/mcp.

You can also create Tool Packs via the API. See the Tool Packs reference.

Individual vs shared credential scope

When you add a Connector to a Tool Pack, you pick the credential scope.

Pick Individual when each end user has their own account in the third party - typical for B2B agents acting on a user’s personal Salesforce, GitHub, Notion. Each user authenticates once; their token is theirs.

Pick Shared when one set of credentials should serve a whole tenant - typical when a Company has a single Slack workspace and any of their users’ agent calls should post as the Company. One person on the Company’s IT team authenticates once; everyone else inherits.

If you’re unsure, pick Individual. Switching from Shared to Individual later is harmless; the reverse means re-authenticating every user.

Tool descriptions and inputs

Two ways to shape what the model sees per Tool Pack:

• Description overrides. Rewrite a tool’s description so the model picks it correctly. Useful when your domain has different terms than the third party - your “ticket” might be the third party’s “issue.” See Tool Description Overrides.
• Input overrides. Hide or constrain fields on a tool’s input schema. Useful for forcing a project ID, hiding a paginator, narrowing an enum. See Tool Input Overrides.

Both apply at the tool-pack level, not org-wide. Different packs can show the same tool with different descriptions or different shapes.

Editing a pack with active users

Edits to a Tool Pack take effect on the next tool call - no token rotation, no re-authentication needed. Specifically:

• Adding a tool. Existing Registered Users using this pack will see the new tool the next time the agent 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. If an agent tries to call it, the call returns 403 unauthorized_tool.
• Changing description / input overrides. Same as adding - picked up on the next tools/list.
• Changing credential scope (Individual ↔ Shared). Existing credentials are not migrated. New users get the new scope; existing users keep what they had until they re-authenticate.
• Removing a Connector. The Connector and all its tools stop being callable. Stored credentials are not deleted - if you re-add the Connector later, users don’t have to re-authenticate.

For high-volume packs, prefer adding new tools or making them configurable rather than removing tools mid-flight; mid-flight removals can break agent runs that picked the now-missing tool from a stale list.

Security Gateway overrides per pack

You can override Security Gateway rules per Tool Pack. The org-level rule still exists; the override changes the action just for one pack. Common pattern: block credit card numbers org-wide, allow them on a payments-team pack that legitimately needs to read them.

Configure overrides on the Tool Pack’s Rules tab.

Next

Set up the identity Agent Handler attaches credentials to with Registered Users.