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.7 KiB
seo_title, seo_description
| seo_title | seo_description |
|---|---|
| Answer a Connector Review | An agent hit an Ask-first action and is waiting. Allow the call once, allow future calls for the same action, or decline, and see what each choice does. |
Answer a connector review request
When an agent calls an action set to Ask first, the call stops and waits for a person. This is where you answer it.
Find the waiting requests
Two places, same queue:
- Connectors → Review, for everything across the company.
- A connector's own Review tab, scoped to that one connection.
Pending items are labelled Waiting for your OK. The connector list flags the connection as Needs attention while something is pending.
The API equivalent is:
GET /api/companies/{companyId}/tools/action-requests?status=pending
What a request shows you
Review the action, connection, and request details shown in the card. The available details depend on the request type. If the preview does not establish what will change, inspect the task and ask the agent to clarify before approving.
The three answers
| Answer | What happens |
|---|---|
| Allow once | Approves this stored call without creating a rule for future calls. A new call still needs approval unless another policy permits it. |
| Always allow | Approves this call and lets the same agent use the same action with different arguments on this connection, within the current project when present. Offered only for eligible requests. |
| Decline | Rejects this request without running its action. The agent must change approach. |
Choose Allow once when you only intend to approve the specific request in front of you. Always allow is broader than remembering an identical set of arguments.
Trust rules
A trust rule is a stored company tool policy created from one approval. It is not invisible: rules are listed under the company's tool policies with the selectors they match, and each one can be revoked.
Revoking a trust rule removes that allowance. Future calls are evaluated against the remaining policies, including Ask first where configured. It does not undo calls that already ran.
Prefer Allow once until you are comfortable authorizing that action with other arguments in the stated scope. A successful read or one harmless write does not establish that every later use is acceptable.
What the agent experiences
An agent calling an Ask-first action does not get an error and does not get a result — it gets told approval is required, and it waits. Paperclip wakes the agent again when you answer.
Approval means approve and run: Paperclip attempts the stored call using its saved arguments. Approval is not proof that the provider operation succeeded; check the execution result. An agent should not re-issue the call after an approval; if the wake says it executed, that result is the result.
A declined request means the action did not happen. The agent is expected to change approach rather than retry the same call.
Pending requests expire. After expiry the item reads Expired — send it again, and the agent has to make a fresh call to open a new request.
If a request seems stuck
- Denied — see Review for why on a test call means the request was declined, not that the connector is broken.
- A request that never appears usually means the call never reached the gateway. Check the action is not Off, and that the agent is in the connection's allowed set.
- A connection in Paused state does not produce review requests, because agents cannot use it at all.