How do we turn MCP tools on or off for specific groups?

Large MCP connectors—especially OpenAPI / Swagger APIs—often expose dozens or hundreds of operations. You rarely want every employee to invoke all of them. On the connector configuration page, Harriet lets you sync tools, turn individual endpoints on or off, and restrict who may call each one by group or role.

Important: The vendor’s organization API key (if your connector uses one) is stored only in Company settings by IT. End users never receive that key. They access tools through Harriet-authenticated, subscoped paths—Harriet chat and workflows under their user account, or Endpoint AI with a per-user, per-device MCP proxy credential that exposes only the tools you enable for their groups.

This section is the first line of defense before request/response hooks (see How can we restrict a shared-key MCP connector to each user's own data?): disable admin tools entirely for most users, and expose only the one or two endpoints employees actually need.

Where to configure this

1. Open Company settings → Integrations and select your MCP connector (or finish New connector—see How to create an MCP connector (Company settings)).
2. Scroll to the Tool permissions section on the connector configuration page.
3. Click Sync tools so Harriet discovers operations from the OpenAPI spec, native MCP server, or sandboxed package.
4. For each tool in the list, use the Enabled checkbox and optional restrictions (groups, roles, confirmation).
5. Save the connector.

The header shows how many tools are enabled, for example 2 of 84 enabled.

Enable and disable individual tools

Each synced tool appears as a row with:

• Tool name and description (from the upstream spec or MCP server)
• Enabled — when unchecked, no user can call that tool through Harriet, regardless of group membership

Turn tools off unless you have a clear use case. For APIs with many endpoints, Harriet disables new tools by default when a sync discovers 50 or more tools—so you opt in to each one deliberately rather than accidentally exposing a broad admin surface.

Disabled tools are not offered to agents in chat, workflows, or Endpoint AI paths that honor connector permissions.

Restrict by group or role

Expand Show restrictions on an enabled tool to set:

Setting	Effect
Roles	Only users with at least one selected Harriet role may call the tool. Leave empty for any role.
Groups	Only members of selected customer groups may call the tool. Leave empty for any group.
Requires confirmation	The tool pauses for human approval before running (common in workflows).
Sub-agent access	Whether workflow sub-agents may use the tool (see How do MCP tools work inside workflow agents?).

If both Roles and Groups are set, the user must satisfy both (have a listed role and belong to a listed group).

Group restrictions are evaluated against the signed-in Harriet user at call time—the same check applies in Harriet chat, workflows, and Endpoint AI MCP proxy traffic. Disabled tools and group denials are enforced server-side; users cannot bypass them by obtaining the org vendor key (they never receive it—see MCP authorization and stored credentials).

Example: power users vs employees on one connector

Suppose an MDM or endpoint API syncs tools such as list_my_devices, list_all_devices, lock_device, and wipe_device.

A practical split:

Tool	Enabled	Groups	Notes
list_my_devices	Yes	All employees (or everyone)	Safe self-service read
list_all_devices	Yes	IT admins only	Org-wide inventory
lock_device	Yes	IT admins	Optional Requires confirmation
wipe_device	Yes	IT admins	Requires confirmation strongly recommended

Employees in the general population group can ask Harriet about their own device via the one enabled tool they can access. IT staff in the admin group retain the broader toolkit.

Combine with hooks on read tools if the org API key still returns more data than a user should see—see How can we restrict a shared-key MCP connector to each user's own data?

Skills and channels still matter

Tool permissions gate whether a user may invoke a tool on a connector. Separately:

• A skill must attach the connector and be enabled for the chat channel, workflow step, or Endpoint AI rollout you care about.
• Users only see tools for integrations linked to skills they can reach.

Typical rollout:

1. Sync tools and configure permissions on the connector (this article).
2. Attach the connector to one or more skills—for example a narrow Employee devices skill vs a broader IT endpoint admin skill.
3. Assign skills to the right groups and channels so each audience gets the right Harriet surface.

See How do we connect external tools using MCP? and Permissions and groups for the wider access model.

Guardrails

• Default deny for large APIs: After sync, review the tool list before enabling anything for production skills.
• Do not rely on the model to avoid tools: Disabled tools are blocked server-side; enabled tools without group restrictions are callable by anyone who can reach the skill.
• Re-sync after API changes: New upstream operations appear on the next Sync tools; re-check Enabled and group settings after vendor updates.
• Writes and destructive actions: Keep them off for employee groups; use Requires confirmation for IT workflows where appropriate.
• Endpoint AI review: When enabled, submit connector changes through the review queue before broad deployment.

Related articles

See How to create an MCP connector (Company settings), How can we restrict a shared-key MCP connector to each user's own data?, How do we adapt an existing API into an MCP connector?, MCP authorization and stored credentials, and How do MCP tools work inside workflow agents?