Tool permissions
A connector rarely needs to expose everything it can do. Tool permissions decide which of a connector's tools skills may call, who may call each one, and which calls pause for a human before running.
Enabling the right tools
After a connector is created, Sync tools discovers what the server offers — from its OpenAPI spec, its native MCP endpoint, or its sandboxed package. Each discovered tool appears as a row in the Tool permissions section of the connector's configuration, with an Enabled checkbox. When a tool is disabled, nobody can call it through Harriet, whatever their team.
Large APIs can sync dozens or hundreds of operations, so the header keeps count (for example, 2 of 84 enabled). When a sync discovers 50 or more tools, Harriet disables new tools by default — you opt in to each one deliberately rather than accidentally exposing a broad admin surface.
Enabled tools can carry further restrictions:
| Setting | Effect |
|---|---|
| Roles | Only people with at least one selected role may call the tool. Empty means any role. |
| Groups | Only members of the selected teams may call the tool. Empty means any team. |
| Requires confirmation | The tool pauses for human approval before running. |
These checks are enforced server-side at call time, so they hold across every surface: a disabled or denied tool is filtered out of the tool list a device receives and rejected if called anyway. Restricting who can reach the skill itself is a separate layer — see Assigning skills and connector access control.
The usage_guide tool
Alongside a connector's own tools, Harriet appends one of its own: usage_guide. It is added automatically to every skill served through Harriet's gateway whenever the skill has guide content, and it returns the skill's instructions — its SKILL.md, prompt text, or description — plus any bundled files by name.
This is how the model on a device loads a skill's full instructions on demand instead of guessing how to use the tools. You do not configure or maintain it; it is always permitted, and it appears in tool lists like any other tool.
Approval prompts in Harriet Desktop
Permissions do not end at configuration. When a tool call needs sign-off, Harriet Desktop surfaces a permission request showing what is being requested, and the person replies allow once, always, or deny. Allowing once never widens what is permitted later; the prompt simply returns next time.
Tools an admin marked Requires confirmation arrive on devices flagged to ask before running, so risky operations — sending mail, changing a system of record — get a human check even when the tool itself is enabled.
How tool calls are audited
Every tool call through Harriet's gateway lands in the audit log: the person, device, skill, tool name, and outcome, with upstream failures recorded separately from Harriet-side errors so you can tell whose problem it was.
By default the log records that a call happened, not its contents. An account owner can additionally turn on storage of tool arguments and results for debugging; viewing that payload data requires its own permission on top of audit access.
Argument and result capture is most useful during rollout, when you want to compare what the model sent with what the API returned. Consider switching it off once a connector is stable.