Connector catalog, setup guides, and shared access documentation, followed by a final code-accuracy repair pass. This PR does not change application behavior. ## Final accuracy pass Checked against shipped Paperclip `v2026.916.0`, commit `dffc2b3ca1b9e88fa21cb17493083e682dffd1ca`, rather than the dirty local checkout or the earlier canary baseline. - Corrects connector/method-specific identity choices, human audiences, and managed GitHub versus PAT scope and verification. - Explains that **Always allow** covers different arguments for the same agent/action/connection, with project scope when present; uses actual button labels and removes the test-panel control from review instructions. - Qualifies new-action quarantine, including safe-default read exceptions. Removes unconditional approval guarantees. - Separates provider channel/repository reach from Paperclip sender authorization. - Completes sandbox sign-in and model credential-selection instructions from the current UI implementation. - Repairs Notion's hub summary, removes incomplete optional Notion/Sentry client-registration procedures, and corrects Linear's provider-versus-Paperclip attribution. - Removes unsupported Postman tier claims, contradictory Cloudinary/Mem0 verification assertions, API-equivalence claims, and overbroad successful-test assurances. - Retains Supabase's required project reference: both released method definitions explicitly require it. An earlier review suggested otherwise; release code is authoritative here. - Updates the release baseline and removes draft commit chronology from the public introduction. ## Availability and remaining runtime gates - **Google:** Verification is pending. Per the product-owner clarification, authorization can continue where Google offers an Advanced option; this is not available for every account and does not override Workspace policy or other Google prerequisites. Notices on the hub and all Google guides now distinguish an unverified-app warning from blocked authorization. - **Slack is available but not yet fully functional; follow-up fixes are planned.** For agent tools, the released OAuth endpoint/scope defaults differ from Slack's documented MCP contract. The page now warns against treating that route as production-ready and removes the misleading bot-scope walkthrough. Chat-channel bot setup remains separate. Engineering must reconcile the integration and run OAuth plus one read before removing this warning. Source: https://docs.slack.dev/ai/slack-mcp-server/ - No credentialed connector run was performed in this pass. Code consistency, provider documentation, UI rendering, and successful live execution are separate evidence levels. No claim of runtime certification for all connectors. ## Validation - Root build: 253 crawlable documentation pages. - Full `docs:test`: all eight suites passed locally, including root/subpath routes, sitemap history, fingerprints, navigation, skill source blocks, crawlable links, doc-link resolution, and SEO metadata. - Internal-link lint: 258 Markdown files; no broken internal links. - Latest cleanup: full build, all eight docs:test suites, internal-link lint and diff whitespace checks passed; 1,878 link-resolution checks. - Fixed the Calendar MCP reference URL; browser-checked the five inconclusive external destinations (Miro article loads; Asana, Google Cloud, OpenAI and xAI reach sign-in/console screens). Authenticated destinations were not tested beyond those screens. - Replaced the Sandbox providers editorial TODO with a scope note and removed the CLI overview's unfinished-guide announcement. - Browser client navigation: 687 checks passed using installed Chrome. Initial launch lacked the downloaded Playwright browser; rerun used `DOCS_CHROMIUM_PATH` without changing the tests. - Nine representative connector/shared pages at 1440px and 390px: HTTP 200, one article H1, no page-level horizontal overflow. Mobile screenshot inspected; approval page opened in the Codex browser. - Navigation audit reports three existing non-connector orphan files; this patch does not alter those files or their navigation. The previous revision's provider-page expansion, Google shared setup guide, navigation additions, and accidental node_modules-symlink cleanup remain in this PR. Internal review ledgers remain outside the publication branch. No merge or production deployment authorized. --------- Co-authored-by: DevRel Gemini <[email protected]> Co-authored-by: Paperclip <[email protected]> Co-authored-by: Claude Opus 5 (1M context) <[email protected]> Co-authored-by: Michael Nguyen <[email protected]>
6.7 KiB
seo_title, seo_description
| seo_title | seo_description |
|---|---|
| Notion Connector | Connect Notion so agents can search, read, and update workspace content. Setup, what the connection can reach, a read-only test, and fixes. |
Notion
Notion's hosted connection lets agents search your workspace, read pages and databases, and — when you allow it — create and update them.
The reach of this connection is the Notion account you sign in with. Notion's hosted connection inherits that account's permissions: an agent can reach whatever that person can already open, and nothing they cannot. Notion states this directly — "a connected client can use Notion MCP to access content that you can access." There is no step where you pick individual pages to share, and Paperclip does not narrow the set afterwards. Choose the connecting account accordingly.
Before you connect
- Decide which Notion account to connect. This is the real access decision, and it happens before you open the consent screen. If agents should not reach everything you can reach, connect a Notion account whose own workspace permissions are already limited to the right content, rather than your own broad account.
- Permission to add a connection to the workspace. Some Notion plans let a workspace owner restrict which connections members may approve; if yours does, ask an owner to approve the Paperclip connection first.
- If you want narrower reach than any existing account provides, create the restricted Notion account and give it access to the intended pages before connecting. Doing it afterwards means reconnecting under a different identity.
Connect Notion
- Open Connectors and select Notion.
- On the Access step, choose the identity that owns the credential and which agents may use the connection. Select Continue to Notion.
- Sign in as the Notion account you chose above, and pick the workspace you want to connect. Everything that account can open in that workspace becomes reachable.
- Approve the authorization. Notion returns you to Paperclip and the connection becomes Ready.
Paperclip registers its client with Notion automatically, so there is nothing to set up in a developer console.
Note: If your instance routes credentials through Vercel Connect, Notion can also be connected that way; the access and sharing decisions are the same.
Choose access
Three separate decisions govern a Notion call. How connector access works explains all three in one place; the Notion-specific parts are:
| Decision | What it means for Notion |
|---|---|
| Identity | Just me uses your Notion account on your own runs. An organization-shared credential makes one Notion account available to eligible agents on runs whose responsible person is in its human audience, and needs the connection-manager permission. |
| Reachable content | Everything the connected Notion account can open. To narrow it, change that account's permissions in Notion, or reconnect under an account with less access. Paperclip has no page-level filter for Notion. |
| Actions | Notion's server supplies the action list. Reads and writes are classified separately, so you can leave reads Allowed and put writes on Ask first. |
Representative operations at the current reviewed catalog: search, fetch a page, query a database, and read comments on the read side; create and update pages, create comments, create databases, and move or duplicate pages on the write side. Open the connection's Permissions tab for the live list, and Refresh actions to re-read it.
Note: Moving, duplicating, and converting pages are writes even though their names do not start with a create or update verb. Paperclip classifies them explicitly so they are not mistaken for reads.
Try it
Give an agent that holds the connection a read-only task. Pick a page the connected Notion account can open, and one fact on it you already know, so you can tell a real read from a plausible guess:
Find the "Engineering onboarding" page in Notion, then tell me the title of its
first section heading. Do not make any changes.
Expect the heading you already know. Then open the task's activity and confirm the Notion calls are listed there with the action used and the connection they ran against — the answer alone does not prove the agent read the page rather than inferred it.
A read is the right first check because it leaves nothing behind. If you want to confirm writes as well, do it on a scratch page you created for the purpose.
Note: This is an illustrative task, not a recorded test result. Adjust the page name to something in your own workspace.
Troubleshooting and limitations
| Problem | Likely cause | Fix |
|---|---|---|
| Search returns nothing, or a page you expected is missing | Most often the connected Notion account cannot open that page; it may also live in a different workspace | Sign in to Notion as the connected account and try to open the page yourself. If you cannot, share it with that account in Notion. Reconnecting does not add reach |
| An agent can reach more than you intended | The connected account has broad workspace access, which the connection inherits | Reduce that account's permissions in Notion, or reconnect using an account with narrower access |
| Authorization does not complete | A workspace owner restricts which connections members may approve | Ask an owner to approve the connection, then retry |
| A write action is missing from the list | The action list is the provider's, and Notion changes it | Use Refresh actions, then check the action's switch — see Set action permissions for when a newly discovered action starts off |
| Calls stop working after a while | The Notion grant was revoked, in Notion or in Paperclip | The connection shows Needs attention; select Reconnect |
Limitations worth knowing: this connector is Notion's hosted content connection, not the whole Notion API. Workspace administration, user management, and billing are not exposed. A connection reaches one workspace; connect Notion again for a second workspace.
Workspace owners can review and revoke connected clients in Notion under Settings → Connections, independently of anything set in Paperclip.
Related guides
- How connector access works
- Set action permissions
- Verify a connector and fix a broken one
- Notion's MCP overview — the provider's description of the hosted connection and what it can reach.
- Notion's MCP security guidance — how Notion describes the access a connected client inherits.