Only the ones it needs, and ideally read-only versions first. Anthropic's routines page says all your connected connectors are included by default and Claude can use every tool from an included connector, including writes, without asking during a run. Remove everything the task does not use.
The default is generous
When you create a routine, every connector on your account comes along, and the run can call any of their tools unprompted. If you have connected chat, ticketing, email and a code host, a nightly summary task can in principle send messages or create tickets, whether or not you meant it to.
Connector traffic reaches services through the vendor's servers, so network allowlists do not limit it. The page says connector requests do not need allowlist changes, which also means a network restriction will not stop them. The connector list is the control.
A decision table
| Task purpose | Connectors to include | Connectors to remove |
|---|---|---|
| Morning summary of merged pull requests | Code host, read only if possible | Chat write, email, ticketing |
| Backlog triage | Ticketing with limited write scope | Email, file storage |
| Docs drift check | Code host, docs repository | Everything else |
| Alert investigation | Monitoring read, code host | Anything that sends messages unless a person reviews first |
If a service only offers all or nothing access, consider a separate account with narrow rights for the automation. One connection per automation explains why.
Steps before you save
- Write one sentence on what the task must do, and what it must never do.
- List the tools it needs. Map each to a connector.
- Remove all other connectors from the routine form.
- For each kept connector, check the scope granted at authorization. Reduce it if the product allows.
- Run once manually and read the transcript for tool calls you did not expect.
- Repeat the check whenever you edit the task, because edits can re-add connectors.
Desktop tasks differ
The Desktop page says MCP tools marked as requiring user interaction prompt on every call, with no always-allow option, so runs that call them stall each time. That is an intentional brake for sensitive tools. Local tasks can also use MCP servers from config files, so review those files as well.
Revoking later
If a connector is compromised or retired, revoke it at the source and then check every task that used it. The routines page notes that a routine whose GitHub connection lapses skips runs for up to 72 hours before turning off. For the broader checklist, see revoking an MCP server from every agent.
Worked example: trimming a backlog triage routine
A product team wants a routine that runs each weeknight, reads new issues from the tracker, assigns labels, and posts a morning summary in chat. The creator has eight connectors on the account: code host, issue tracker, chat, email, calendar, a document store, a customer support desk and a spreadsheet tool. By default, all eight are included.
Walk through the trim. The job needs to read issues, write labels, and post one message. That maps to the issue tracker and the chat connector. The code host might help to see which component an issue touches, but only to read. Everything else goes: email, calendar, document store, support desk and spreadsheets have nothing to do with the job. Removing them takes a minute and removes six paths for a misguided or manipulated run to read private material or send messages to the wrong place.
Then the creator looks at scope. The issue tracker connector was authorized with full write access across all projects. The job only needs one project. If the product lets the creator authorize a narrower grant, they do so. If not, they ask whether a separate account with access to only that project can be used for the connection. The chat connector can post to every channel. A bot restricted to one channel is better.
Scope questions for each connector
| Question | Why it matters |
|---|---|
| Which tools does this connector expose? | Some include delete and send tools you never need |
| Is read separable from write? | A read only grant limits the worst case |
| Can access be limited to one project, channel or folder? | Narrower grants reduce blast radius |
| Whose identity does it use? | Actions appear as that person |
| How do I revoke it? | You need a tested path before an incident |
What goes wrong when you do not trim
- A summary task sends an email because the email connector was there and a hostile input asked.
- A task that was meant to read one folder reads a whole document store.
- A leaver's connectors keep working after their role changes, because the routine still holds the grants.
- A new connector added to the account later appears in a new routine by default, widening access without anyone deciding to.
That last point deserves a habit. Whenever you connect a new service, check which existing routines would pick it up when edited, and whether defaults include it for new ones.
Review cadence
Open each task's connector list when you review the register. Ask whether each connector was used in recent runs. Transcripts show which tools were called. A connector that no run has used in a month is a candidate for removal. Treat the list as access that must justify itself.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a server and its tools are registered, and think about which you would leave out of a scheduled task.
Quick check
Does a network allowlist limit connector actions?
Not according to the routines page. Connector traffic goes through the vendor's servers, so scope the connector list and the permissions on the account.
Should a summary task have write access?
Usually no. Start read only and add write access only after you have reviewed several runs.
Should I use a separate account for each automation connection?
Where a service cannot narrow scopes, a dedicated account with limited access is a sound way to contain a run. It also makes attribution and revocation simpler.
Sources
Last reviewed: 19 October 2026.
