Two Notion workspaces, one product team
Most product organizations run more than one Notion workspace. One is the company wiki. The second arrived with an acquisition, an agency, or a team that moved before IT had an opinion. Both contain a page called Roadmap. Notion MCP access for product team work starts with deciding which of those two workspaces an agent may write to, and being able to prove afterward which one it reached.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps
In Elaichi, every connected account is advertised to the model under its own name, in the form {account}__{tool}. Two Notion accounts mean two sets of tools with two labels. The model picks between them from the label, the tool name and the description. That is a ranking decision. Ranking is the wrong layer to defend a workspace with, because a ranking always returns something.
The client side is one address. Elaichi serves one organization-wide MCP endpoint, POST /mcp, standard MCP over Streamable HTTP, behind OAuth (a sign-in flow that gives the client a token without handing over a password). You point ChatGPT at that endpoint through its admin console, and each product manager signs in as themselves. There are no per-toolbox URLs and no embedded tokens to pass around. Notion sits in a catalog of 450+, and adding Claude or Cursor later is the same address again.
How do you set up Notion MCP access for product team members?
Connect both accounts once at the organization, share them deliberately, give each member a role, and write the restrictions before you invite anyone. The order matters, so here it is concretely.
Connect both Notion accounts and label them so a human can tell them apart. "Notion Core Wiki" and "Notion Atlas Acquisition" beat "Notion" and "Notion 2". Account labels are scored during tool search, so a distinct label is doing real work rather than decoration.
Share each connection on purpose. Sharing is one building block: a grant of view, use or edit on a resource, to a user, a team, or the whole organization. A member sees only what they own or what was explicitly shared with them. No organization-level permission widens that listing quietly, and that includes org owners and admins.
Give each member a role. Exactly one role per member, enforced by a unique index, so a role is a whole persona rather than a bolt-on. The tool:execute permission gates the endpoint ahead of every other check. Guest, Billing Admin and Auditor do not have it, so for them tools/list comes back empty and a call returns an in-band error naming the permission.
Sign-in can run on your existing identity provider. Elaichi has SAML and OIDC SSO built in-house, plus SCIM v2 for users and groups with group-to-role mapping. A product manager who joins the Product group in your directory arrives with the role that group maps to.
What stops the agent from deleting a Notion page or database?
A restriction does. A restriction says which connectors and which individual tools a target may reach. Targets are role or user only. There is no organization target, and the organization default is the absence of any rule, which means allow-all. A freshly connected Notion account is wide open until you write something down.
A rule on a user replaces the role rules for that user rather than adding to them
Within the winning layer, allow rules union, block rules union, and blocks always beat allows. For a product team the useful shape is a block rule on the Member role covering page deletion and database deletion, with everything else left alone. Blocking beats allowlisting here for a mechanical reason. the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything, so an allow rule naming nothing denies everything.
One detail decides whether the block holds. A rule is written against a connector and a tool, but the canonical operation is pinned against the catalog at write time. A block matches on the tool name or the pinned operation. An allow matches on the pinned operation only. A tool's advertised name is a token whoever edits the connector's documentation controls, which is why governance binds the operation. The full reasoning is in why a block matches the name and an allow matches the operation.
Two more layers sit under the rule. OAuth scopes ladder from mcp:read through mcp:write to mcp:destructive, and a tool classified forbidden is reachable under no scope at all. MCP annotations carry a read-only hint on reads and a destructive hint on deletes, with no annotation on a plain write, because the protocol has no hint for changing something without destroying it. the code that decides allow or deny Enforcement runs at four points: browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL.
Timing is the part people get wrong. A restriction change, like a role change, takes effect within about two minutes. It is not the next call. Only grant revocation, member removal and suspension are effective on the next call, because the grant's revocation state is re-read from the organization store every single time.
Can frozen parameters pin the agent to one database?
For a toolbox entry, yes. Frozen parameters are a per-entry map over the tool's flattened argument space, and they have two effects. Frozen keys are stripped from the advertised schema, so the model never sees them. Frozen values are merged over the caller's arguments at execution, so passing the key anyway cannot un-freeze it.
The precedence is worth memorizing: entry defaults, then caller and model arguments, then frozen parameters last. Freeze the identifier of the parent database on a create-page entry, and the model can file a spec in the specs database and nowhere else. It does not get to argue, because the argument is not in the schema it was handed.
Frozen parameters are a narrowing tool, not a deletion guard. Use a restriction for "never delete" and frozen parameters for "only here".
Which Notion workspace did the agent actually write to?
The audit record answers this, and it answers from the execution rather than from the intent. Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account. The connection recorded is the one actually reached. After an unexpected edit, "which of my two Notion workspaces did the agent write to" is the first question, and guessing from a timestamp is not an answer.
Each record carries the operation and tool, the connection, the classification, whether the call was approved, the outcome, and an error code only. Argument names and counts are logged. Argument values never are. actor_kind is a recorded field rather than an inference, and its values include ai_assistant, so agent activity is written down at the point of action instead of reconstructed later from a user agent string.
Two error strings exist per failed call, and they never cross. The string returned to the caller is derived from the third party's response body. The string written to the audit trail is never derived from the request or the response. Audit records are org-visible, readable by the in-product assistant, and fanned out to whatever SIEM you configure, so a remote error body reaching one would be third-party payload leaving the system through the log pipe.
The trail is append-only, newest-first, cursor-paginated, and filterable by free text, category, actor, action kind and time. It is eventually consistent, so a row can take a moment to appear. Audit lives in one log tenant per organization, enforced in the type system rather than by a WHERE clause. You can forward it to your own destination: Datadog is implemented, while Splunk HEC and Microsoft Sentinel are accepted but not yet delivering.
Two Notion accounts and the 30-tool threshold
Past 30 tools, the connected tools collapse behind two meta-tools, search_tools and execute_tool. The threshold counts catalog operations and connected tools together, and the control-plane catalog alone is dozens of operations, so one connected app is normally enough to trip it. Collapse is the normal case for a product team, not an edge case. Tools withheld by a restriction are excluded from the count.
This is why the account labels matter. Ranking is purely lexical over three fields: tool name, description and connector label. A relevance floor drops results that do not account for at least half the query's own weighted mass, so a search for a Notion tool stops returning a plausible-looking tool from a different app. The words set, connection, frozen and more are dropped from description tokens, because they appear on every merged or frozen tool. Account labels stay scorable on purpose. The derivation is in the relevance floor behind search_tools.
execute_tool is only a naming indirection. It unwraps to the same tool name and arguments and falls through the identical gates, so nothing above changes when discovery collapses.
What happens when the PM who owned the connection leaves?
Removal runs a preflight. A personal connection referenced by a toolbox entry has to be resolved first, transferred to the organization, a team or another member, or deleted, or the removal is refused. Unreferenced personal connections are cleaned up. A private connection is not transferable at all, because a credential only its owner could ever use does not become somebody else's when they leave. Delegated toolbox entries surface as a non-blocking warning, and re-pinning the entry is the fix.
removing or suspending a member revokes every live grant in the same transaction as the membership change, so their access ends on the next call. The same shape, applied to people who never had a full seat, is covered in the contractor offboarding playbook.
The credentials themselves are not in Elaichi. A separate service holds per-account secrets, encrypted at rest with AES-256-GCM, and owns refresh. A failed refresh marks the connection needs_reauth rather than failing quietly, so a stale Notion token shows up as a connection to fix and not as an agent that mysteriously stopped working.
What does this cost for a product team?
Gold is $15 per user per month, or $120 per user per year. There are two plans, Gold and Black, with a 14-day trial. You start with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. Checkout collects a card and sets the paid trial to the remaining days, so it is one continuous trial rather than two.
Billable seats are active memberships, minimum one. Suspended members are excluded, and so are the free-seat roles: Guest, Billing Admin and Auditor. The read-only Auditor seat matters for this rollout, because a compliance reviewer can watch the Notion audit trail without costing a license. If a trial ends without checkout the workspace pauses. Plan-gated features lock, nothing is deleted, and subscribing picks up where it left off. Current numbers are on pricing.
When a product team does not need this yet
If there is one Notion workspace, four people, and the agent only reads, a control plane is overhead. Point the client at whatever the vendor ships. Revisit when a second workspace appears, or when someone asks which account an agent wrote to and nobody can say. That decision is laid out in when an MCP gateway is premature.
One limitation belongs in the same paragraph. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. A Notion page containing hostile instructions is still a live risk on the endpoint. What does hold there: role checks per operation, the forbidden classification, output redaction, OAuth scope limits and full audit logging.
For the same rollout run against a CRM instead of a wiki, see the sales team playbook for ChatGPT and Salesforce. Scope by department sits on use cases, and the catalog is at connectors.
