Tool permissions

Tool access is the part of an agent product that is worth being pedantic about. Work on Repeat models it as two independent grants rather than one switch.

The three states

Automatic execution cannot be granted to a disabled tool — the API rejects that combination outright. Enabling is a decision about capability; automatic execution is a decision about autonomy.

Why two grants

Enabling a tool says "this capability is relevant to this responsibility." Granting automatic execution says "I accept that this will happen while nobody is watching, on a schedule, repeatedly."

Those are different risks, and they are usually decided at different times: you enable a tool while designing the routine, and you grant automatic execution after you have read a trace and believe the routine uses it well.

Confirmation

Granting automatic execution requires an explicit confirmation naming the tool and stating that it may read or change connected data. Without that confirmation the API returns 409 automatic_tool_confirmation_required.

This is deliberately not a preference you can set once and forget for every tool in a project.

Annotations are context, not authorization

MCP servers may annotate tools with hints such as readOnlyHint. Work on Repeat displays these because they are useful, and ignores them for authorization because the remote server supplies them. A server that mislabels a destructive tool as read-only would otherwise be granting itself permission.

Scope is per routine

Tool policies belong to a routine, not to a connection. The same GitHub connection can offer read-only tools to an audit routine and one write tool to a routine that opens pull requests. Nothing is shared implicitly.

Rediscovery resets approvals

Rediscovering a connection's tools refreshes the remote schema and clears prior approvals, then returns the routine to draft. A tool whose definition changed must be re-approved and re-proved before it runs unattended again.

Practical guidance

What the model actually sees

Only enabled tools are assembled into the model's context, each named <connection-slug>__<tool-name>. Credentials are resolved server-side at call time — the model never receives a token, a header, or the connection URL. If the model asks for something outside its policy, the run ends with tool_denied and the attempt is recorded.