> For the complete documentation index, see [llms.txt](https://docs.darcyiq.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.darcyiq.com/build/integration-overview/tool-permissions.md).

# Tool Permissions

An MCP integration usually exposes a whole set of tools, and you rarely want Darcy to have equal freedom with all of them. Reading data is one thing; deleting a record or sending mail on your behalf is another. **Tool Permissions** lets you decide, tool by tool.

Open a connected integration and choose the **Tool Permissions** tab. Every tool the server reports is listed with its name, its description, and a three-way control.

## The Three Settings

| Setting                         | Icon           | What it means                              |
| ------------------------------- | -------------- | ------------------------------------------ |
| **Enabled**                     | Green check    | Darcy can use this tool freely             |
| **Enabled + Requires Approval** | Amber triangle | Darcy must ask you before each use in chat |
| **Disabled**                    | Red X          | Darcy can never use this tool              |

Every tool starts **Enabled**. Changes save the moment you make them — there's no save button.

**Disabled** is a hard stop, enforced in two places: the tool is never offered to the model in the first place, and it's refused if something tries to call it anyway. Darcy is told the tool was disabled by the integration's owner, so she reports the restriction rather than retrying.

{% hint style="warning" %}
**Requires Approval only applies where there's a human to ask.** It gates interactive chat, where Darcy can prompt you and wait. In scheduled automations, agent runs, and other background work there's nobody to answer, so approval-marked tools run normally.

If a tool must never run unattended, set it to **Disabled** rather than **Requires Approval**.
{% endhint %}

## Who These Apply To

Tool permissions belong to the integration, not to you. Whatever you set here applies to **everyone the integration is shared with** — there's no per-person variation.

| Your access | What you can do                                       |
| ----------- | ----------------------------------------------------- |
| **Owner**   | Change any tool's permission                          |
| **Write**   | Change any tool's permission                          |
| **Read**    | See the current setting as a label, but not change it |

{% hint style="info" %}
Granting someone Write access to an integration lets them change its tool permissions, including re-enabling something you disabled. If you want a restriction to hold, share with Read access instead.
{% endhint %}

## New Tools Are Enabled by Default

Only your explicit restrictions are stored. If the MCP server starts advertising a new tool later, it arrives **Enabled** rather than inheriting a restriction from a tool it has nothing to do with.

This keeps servers working as they evolve, but it does mean a server that adds a sensitive tool gets it enabled by default. If you're relying on tool permissions to contain what an integration can do, it's worth revisiting the tab after the server updates.

## Which Integrations Support This

Tool permissions apply to **MCP-backed integrations**, where the tool list is discovered from the server at connection time.

Built-in integrations such as Salesforce, Jira, Outlook, Google Workspace, SharePoint, and AWS ship a fixed set of tools. Their tab explains that those tools can't be configured individually.

You'll also see a message rather than a list when:

* **The integration isn't connected yet** — connect it and the tools appear
* **The server reported no tools** — test the connection, then try again

## Related

* [Integration Overview](/build/integration-overview.md) — connecting and sharing integrations
* [MCP Framework](/build/mcp-studio/mcp.md) — how MCP integrations work
* [Building Custom MCPs](/build/mcp-studio/building-custom-mcps.md) — the tools your own server exposes


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.darcyiq.com/build/integration-overview/tool-permissions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.