Agent permissions and access rules

Toolstile permissions decide which tools, resources and prompts an agent may use from each MCP connection. Direct grants and assigned policies combine their allows, while a matching block in either source wins. Full access includes new supported capabilities the server adds later. Permission edits take effect after you save them; previews let you inspect proposed changes first.

Choose the workspace and agent

Each agent authorization belongs to one workspace. A personal connection and a team shared MCP entry have separate access settings, even if they connect to the same provider. Choose the workspace you intend to change before editing access.

Team owners, admins and custom roles with Manage agent access can configure individual agent grants. Joining a team or grouping agents under a device does not grant those agents access to shared entries. Each agent needs its own grant or policy assignment.

A device groups agent connections so you can manage them together. For example, your laptop may contain a coding agent and a research agent. Those agents can have different permissions, and revoking one agent's workspace access leaves the other's authorization in place.

Select capabilities or grant full access

Permissions cover more than tools:

• Tools are actions the agent can call, such as searching issues or updating a record.
• Resources provide content the agent can read. Rules can name a resource URI or match a resource URI template.
• Prompts are templates the server offers for structuring a request, such as a review checklist the agent can fill in.

A selected grant allows the capabilities you list. Tool and prompt entries use exact names; resource entries use URIs or URI templates. Enter one value per line in the relevant allow or block field.

Full access allows the connection's supported tools, resources and prompts, including new ones it adds later. Existing explicit blocks still apply. Full access applies to the selected MCP entry; it does not grant access to every connection in the workspace.

If you want to review new tools before an agent can use them, turn on tool review for the MCP entry, or keep full access off and list the permitted names. A resource matching an already allowed URI template can be permitted without a new rule.

Start from a suggested selection

For some popular integrations, Toolstile has reviewed each tool's description and written a suggested starting selection, such as reading issues and projects. In Access, choose an agent, then choose a suggestion above its tool list. It adds the listed tools this server offers to your draft: lookups are allowed, and tools that can change data, read logs or look up people are set to Require approval. Existing access stays as it is, blocks and approval requirements stay in force, and the suggestion doesn't grant tool names the server adds later. Nothing changes until you choose Save changes, so check the highlighted rows first.

A suggestion is a starting point reviewed by Toolstile, not a guarantee: the server decides what each tool does. Each integration's page lists its suggestions and their exact tools. Suggestions are not offered while Everything, including ones added later is on.

Direct grants, policies and blocks

A direct grant applies to one agent authorization and one MCP entry. A reusable policy contains rules you can assign to multiple agents. An agent can receive access from its direct grant and assigned policies at the same time.

The rules combine as follows:

1. A matching block in any applicable source denies access.
2. Otherwise, a matching Require approval rule in any applicable source makes each call wait for review.
3. Otherwise, full access or a matching allow in any applicable source permits the capability.
4. Without an applicable allow, access is denied.

A direct grant does not take priority over a policy. Removing an allow from one source may leave another source's allow in effect. To deny a capability that another grant permits, add a matching block or remove every applicable allow.

For example, suppose an issue-tracker connection exposes search_issues, create_issue and delete_issue. Your coding agent has full access through a policy, but its direct grant blocks delete_issue. It can use the other tools; deletion stays blocked. Adding delete_issue to a second policy's Allow list does not change that outcome.

These names are illustrative. Use the names exposed by your actual connection when editing its rules.

Require approval for specific tools

Some tools are worth allowing only after a person checks each call, such as sending a payment, deleting a record or merging a pull request. In Access, choose Require approval for those tools. Toolstile does not guess whether a tool reads or writes from its name or annotations, so pick these tools yourself. Resources and prompts keep their normal allow and block settings.

When the agent calls a gated tool, it gets a result saying approval is required, with a review link. Open Approvals to see the agent, connection, account and the exact arguments, then choose Approve once or Deny. In a personal workspace the connection owner reviews calls; in a team workspace, owners and admins do.

Approving does not run the call. The agent retries the identical call, and the approval covers only those arguments. Different arguments need a new approval, and changing the selected account or the rules cancels an earlier one. Pending requests expire after 15 minutes. Calls that are waiting for approval or were denied do not count as operations.

Review new and changed tools

An MCP server can add tools or change a tool's description, inputs or outputs at any time, and agents act on those descriptions. Open Tool reviews, choose an MCP entry and turn on review. Toolstile accepts the tools the entry has at that moment. After that, a new tool, or a tool whose definition differs from the accepted version, is hidden from agents and refused if called, until an owner or admin accepts it. This also applies to tools allowed through full access.

Each change shows the difference from the accepted version. Accept makes that exact version available; a later change waits again. Toolstile checks the definition on every call, so a change made after an agent listed its tools cannot run before review. Owners and admins get a notification when something is waiting. Accepting a new version cancels approvals that were requested for the previous one.

Changes are noticed when an agent lists or calls tools, or when someone refreshes the entry's tools. Review compares what the server reports: it cannot detect a tool that behaves differently behind an unchanged description. Turning review off forgets the accepted versions.

Ask for access

In a team workspace, a member whose agent needs a tool it does not have can open Access requests and choose Ask for access: pick the agent, the MCP entry and the tools (or full access), and say why. Owners and admins are notified. Before deciding, they see exactly how the agent's direct grant would change, and which requested tools an explicit block or Require approval rule would still hold back.

Approving updates the agent's direct grant and nothing else: no call runs, and a call that was refused earlier is not replayed. The agent retries the task. A second request for the same agent and entry widens the open one instead of adding another. Requests and decisions are recorded in the workspace audit log.

Edit and save access

Open Access in the selected workspace and choose a server. The Tools, Resources and Prompts tabs list what the server offers now, with one column per agent grouped by device. Check a box to allow that capability for that agent. Everything, including ones added later in an agent's column gives full access, including capabilities the server adds later. Unchecking a box that is allowed through full access records an explicit block for that agent. Use Add row for a name the server does not list, or for a resource URI template. Edits stay as a draft until you choose Save changes; Discard drops them.

The Policies page shows how direct grants and policies combine. Its Direct grants view lets you pick an agent authorization and MCP entry, edit the rules, and preview the effective access together with any saved policy assignments. Save direct grant applies the change; Discard changes restores the saved rules. Editing fields or looking at a preview does not change active permissions, so check the save result before relying on a restriction.

In Reusable policies, saving an existing policy updates every agent assigned to it. Save a new policy before previewing it with an assigned agent. In Policy assignments, a proposed change stays staged until you choose Save assignment.

Reusable policies need Starter or above, and custom management roles need Team or above. On Free you manage access with direct grants and blocks, which work the same way on every plan. Check pricing for availability.

Understand what the agent can see and do

Toolstile filters discovery using the same permission rules it applies to execution. A blocked tool is omitted from the agent's tool list, and a call does not become permitted merely because the client remembers its name.

When Toolstile refuses a call, the agent is told why: it has no grant for the tool, an explicit block applies, or the tool's definition is waiting for review. The message names the next step, such as the Access requests or Tool reviews page.

After saving changes, refresh the client's catalog or reconnect if it still shows an old list. Toolstile checks current access when forwarding requests, including membership and the selected upstream account's availability. A stale client display does not preserve a removed permission.

For shared MCP entries, capability grants apply across the entry's approved accounts, including accounts approved later. Your preferred account overrides the workspace default. If that selected account becomes unavailable, the entry stops being usable until you select an available account. See shared accounts before changing approvals or defaults.

An upstream account must also permit the requested action. Toolstile cannot grant access to a provider's records or actions beyond that account's rights. See connection authentication for the upstream sign-in steps.

Revoke access at the right scope

Revoke an agent authorization to stop that agent's access to the selected workspace. An access manager can revoke workspace authorizations, and a user can revoke their own. Removing a member also stops that member's agents from using the workspace.

Revoke your device to stop all agents grouped under it, across their workspaces. Only the device's owner can perform that broader action; a team administrator's authority stays within their workspace.

Revocation cannot undo a tool action the remote service has already performed. If an upstream credential has been exposed, revoke or rotate it with that provider as well. For an access failure, check troubleshooting; for capture and retention details, read security and data handling.

Separate management roles from agent grants

Owners manage billing, ownership and workspace deletion. Admins manage members, shared MCP entries and agent access. Custom management roles can delegate specific duties such as managing shared MCPs, managing agent access or viewing activity metadata.

A management role does not automatically grant the person's agents access to MCP capabilities. Viewing activity metadata also does not grant debug capture access: team captures remain restricted to owners and admins. Role edits require Save, just like permission edits.

If a plan change removes support for assigned policies or custom roles, the affected agents' access stays paused until a workspace admin explicitly converts it to supported settings. Review the proposed conversion and its blocks before saving.

Set up your first connection, or continue to shared accounts.