目錄
A Notion AI MCP workflow that had been working normally suddenly stopped at its first Tool Call in late August. The screen said a tool’s operation type had changed since the last administrator approval and required renewed approval before it could continue. More confusingly, many affected workspaces could not find the reapproval entry point mentioned by the error at all. Some users completely removed and reconnected MCP, only to see it fail again.
At first, it looked as though Notion had launched a new MCP permission-governance mechanism while the front-end interface had not yet caught up. Later information showed that this was not the right interpretation. On August 30, Notion formally acknowledged failures affecting some Notion AI MCP Tool Calls. After its engineering team intervened, the company announced recovery that evening. The incident lasted about six hours and 36 minutes. The same pattern appears in r/Notion discussions from August 29: Connections and the Tool List looked normal, but execution produced an operation type error. In some cases, the same MCP worked in an Agent but failed in Notion AI.
The incident itself is therefore better understood as a platform-side MCP execution failure, not a user suddenly missing an administrator approval. Still, the error message is not entirely without value. Notion is genuinely adding more granular controls for external tools based on reading, writing, and execution risk. Two things must be separated: there is no public technical RCA for why this error occurred, while official product documentation does confirm that Notion is expanding MCP and Agent permission controls.
This article reflects information available as of August 31, 2026. The administration interfaces for Notion MCP, Custom Agents, and Connections may continue to change with product updates.
What Happened With Notion AI’s “Operation Type Changed” Error?
Similar Reports Began on August 29, and Notion Formally Acknowledged MCP Tool Call Failures on August 30
On August 29, users on r/Notion began reporting that MCP Connections that had worked normally in Notion AI suddenly could not execute at all. Every error said that a tool’s operation type had changed since the previous Admin Approval and required a new administrator approval. One case named whoami specifically. Another said every MCP Tool showed the same problem and that removing and adding the Connection again did not help.
On August 30, Notion Status formally posted an incident notice saying that some Notion AI MCP Tool Calls were failing, that the engineering team had identified the issue, and that service was restored at 22:49 that day. The timeline matters because the instruction to “ask an administrator to approve again” did not necessarily mean that an administrator had missed a configuration step. At least in this wave of widespread failures, the solution came from Notion’s platform-side repair, not every user finding an Approval Button.
The first response to the same message should therefore not be rebuilding an entire automation system. Check Notion Status and the community for many reports occurring at the same time. If multiple unrelated MCP Servers fail simultaneously while Authentication and Tool Discovery remain normal, it is usually inappropriate to blame a single Connection first.
What Is an Operation Type? It Cannot Be Directly Equated With MCP’s Read／Write Field
MCP Has Behavioral Annotations, but Notion Has Not Disclosed Which Field This Error Refers To
An MCP Tool Definition may contain annotations in addition to the tool name, description, and Input Schema. These include readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. They can tell an MCP Client whether a Tool is read-only, may modify or destroy data, or interacts with the outside world.
But the MCP specification explicitly warns that Annotations are Hints, not security guarantees, and a Client must not unconditionally trust descriptions from an untrusted Server. More importantly, Notion has not published documentation saying that operation type in the error is identical to readOnlyHint. Nor has it documented which changes to Tool Annotations, Input Schema, or other parts of a Tool Definition always trigger reapproval.
The original claim that “changing a server from Read to Write invalidates its old Approval” can therefore illustrate risk, but it cannot be presented as the confirmed technical cause of this incident. The blocking of whoami also does not prove that Notion was merely comparing changed declarations. The incident produced widespread False Blocking, and Notion ultimately repaired it from the platform side.
Notion Does Classify MCP Tools as Read or Write, With Stricter Defaults for Write
MCP Tools in a Custom Agent Can Now Be Controlled Individually
Although the incident cannot prove the internal implementation of operation type, current Notion Custom Agents do expose MCP Tool Risk as a user-visible setting. Open Settings → Tools & Access for a Custom Agent and expand an MCP Connection to see the Tools provided by the Server and enable or disable each one.
Notion classifies these as Read Tools and Write Tools. Tools such as Search, Fetch, List, and View primarily retrieve information and are considered Read. Create, Update, Delete, Send, and Post change external data and are considered Write. Read Tools can be configured to run automatically. Write Tools require user confirmation by default, helping prevent an Agent from directly modifying or deleting data in an external system without human review.
This is the “Operation Risk Control” supported by official documentation today. Its concept is indeed close to the error message: whether a Tool can modify data affects whether the system requires Human Confirmation. But that does not justify the further claim that “the August 29 incident occurred because Notion detected changes to every Tool’s Operation Type and correctly blocked them all.”
Why Must Read Tools and Write Tools Be Separated?
The Biggest Difference Between an AI Agent and Fixed Automation Is That the Model May Choose the Tool Call
A traditional Automation generally follows a predefined flow. For example, after receiving a Form, it creates a Database Record and sends an Email. Every step is known before deployment. An Agent is different: the user gives it a goal, and the model may choose Search, Fetch, Create, Update, Send, or other Tools according to the current Context.
If an Agent has only Search and Fetch, a bad judgment mainly risks reading the wrong data, retrieving the wrong Context, or using information that should not appear in an answer. Once the same Agent also has Tools such as Update, Delete, Send, and Post, an error can become an external Side Effect, such as modifying a production Database, sending an Email, or deleting data.
This is why Notion repeatedly recommends least privilege in its Prompt Injection security documentation. Official guidance advises giving a Sensitive Workflow only the Pages, Databases, and Tools it genuinely needs, keeping an external Tool Read-only when writing is unnecessary, and retaining Human Confirmation for non-Read-only Tools. As AI becomes capable of more actions, security controls naturally have to move from “Can this Connection connect?” down to “Can this Tool run automatically?”
How Broad Are Notion MCP’s OAuth Permissions?
Hosted Notion MCP Generally Follows the Signed-In User’s Permissions in That Workspace
Notion’s official explanation of Hosted MCP is direct: MCP Tools operate with the Notion Permissions already held by the signed-in user. An AI Tool can read and write content the user could already access in the connected Workspace. This differs significantly from the Page-level Sharing model common with traditional Notion API Integrations. Hosted MCP uses User-based OAuth, with the main goal of letting AI Clients such as Claude, Cursor, and ChatGPT operate Notion as the current user.
“Connecting Hosted Notion MCP” should therefore not be understood as opening only one small Database to an Agent. If the OAuth user can access Projects, Clients, Meeting Notes, and other Private Pages, an AI Client connected through Notion MCP can in principle work within the same permission boundary.
This is also why a Workflow requiring a narrow data boundary cannot rely on a Prompt that says “Do not view other pages.” If a fixed program should process only a few specific databases, a traditional Notion API Integration may make it easier to create a clear Page／Database Access Boundary. When using Hosted MCP, the permissions of the signed-in identity itself must also be included in the risk assessment.
Enterprise MCP Governance Controls AI Apps and Clients, Not the Single-Tool Approval Mentioned in This Error
Enterprise Can Create an Approved AI Apps List
Notion Enterprise now lets administrators manage which external AI Apps and MCP Clients can connect to a workspace under Settings → Connections. An administrator can switch to an Approved List model and explicitly allow Claude, Cursor, ChatGPT, or another MCP-capable Client. Notion blocks later Calls from unapproved tools even if they previously obtained a Token.
Administrators can also use Disconnect All Users to invalidate all existing Notion MCP Connections. Users must then Authentication again and reconnect only through currently approved AI Apps. If an enterprise uses a supported Identity Provider such as Okta, an administrator can create an Enterprise-managed Connection and reduce the need for each member to complete OAuth separately.
These controls answer “Which AI App may connect to Notion MCP?” Tools & Access in a Custom Agent answers “Which MCP Tools may a particular Agent use, and does execution require confirmation?” Both layers use the language of Approval and can easily be confused, but they are not the same.
Current official documentation does not provide an Enterprise page saying, “When a Tool Operation Type changes, re-Approve the individual Tool here.” The late-August error’s instruction to seek renewed approval in Module Settings therefore cannot be converted into an undocumented procedure using the existing Enterprise Connections documentation.
Custom MCP Servers Have Another Permission Model
Business and Enterprise Can Connect Custom Agents to Custom MCP, but an Admin First Decides Whether Installation Is Allowed
Notion Custom Agents now support preintegrated MCP Connections and can also connect to a custom Hosted MCP Server. To use Custom MCP, a Workspace Admin must first permit Custom MCP Servers and can then decide whether members may freely install Connections or choose only from an Approved Connections list.
When a Connection is actually created, each Custom Agent has its own MCP Connection and uses the external-service Credentials of the user who originally performed Authentication. Connections are not automatically shared among Agents. If Agent A has signed into Figma, Agent B does not automatically receive the same Connection.
There is another permission effect that is easy to miss: a user with sufficient access to a Custom Agent may be able to use its connected MCP Tools even if that user has not separately signed into the external service. The Authentication identity behind the MCP Connection, who can use the Agent, and what the Tool itself can do are therefore three layers that must be examined together.
Why Did the Late-August Incident Look Like a Governance Update?
The Error Message Sounded Too Much Like a Real, Actionable Policy
Users saw a very specific statement: the Tool’s operation type had changed, so an Admin had to approve it again. The problem was that the interface had no corresponding reapproval entry point, and renewed Authentication did not necessarily work. Such an error can easily make a stricter system seem to be operating as designed, when at the time even Tool Calls with no real risk change could be blocked.
The later timeline clarifies the situation. Notion did not publish an “MCP Governance update.” It created an Incident in its Status system, directly titled around failures affecting some Notion AI MCP Tool Calls, and restored service after its Engineering Team intervened. The most reasonable classification is therefore a service incident.
Still, the incident unexpectedly exposed a normally invisible security layer. Notion AI’s Tool Runtime is clearly not simply “the Server advertises a Tool, and the model executes it whenever it wants.” There is at least another Policy Check among the Client, Connection, Tool Risk, and Confirmation layers. In this incident, one of those checks malfunctioned and blocked legitimate Tool Calls.
Is Hosted Notion MCP Replacing the Old Local MCP Server?
The Remote Version Is the Official Focus, While the Old Open-Source Server Is No Longer Actively Maintained
Notion first released notion-mcp-server, which users could download and deploy themselves. It essentially converted existing Notion API Endpoints into a set of MCP Tools. Notion later launched its own Hosted Remote MCP Server with OAuth. Its Tool Interface is no longer merely a one-to-one wrapper around the API, but includes Agent-oriented operations such as Search, Fetch, Create Pages, and Update Page.
The official GitHub Repository now clearly says the team actively supports only Remote Notion MCP. The old Local Server may eventually be Sunset, and Issues and Pull Requests in the Repository are no longer actively handled. Official Developer Docs likewise call the Local Server a Last Resort, potentially justified only when a Headless Workflow must use a Bearer Token and cannot complete User OAuth.
Another difference is that Notion controls updates to the Hosted Server. It can directly modify the Tools, Descriptions, and underlying implementation without requiring every user to update an npm Package. Notion-flavored Markdown also lets Agents read and write pages without repeatedly handling deeply nested Block JSON, completing common operations with fewer Tool Calls and Tokens.
But this advantage also means that the Tool Surface continuously evolves on the service side. There is no official RCA proving that a Hosted Tool Definition Change caused the late-August incident, so that cannot be stated as a known cause. What can be said is that the Hosted Model speeds up Tool updates, and workflows depending on those Tools have more reason to manage service status and Schema Change as external dependencies.
How to Troubleshoot a Sudden Operation Type Error in Notion MCP
First Check Notion Status; Do Not Immediately Tear Down the Entire Connection
If the Tool List remains available and Authentication looks normal, but every Tool Call suddenly shows the same Policy／Approval Error, first check Notion Status for an incident involving Notion AI, MCP, or Connections. The August 30 event is a typical example: reconnecting did not resolve every case, and Notion eventually had to repair the platform.
Next Determine Whether Every Tool Fails or Only One Connection or Tool
If only one Custom MCP Server fails while other MCPs work, a Server Authentication, Tool Definition, or Credential problem becomes more likely. If unrelated Tools such as Search, Fetch, and Whoami fail together, or different Servers show the same message, it is less likely that one Tool truly changed behavior without warning.
Renew Authentication After the Service Is Healthy
Notion’s official MCP Troubleshooting already recommends Disconnect／Clear Authentication followed by a fresh OAuth flow when Authentication has a problem. This step is appropriate when Status is healthy and the issue remains confined to one Connection. It is not a reason to repeatedly rebuild Connections during a platform incident.
For a Custom Agent, Inspect Tools & Access Directly
A Custom Agent’s Settings → Tools & Access shows which Tools an MCP Server provides, which are currently Enabled, and whether each is set to Run Automatically, Always Ask, or Always Allow. When a Tool truly writes, deletes, or sends data, retaining confirmation while uncertain is much safer than setting everything to Always Allow solely for full automation.
Keep Recovery Points in Production Write Workflows
A Workflow that updates a production database, sends external messages, or deletes information does not have to prohibit all Agent writing. But it should preserve ways to detect and recover from errors, such as keeping Human Confirmation on Write Tools, limiting an Agent to a specified Database, or turning large changes into Draft／Suggested Edits that are applied only after review.
On August 28, Notion had just added Suggest Edits for Agents, allowing an Agent to propose line-by-line changes for a person to accept individually. For document workflows requiring quality control, this is often easier to govern than letting an Agent edit everything directly and looking for mistakes afterward in an Audit Log.
How Should Developers Change a Custom MCP Server’s Tool Definition Safely?
Version Breaking Changes Explicitly, but Do Not Assume This Will Always Prevent Client Reconfirmation
An MCP Tool Name is an important identifier used by a Client. If an existing Tool changes from a simple query into one that modifies external data while keeping exactly the same name and description, existing Prompts, Agent Policies, and Approval Assumptions can all become inaccurate. For a clear Behavioral Breaking Change in a custom Server, consider creating a new Tool Name or at least updating the Version, Description, and Annotation together so the caller has an opportunity to reevaluate it.
But this cannot be packaged as “renaming it guarantees you will never see Notion’s operation type Error again.” Notion has not disclosed the rules of its internal Approval Cache, so there is no formal contract stating whether a change to Tool Name, Schema, or Annotation requires renewed confirmation.
What is certain is that the MCP specification provides behavioral descriptions such as readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, and Server Authors should fill them out accurately. Clients must still treat them as Hints and should not build a true security boundary solely from a Server’s self-declaration.
What Is the Difference Between Notion MCP and the Notion API?
MCP Suits AI-Selected Tools; the API Suits Fixed, Predictable Program Flows
Notion MCP’s core advantage is being Agent-friendly. An AI Client can Discover Tools and then combine Search, Fetch, Create Pages, Update Page, and other operations according to a natural-language request. Remote MCP can also use Notion-flavored Markdown and Notion AI Semantic Search, making large-scale page operations more suitable for an LLM than directly manipulating Block JSON.
The Notion API is better suited to deterministic Backend Workflows. A program calls a specific Endpoint directly, with Authentication, input, output, and error handling controlled by the developer. It also supports capabilities MCP does not yet have, such as the File Upload API. Remote Notion MCP uses User-based OAuth and currently does not support Bearer Tokens, so it is not always suitable for unattended Headless Automation. Fixed Server-to-server workflows generally still need to evaluate an API Integration.
Neither replaces the other. If the requirement is “let AI find information based on Context and decide the next operation,” MCP is more natural. If the requirement is “at 8 a.m. every day, synchronize three fields from Database A to B,” a traditional API or Worker is usually easier to test and less dependent on Agent Decision.
The Real Lesson From This Incident Is Not to Remove Every Write Tool
The late-August operation type Error ultimately proved to be a Notion AI MCP service incident, not a missing Approval Button in one workspace. There is no evidence that every affected MCP Server changed Tool behavior on the same day. Getting this wrong would distort the entire later inference that “Notion is moving all MCP use to a reapproval model.”
The message sounded plausible because it overlaps with Notion’s actual product direction. Enterprise has an AI App Allowlist. Custom Agents can configure Read／Write and Confirmation for each Tool. Prompt Injection documentation repeatedly presents Least Privilege and Human Confirmation as primary defenses. As AI Agents gain the ability to actually change data, more granular Tool Permission is already a real trend. This Incident simply was not the formal release of that trend.
For people who depend on Notion Automation or MCP workflows, the practical preparation is not memorizing this Error Message. Separate Workflows that only Read from those that Write, those that always require a person, and those that cannot be allowed to stop completely because of one MCP Service Failure. The next time a platform update or incident occurs, this makes it easier to know whether to wait for the vendor’s repair or revise your own Connection.
Frequently Asked Questions
Not necessarily. When the message appeared widely on August 29–30, 2026, Notion formally confirmed failures affecting some Notion AI MCP Tool Calls and repaired them from the platform side. That wave cannot be explained simply as missing administrator approval. If the same message later appears in one workspace, first check Status and the Connection before deciding whether a setting actually changed.
No. Notion’s general Troubleshooting does recommend disconnecting and repeating OAuth for Authentication problems, but users reported that completely removing and rebuilding a Connection still failed during the late-August incident. While a platform Incident remains unresolved, repeated authorization usually does not fix a Server-side Error.
Current official documentation does not describe a “single-Tool Operation Type Re-approval” process matching this error exactly. Enterprise has an AI App／MCP Client Approved List, and a Custom Agent can control whether each Tool is enabled and requires Confirmation. Neither can be directly treated as the Module Re-approval page named by the error.
Within the connected Workspace, Hosted Notion MCP operates with the user’s own Notion Access. Official documentation says MCP Tools can access content the user could already access. It is not a low-permission Integration that opens only a few Pages by default. A smaller boundary requires a different Authentication design or an Integration architecture better suited to fixed Page Scope.
Read Tools primarily retrieve information, such as Search, Fetch, List, and View. Write Tools change an external system, such as Create, Update, Delete, Send, and Post. By default, Notion requires confirmation before a Write Tool runs, while a Read Tool is more suitable for automatic execution when its risks are acceptable.
Most general use cases should now prioritize Hosted Notion MCP. Notion says the Remote Server is the actively maintained version, while the old open-source notion-mcp-server is no longer actively maintained and may eventually be retired. However, Remote MCP depends on User OAuth and does not support Bearer Tokens. A fully unattended Headless Workflow requiring Token-based Authentication may still need the Notion API or another self-managed integration.
MCP is better when AI needs to search, read, and select the next Tool Call from a natural-language request. The Notion API is usually easier to control for deterministic flows such as scheduled jobs, data synchronization, precise permissions, or File Upload. Both can coexist; not every Automation must become an Agent Workflow.