39633c2217
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]>
5.2 KiB
seo_title: Connections v3 Foundation seo_description: The rebuilt connection storage and authorization layer under Paperclip Connectors: stable identities, subject-aware grants, and the mcp_remote rename.
Connections v3 (the foundation under Connectors)
Connections v3 is the layer that stores, authorizes, and hands out connections to outside services. It is what Connectors is built on.
Note: This page is no longer about an experimental flag. When it was first written, the connection surface shipped behind an Apps toggle in experimental settings and the catalog was a small Wave 1 cut. Neither is true now. The surface is always on, the toggle is gone, and the catalog is the full list on Connectors. What remains here is the underlying model and the one operator-facing rename — the parts that are still worth looking up.
What changed since this page was first published
| Then | Now |
|---|---|
| Apps had to be turned on in Settings → Instance settings → Experimental. | Always enabled. enableApps is a deprecated compatibility key: "Apps is always enabled; stored and managed values are ignored." The Experimental settings page no longer renders the toggle. |
| The navigation item was Apps. | The sidebar item is Connectors. The route is still /apps. |
| A Wave 1 catalog, described as plumbing rather than a store. | A full catalog with setup flows, per-action permissions, and a review queue. See Connectors. |
| "Setup flows are partial." | Setup flows are the product surface. Each provider page documents the exact paths Paperclip supports for it. |
One experimental flag in this area is still real and still off by default: Chat connectors, described as "Show experimental chat connector setup and Board surfaces. Existing connections keep running when hidden; GitHub and other tool connectors are unaffected." That flag governs the chat channels — Slack, Discord, Microsoft Teams, Telegram, iMessage — and AgentMail's email inboxes with them. It does not govern app integrations, so the Slack and GitHub agent tools are unaffected even when their chat halves are hidden.
The model
Connecting an external service used to mean a loose bundle of config and secrets with no clear owner and no stable name. Connections v3 replaced that with an explicit model, and that model is still how connectors work today:
- A stable connection identity. Every connection has a company-scoped
uid(likegoogle-sheets/finance-sheet-1a2b3c4d) that stays put as names change, so the rest of Paperclip can reference it reliably. Renaming a connection does not break a policy pointed at it. - Explicit ownership, auth, and transport. Each connection records who owns it, how it authenticates (
oauth,api_key, ornone), and how it talks to the service. - Subject-aware grants. A
connection_grantstable separates the connection from who may use it. A grant is scoped to the organization, to one user, or to one agent, so a single connection can serve a shared default and per-subject authorizations at the same time. This is what the identity choices in How connector access works are built on. - Multi-key credentials. A connection can hold more than one credential reference, which real-world apps with several keys or scopes need.
A generated AppDefinition catalog gives browse-and-connect a single typed contract: each entry declares its methods, transports, ownership modes, required fields, and risk tier. Grant management routes fail closed for scopes they do not recognize — an unknown scope is refused rather than quietly allowed.
Operator note: the remote_http rename
Connections v3 renamed the legacy remote_http transport to mcp_remote. This is what remote MCP server connections use.
Nothing to do on upgrade. The change shipped as two additive migrations that run automatically on startup:
0182_connections_v3_schema_core— backfills connectionuids, adds the ownership and auth fields, creates theconnection_grantstable, seeds a default organization grant for every existing connection, and rewrites anytransportofremote_httptomcp_remote.0183_connection_user_authorization_state— adds the subject-aware authorization state used by per-user grants.
The only thing to carry forward: if you have tooling, scripts, or notes that name the remote_http transport, update them to mcp_remote. The transports in use are mcp_remote, rest_api, local_stdio, chat_sdk, and runtime_auth.
Where to go next
- Connectors — the catalog, the shared guides, and the per-provider pages.
- How connector access works — grants, agent access, and per-action permission.
- Tool Gateway — where the effective policy is enforced at call time.
- Experimental features overview — how experimental flags work and what "no compatibility guarantees" means.
- Cloud Sync — retired, removed upstream along with its toggle. To move a company between instances, use company Import/Export instead.