Automation and Agents
Notion Agent MCP Connections: Decide What It Can Access and Approve
A decision guide for Notion Agent MCP connections: check access and account permissions, inspect evidence, and review a proposed external write.
On this page
- Define the task before choosing a connection
- Check plan, workspace, and device access
- Identify the account and its actual reach
- Make the first request an inspectable search
- Prepare the issue as a reviewable artifact
- Check approval settings before a write
- Maintain the connection as the task changes
- Review Custom Agent access separately
- Make a decision the team can revisit
A support lead receives a report that a CSV export sometimes stalls. They want to search GitHub for a related issue and, if there is no useful match, consider creating one. The search gathers information. Creating an issue changes a shared work queue. Those steps need separate decisions about evidence, account access, and approval.
Notion’s September 15, 2026 release says Notion Agent can connect to external tools through MCP, including custom connections. Notion’s MCP help page says a connected Agent can look up information and take actions in another app. A personal connection uses the person’s account and available permissions. Supported tools can be configured to run automatically or require approval.
The CSV report is a hypothetical example. No account was connected, search was run, approval prompt was observed, or issue was created for this article. The useful question for an operations lead is specific: can this person use this connection to investigate this report, and can someone review the exact proposed change before it reaches GitHub?
Define the task first. Then check the workspace, external account, supported tools, and approval settings. Inspect the search results before deciding whether an issue is warranted. If it is, review the proposed content and destination before approving a write. These checks turn Notion’s documented capability into a decision about a particular job.
Define the task before choosing a connection
“Connect GitHub” describes setup, but it does not tell the lead what to look for. A useful first request for the fictional report would ask Notion Agent to find issues about CSV exports stalling, return relevant links and their stated status, and flag uncertainty about whether they describe the same symptom. The lead could compare those records with the original report.
The possible write needs its own purpose. If no convincing match appears, the lead might ask for proposed issue text in chat. A draft can be corrected without changing GitHub. A created issue becomes a record colleagues may see, discuss, assign, or act on. Before creating one, the team needs to know which repository it belongs in, what evidence supports it, what remains unknown, and who should approve it.
Notion’s MCP help page includes examples of finding information in connected apps and creating a GitHub issue. Those examples establish the kinds of requests Notion describes. They do not establish which tools a particular server exposes to a particular account. Check the chosen connection before making issue creation part of a team procedure.
The report also needs a status boundary. “CSV export sometimes stalls” is a reported symptom. It does not establish a cause, reproduction condition, severity, or fix. An issue draft could preserve the reporter’s wording, identify the affected workflow, link related records, and list questions for investigation. If it names a cause or says someone reproduced the problem without evidence, the reviewer should correct it.
Name that reviewer before running the task. The person who authenticated the connection can examine its account and settings. A repository owner may be better placed to decide whether a new issue belongs in that project. The captured Notion documents do not assign these roles. The team needs to assign them for its own workflow.
A bounded first trial has an inspectable search answer and, if needed, a proposed issue draft. A write becomes a separate step after someone checks the evidence, destination, account, and approval setting. For the broader decision about whether this task deserves automation, Rise’s practical test for what to automate examines input stability, judgment, failure consequences, and maintenance.
Check plan, workspace, and device access
The MCP help page, undated in the supplied capture, says Notion Agent MCP connections require a Business or Enterprise plan. It says workspace admins may limit which servers members can connect. People can add MCP servers on web and desktop; the page says this is unavailable on mobile. These are documented conditions, not findings about this team’s account.
The September 15 release describes Custom MCP connections as beta on Business and Enterprise plans. The help page says the Add Custom MCP option depends on the workspace allowing custom servers. Its troubleshooting section adds that the button appears only for admins. A team needing an unlisted server should establish whether the workspace permits custom servers and who has the control to add one.
Before treating a connection as available, record the workspace plan, the server needed for the task, whether the workspace allows that server, and who can add it. A Business or Enterprise plan alone does not show that a particular server is approved. For a custom server, Notion’s security guidance says Notion has not reviewed that server and its host controls the tools it exposes. Workspace content shared with the Agent may be supplied to the server during tool calls. The lead should review the server and limit the data and tools available for this task. A visible connection also does not show that the external account can reach the repository the lead needs. These are separate checks, and an access request to an admin should say which one failed.
Keep the device claim narrow. The help page addresses adding an MCP server on web or desktop. It does not settle every later use of a connection that was already added. Set up the proposed trial on a documented surface. If mobile use matters to the team, verify that workflow separately.
Once the workspace permits a connection, the next question is whose external account stands behind it. That account affects what an answer can contain and what an action could change.
Identify the account and its actual reach
The help page says a personal MCP connection belongs to the person who authenticates it. Notion Agent uses that person’s account in the external app and has the same permissions the person has there. Teammates who want the same server must connect with their own accounts.
Imagine two support leads searching for the fictional CSV problem. One can see the repository containing an earlier report; the other cannot. They might receive different answers to the same request. That is an inference from Notion’s documented account model, not an observed test result. An empty response needs an access check before anyone treats it as evidence that no issue exists.
For the proposed task, identify the account owner, external app, expected repository, and access needed for the search. If issue creation is under consideration, identify the access that action would require too. Ask the account owner to check the relevant resources in the external app and inspect the connection in Notion. “We connected GitHub” is too broad to establish that this person can search the right project.
Notion’s account-permission statement does not list every action available through a particular connection. The help page refers to settings for supported tools, but it does not identify the tools exposed to this hypothetical GitHub account. Inspect the selected connection’s supported actions and approval settings before relying on it for a read or write. An app name, account role, or release announcement cannot establish its exact action surface.
The same distinction matters when several people use a shared procedure. A successful search through one lead’s account does not establish another lead’s access. The procedure can name the project and the required check, while each person verifies their own connection. That keeps a permission failure from being misdiagnosed as a search failure.
Record the account used when reviewing a result. If a colleague later asks why an issue was missed, the team can examine the connection, accessible repository, and request that produced the answer. Without that record, the team may have a good summary and no way to judge how complete its underlying search could have been.
Make the first request an inspectable search
Begin the proposed trial with a request to find information. Ask the Agent to find issues about CSV exports stalling and return the references behind its answer. The lead should open relevant links and compare each record with the reported product, symptom, and period. A matching phrase in a title is a lead. It does not prove the new report is already tracked.
Different findings call for different next steps. An issue about another export format may be irrelevant. An older issue with a similar symptom may need a product owner’s judgment before the lead links the two. An open issue with a close match may make a new issue unnecessary. The Agent’s summary can organize this material, while the linked records give the lead a basis for deciding.
A useful search record would include the question asked, connection named, account used, links returned, relevance of each result, and unresolved points. This is a proposed review method for the fictional report. It gives the lead something to inspect and a way to explain why a new issue was or was not considered.
If the Agent returns no match, inspect the conditions of the search. Did it use the intended connection? Could that account reach the repository? Might existing issues describe the symptom in different terms? Did the request fail or time out? The help page advises naming a connection when the Agent does not use the expected one. One query through one account cannot establish that no related record exists anywhere.
The lead’s first decision is whether the returned records are relevant and sufficient to choose a next action. Ambiguous results may call for a refined search or a person who owns the project. A fitting existing issue may call for an update in the team’s normal process. A search with no convincing match after an adequate check may justify preparing a new issue for review. None of those branches requires an immediate write.
- Search: What the lead reviews: Account, query, returned links, and gaps; Effect in the external app: The request seeks information; Decision: Are the results relevant enough to guide the next step?
- Draft in chat: What the lead reviews: Proposed repository, title, body, and supporting links; Effect in the external app: The proposed text remains in chat; Decision: Does it accurately describe the report and its uncertainty?
- Create: What the lead reviews: Exact destination and fields, connection setting, and reviewer; Effect in the external app: A new issue is written if the action succeeds; Decision: Is this the right record to create, and has the responsible person approved it?
The table is a plan for reviewing the hypothetical workflow. It does not claim that a particular MCP server offers every step or that any step has been performed.
Prepare the issue as a reviewable artifact
If a new issue appears warranted, ask for proposed text in chat before creating anything. The draft should state the reported symptom, identify its source, include relevant search links, and list details still needed for investigation. It should avoid asserting a cause, owner, severity, or fix unless the supplied material supports one.
The destination deserves the same attention as the wording. An accurate issue in the wrong repository can misdirect work. Review the repository, title, body, and any proposed labels or assignees. Check whether an existing issue already covers the report and whether the project owner wants a new record, an update to an existing one, or more information first.
Suppose the draft says, “CSV export stalls after users select a date range.” The fictional report says only that exports sometimes stall. The date-range condition needs a source; it should not enter the issue as an observed reproduction step merely because it sounds plausible. Compare the exact proposed fields with the original report and linked issues, not just the Agent’s description of what it intends to write.
The reviewer can use four questions to reach a decision. What observation supports each factual sentence? What remains a report or hypothesis? Is this the correct repository and type of record? Would the proposed labels, assignee, or wording cause colleagues to treat an unresolved point as settled? If so, revise the draft before considering approval.
Keep draft, approval, and result distinct. An issue drafted in chat does not exist in GitHub. A lead’s approval does not prove creation succeeded. After an authorized write in a real workflow, the team would inspect the resulting record and compare it with the approved draft. No such write or result occurred for this article.
The team may decide to gather context through Notion Agent and file issues manually. It may later allow a bounded write in one repository while reviewing other destinations separately. The right scope follows the task and the account; Notion’s general capability announcement cannot make that operational decision for the team.
Check approval settings before a write
The MCP help page says supported tools for a connection can run automatically or require approval. It advises setting Notion Agent to ask permission before creating or updating content in a connected app. Notion’s security guidance says human confirmation is the default for non-read-only tools, but settings can still differ when the task is run. The release describes confirmations as a control. Those statements support inspecting the selected connection and requiring approval for a proposed issue write. They do not establish that every action pauses in every configuration.
Before using this hypothetical workflow, inspect which actions the server supports and how the connection is configured to approve them. Check whether the approval step lets the reviewer see enough detail to judge the intended change. A setting remembered from another account, server, or agent does not establish the setting on this personal connection.
Approval needs a clear object. For an issue, the reviewer should see the repository and fields to be written, then compare them with the report and existing records. The independent OWASP MCP Security Cheat Sheet recommends least-privilege access and showing full tool parameters for sensitive approvals. That is general security guidance, not evidence that this Notion connection displays every field. Wording may be accurate but duplicative, premature, or directed to the wrong queue. If the approval prompt does not show enough detail, use a separate draft and review step before authorizing the write.
A permission prompt governs execution. The team still has to decide whether the action belongs in its process. The authenticated account owner may understand the account’s scope. The repository owner may understand the queue. Sometimes they are the same person. The Notion pages do not assign responsibility to either role, so the team needs to name its reviewer.
Start with search and draft review. That lets the lead inspect relevance, source support, wording, and destination before a write is considered. If the workflow later expands to editing existing issues or acting in another app, inspect those supported tools, destinations, and settings separately. A well-reviewed issue draft cannot validate every future action through the connection.
Maintain the connection as the task changes
The help page describes three routes to a connection window: ask Notion Agent to connect an app; choose All sources in chat, then MCP servers and Add MCP server; or open Settings → Connections and the Discover tab. A permitted custom server uses Add Custom MCP, subject to the workspace and admin conditions above. The person then authenticates with the external app. Check these documented paths against the controls visible in the intended workspace.
After authentication, the MCP help page says the connection appears under All sources → MCP servers in chat. The lead can confirm it there before sending the bounded request. Naming the connection in the prompt can help when the Agent does not use the expected one.
Record why the connection exists: task, account owner, expected project, intended read and write actions, approval setting, and reviewer. This is an operational recommendation. It gives the team a basis for reviewing the connection when the task, account access, server tools, or settings change. A connection created to investigate one repository should have its scope reviewed before it is used for a different queue.
The help page says a person can disconnect an app through Settings → Connections and that Notion Agent stops using that personal connection right away. It also says an admin can remove someone’s connection. A colleague’s separately authenticated connection needs its own review; removing one person’s connection does not establish that the whole team lost access. Source: Notion MCP help.
Treat an error or timeout as an incomplete request. The help page suggests trying again or reconnecting after a connection error and narrowing a large request that times out. Those steps may help complete a search. A failed response does not establish that no relevant issue exists.
Review Custom Agent access separately
A personal Notion Agent connection does not automatically provide an external app to a Custom Agent. The MCP help page says Custom Agents have their own connections, which must be added in the agent’s settings and authenticated again. The Custom Agent MCP help makes that boundary more precise: each connection is unique to one Custom Agent, uses its authenticator’s credentials, and has its own tool settings. Moving the fictional issue workflow into a Custom Agent calls for another connection and access review.
The September 15 release says a Custom Agent can call other Custom Agents as sub-agents, each with its own instructions, context, access, and model. If the team later proposes delegation, it should map which agent receives the report, what context each agent receives, which connection each uses, and where a person reviews a proposed external change. Similar names or instructions do not establish identical access.
The Custom Agent help also says people with permission to interact with an agent can use its connected tools, even without their own access to the external app, while only the person who authenticated a connection can change its tool settings. A team should therefore review who can interact with that agent as well as whose credentials it uses. The release does not establish sub-agent plan eligibility, rollout, or behavior in a particular workspace. The initial decision here concerns a personal connection and one bounded task. Custom Agent delegation becomes relevant when the team has a reason to move that task and can check the new access boundaries.
Make a decision the team can revisit
The lead can proceed with the information task when the workspace permits the server, the intended account can reach the relevant project, and a person can inspect the returned references. A proposed external change needs another decision: confirm the supported action, inspect its destination and content, verify that approval is required for that action on the relevant connection, and identify the reviewer.
A short decision record can make the result usable later:
- Who is connecting?: Record for this task: The named external account and its owner
- Why?: Record for this task: The specific search and any separately proposed write
- Where?: Record for this task: The server and expected repository or other destination
- What can be checked?: Record for this task: Relevant resources, supported actions, and approval setting
- Who decides?: Record for this task: The person who reviews the evidence and proposed change
- What happened?: Record for this task: Links inspected, decision made, and any resulting record
For the fictional CSV report, every account-specific and outcome field remains unresolved because no trial occurred. In a real review, leave any unchecked field explicitly unresolved. An absent server raises a workspace access question. An account that cannot reach the repository raises a permission question. An ambiguous search raises an evidence question. An issue draft without a reviewer raises an action question. Resolve the particular gap before treating the workflow as ready.
The decision should be revisited when the account, server, intended task, or approval setting changes. A past search can show what one account found under one set of conditions. A reviewed issue can show what one person approved. Neither result grants standing authority for different records or actions.
Notion documents the ability to connect tools. A team can make that ability useful by defining the task, checking whose account the connection uses, inspecting the evidence it returns, and reviewing any proposed change before it reaches a shared system. The workspace controls, account access, approval settings, and observed results determine the team’s answer for this workflow.
For the shared instruction decision, read how to maintain a Notion skill in Codex.
Checked for this article
Sources
Keep going
Related notes.
Automation and Agents
GPT-6 Astra Approvals: Where Should a Computer-Use Agent Stop?
A computer-use model can propose an action, but your application decides whether to execute it. Put the stop point in the host system, define what requires a human, and verify the resulting state before the workflow continues.
Read the article
Automation and Agents
Claude Opus 5.5 for Unattended Coding: Where Should Review Stay?
A practical framework for deciding what a coding agent may do alone, when it should pause, and what a reviewer needs before accepting its work.
Read the article
Automation and Agents
Claude Opus 5.5 Pricing: What Does an Accepted Coding Task Cost?
Anthropic lists lower Opus 5.5 rates, but an agency’s useful measure is spend per accepted coding result. Here is a reviewable pilot and a transparent cost calculation.
Read the article