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.3 KiB
seo_title, seo_description
| seo_title | seo_description |
|---|---|
| Stripe Connector | Let agents read Stripe data and, with approval, act on it. Test mode first, restricted keys, why financial actions need review, and troubleshooting. |
Stripe
Agents can work with your Stripe account through Stripe's hosted server — looking up customers, payments, subscriptions, and products, and with approval performing actions against them.
Warning: This connector reaches real financial data, and its writes are real financial operations. Stripe's hosted server is in public preview. Start in test mode, and require approval for anything that moves money.
Do not assume a specific capability from the name. What an agent can do is exactly what Stripe's server exposes to your credential and what you have permitted — refunds, payouts, and payment creation are not automatically available, and are not automatically absent either. Read the connection's action list rather than guessing in either direction.
Before you connect
- A Stripe account. Use a test mode account or test keys for the first connection.
- If using a key, create a restricted key with only the permissions agents need, rather than a full secret key.
Restricted keys are the main control on this connector. Stripe lets you grant read-only access to specific resource types, which is far more precise than anything Paperclip can apply afterwards.
Warning: Paperclip's key field shows the placeholder
sk_..., which is a standard secret key carrying your account's full API access. A restricted key — its id beginsrk_— works in the same field and is what you should use. Do not read the placeholder as a recommendation.
Note: Whether a key is a test-mode or live-mode key is decided in Stripe when you create it, and it determines whether an agent is touching real money. Nothing in Paperclip displays or changes that, so label your connections clearly and check the key's mode in Stripe before connecting anything to production.
Connect Stripe
- Open Connectors and select Stripe.
- On the Access step, choose the identity and which agents may use the connection.
- Choose how to authenticate:
- Sign in with Stripe — browser sign-in.
- Use an API key — paste a Stripe key, created under API keys in the Stripe dashboard.
- Finish setup.
Danger: A Stripe secret key grants full account access, including moving money. Paste only a restricted key unless you have a specific reason not to, and never a live secret key into an untested setup.
Choose access
Two layers, and the Stripe-side one is stronger:
| Layer | Controlled in | Precision |
|---|---|---|
| Which API operations the credential can perform | Stripe, on the restricted key | Per resource, read or write |
| Whether an agent may call an exposed action | Paperclip, on the Permissions tab | Per action, with approval |
Use the restricted key to remove capability, and Paperclip's settings to require review on what remains.
Test mode versus live mode is decided entirely by which credential you connect. A test-mode key reaches test data only. There is no toggle in Paperclip that switches a live connection into test mode, so if you want both, make two connections and name them clearly.
Warning: Stripe's own guidance is that financial and destructive actions require explicit approval before execution. Keep every write on Ask first or Off. An Allowed write here means an agent can change financial records without a person seeing it first.
Try it
Use a read against test data:
Look up the most recent Stripe customer and tell me their email and when they were created. Do not create, refund, or change anything.
Compare against the Stripe dashboard in the same mode. Never verify this connector with a payment, a refund, or a payout — those are real operations even when they are small.
Note: Illustrative task, not a recorded test result. Run it against a test-mode connection first.
Troubleshooting and limitations
| Problem | Likely cause | Fix |
|---|---|---|
| An agent sees no data | The credential is test mode and you are comparing against live, or the reverse | Check which mode the connected credential belongs to |
| An action is refused by Stripe | The restricted key does not include that permission | Widen the key deliberately in Stripe, or leave the capability off |
| An action is missing from the list | Stripe's server does not expose it to this credential | Use Refresh actions; otherwise it is not available |
| A financial action ran without review | It was set to Allowed | Set writes to Ask first or Off |
| Behaviour changes without a Paperclip change | The hosted server is in public preview and evolving | Re-read the action list after provider changes |
| Needs attention | The key was rolled or the sign-in expired | Select Reconnect |
Limitations: one Stripe account and one mode per connection. Paperclip cannot reverse a financial operation. Public preview means the surface can change.
Related guides
- Shopify — storefront commerce, with different boundaries.
- Set action permissions
- Answer a connector review request
- Stripe MCP documentation