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]>
3.3 KiB
seo_title, seo_description
| seo_title | seo_description |
|---|---|
| Share a Connector | Choose which people a connector credential covers and which agents may use it, and understand why the two lists are governed separately in Paperclip. |
Share a connector with people and agents
For credentialed app-tool connections, there are two separate audiences: the people the credential belongs to, and the agents allowed to call through it. Widening one does not widen the other.
Choose the human audience
Open the connector and find its identity card.
For a personal connection (Just me), there is nothing to choose. The credential is yours, and "Only you can use this connection."
For an organization identity, select Who can use this identity:
| Choice | Effect |
|---|---|
| Any human in the company | "Anyone in your company can use this connection." |
| Humans I pick | "Only selected people in your company." Select Choose people and name them. |
Save. The change applies to the next run; there is no reconnect.
Creating or changing an organization identity requires the connection-manager permission. Without it Paperclip refuses the change server-side rather than hiding the control and hoping.
For a dedicated agent identity, the human audience is not a list — the identity belongs to one agent. The card reads "Dedicated to one agent" and links to that agent. See Use separate accounts for people and agents.
Choose which agents may use it
For an app-tool connection, open the Permissions tab and find Which agents can use this connection. Model credentials and chat channels use their own assignment controls; see their provider guides.
| Choice | Effect |
|---|---|
| Any agent | "Available across your company." |
| Just agents I pick | "Available only to selected agents." Select Choose agents and name them. |
If the control is disabled with "Unavailable while this connection is installed for every agent," the connection has a company-wide install that supersedes the per-agent list. Change the install first.
Check the selected audience during setup; availability and defaults depend on the method, your permissions, and whether setup was opened for a particular agent. That is not a permission to act — the action list still decides what any of those agents may actually call. See Set action permissions.
Why these are two lists
The human audience decides whose credential is spent and whose consent backs the call. Agent access decides which parts of your org chart can reach the service at all.
They come apart constantly in practice. A finance connector might be shared with the whole company as an identity but restricted to a single bookkeeping agent. A personal Gmail connection is one person's mailbox, but you may still want three of your agents able to search it on your behalf.
Check what you changed
The connector list shows the current state per connection. For a connection whose identity is mixed across installations, the card reads "Mixed access; scope varies by installation" rather than flattening it into a single claim.