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]>
4.9 KiB
seo_title, seo_description
| seo_title | seo_description |
|---|---|
| Linear Connector | Let agents read, create, and update Linear issues. Registering the OAuth app, what workspace scope really means, a read test, and troubleshooting. |
Linear
Agents can read Linear issues, create new ones, and update existing ones — useful for keeping engineering work in Linear while agents do the work in Paperclip.
Before you connect
- A Linear account with access to the workspace and teams you want agents to use.
- You must register your own Linear OAuth app. This Paperclip connection method asks for registered client credentials. This is a constraint of the documented Paperclip route, not a claim that Linear lacks dynamic client registration. Add Paperclip's redirect URI to the app; Paperclip shows the exact URI during setup.
Connect Linear
Paperclip supplies the redirect URI and Linear supplies the credentials, so start in Paperclip.
1. Read Paperclip's redirect URI
Open Connectors → Linear, choose the identity and agents on the Access step, and copy the redirect URI Paperclip displays. Leave the screen open.
2. Create the Linear OAuth application
At Linear's new OAuth application form:
- Give the application a name.
- Add the redirect URI from step 1 under the redirect callback URLs.
- Create it, then copy the client ID and client secret.
Two things worth knowing before you do this:
- Every admin in the workspace can see and manage the application. Linear's own recommendation is to create a dedicated workspace for managing OAuth applications rather than putting it in your main one.
- Scopes are chosen at authorization, not on the application. Linear's set is
read(always present),write,issues:create,comments:create,timeSchedule:write, andadmin. Grant the narrowest set that covers the work —adminin particular is full access to admin-level endpoints and is not needed for issue work.
3. Finish in Paperclip
Supply the client ID and secret, then authorize in Linear as the account whose access the connection should have.
Choose access
Reach is whatever the authorizing Linear account has. That usually means every team and project that person can see, because Linear workspaces are commonly open internally.
Note: There is no team or project picker in Paperclip. Fields describing workspace, team, and project scope exist in the connector's definition, but they do not narrow what an agent can reach — the limit is the authorizing account's own access in Linear. If an agent should only touch one team's issues, authorize with an account restricted to that team, or rely on action settings and clear instructions rather than assuming a resource filter.
Issue creation and updates are writes. Leave them on Ask first while you are learning how an agent behaves — an agent that files issues enthusiastically is noisy for the whole team. Reads can stay Allowed. See Set action permissions.
Identity matters here for attribution: issues an agent creates or comments on appear under the authorizing account. A dedicated account makes agent activity distinguishable from a person's. See Use separate accounts for people and agents.
Try it
Find Linear issue ENG-142 and tell me its status, assignee, and latest comment. Do not change it.
Compare against the issue in Linear. A read of a known issue confirms the credential and the agent's permission without adding anything to your team's board.
Note: Illustrative task, not a recorded test result. Substitute an issue key from your own workspace.
Troubleshooting and limitations
| Problem | Likely cause | Fix |
|---|---|---|
| Setup asks for a client ID and secret | Expected for this Paperclip connection method | Register the app in Linear's settings |
| Authorization fails with a redirect error | The redirect URI on the Linear app does not match the one Paperclip shows | Copy the URI exactly and retry |
| An issue cannot be found | The authorizing account cannot see that team or project | Grant access in Linear; no reconnect needed |
| The agent reaches more teams than expected | Reach follows the authorizing account, not a Paperclip filter | Authorize with a more limited account |
| Agent-created issues look like they came from a person | The connection uses a personal identity | Use a dedicated agent account |
| Needs attention | The grant was revoked in Linear | Select Reconnect |
Limitations: one workspace per connection. No team or project restriction inside Paperclip. Linear's own rate limits apply.
Related guides
- Jira, Asana, Todoist — other work tracking connectors.
- Use separate accounts for people and agents
- Set action permissions
- Linear API documentation