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]>
7.2 KiB
seo_title, seo_description
| seo_title | seo_description |
|---|---|
| AgentMail Connector | Give a Paperclip agent its own email inbox with AgentMail. Each conversation becomes a task. Setup, routing, sender limits, and troubleshooting. |
AgentMail
AgentMail gives an agent its own email address. Mail that arrives becomes a Paperclip task, the agent works the task, and its replies go back out on the same thread.
This is a conversation channel, not a set of tools an agent calls against your own mail. It does not read an existing mailbox — the inbox belongs to the agent. For reading your own Gmail, see Gmail.
Warning: Anyone who knows the address can email an unrestricted inbox, and an incoming message can create a task and start agent work. Two separate controls govern this — AgentMail's own allowlists, and Paperclip's Allow unlinked people setting. Set both before publishing the address anywhere; see Two sender controls, on two different sides.
Before you connect
- Chat connectors must be switched on for the instance. It is an experimental setting and it is off by default; an instance administrator enables it under experimental settings. Without it, email and chat setup is hidden.
- An AgentMail account and an API key from the AgentMail console.
- The agent that will own the inbox. One inbox belongs to one agent.
- To use your own domain, verify it in AgentMail first. Inboxes on
agentmail.toneed no verification.
Connect AgentMail
- Open Connectors and select AgentMail.
- On the Access step, choose the identity and which agents may use the connection, then select Save and continue.
- Paste your AgentMail API key. Paperclip stores it as a secret.
- Create a new inbox or select an existing one. If you create one, choose the address and, for a custom domain, pick a domain you have already verified.
- Choose how Paperclip receives mail:
- Live connection — Paperclip holds an outbound connection to AgentMail and reconnects on its own. No public URL is needed. This is the simpler choice and works behind a firewall.
- Webhook — AgentMail posts to Paperclip. Your API key must have webhook create, read, and delete permission for the inbox, or setup fails with a message telling you to fix the key or use Live connection.
- Assign the inbox to its agent and finish.
Note: If the owning agent runs at low trust, it needs an active sandbox environment before its inbox can be connected.
How email becomes work
| Stage | What happens |
|---|---|
| A message arrives | Paperclip creates a task for the owning agent, with the message as the opening context |
| The agent works | Ordinary task work. Internal comments and the agent's final response stay in Paperclip and never send email |
| The agent replies | Only an explicit send or reply leaves Paperclip. A reply continues the existing thread; a new message starts a separate child task |
| Delivery | The agent can check delivery status for something it sent |
Two consequences worth knowing. Sending does not close the task, so an agent can send and keep working. And because internal discussion never leaves Paperclip, you can review a thread without risk of the draft reaching the sender.
Choose access
An agent may only use inboxes assigned to it. A request against a thread on an inbox the agent does not own is refused, so one agent cannot read another agent's mail through this connector.
The connection's own settings — the identity that owns the credential, and Any agent or Just agents I pick — work as they do for any connector. How connector access works has the detail. Note that inbox assignment, not the agent list, is what decides whose mail an agent can read.
Two sender controls, on two different sides
Restricting who can reach the agent by email uses both of these, and they do different jobs:
| Control | Where | What it does |
|---|---|---|
| Allowlists and blocklists | AgentMail | Decides which senders' mail reaches the inbox at all. AgentMail keeps separate lists for new messages and for replies — check both, or a restriction will leak through one of them |
| Allow unlinked people | Paperclip, on the connection's Access tab under External identity access | Decides what happens to mail that did arrive from a sender Paperclip does not recognize. Off means only senders linked to a Paperclip person can start work; on means they run as restricted guests, in an isolated workspace and sandbox, unable to approve, hire, spend, or manage access |
Paperclip does not verify or read AgentMail's lists, so the first row is genuinely the provider's to get right. But the second row is yours, and it is the reason "anyone who knows the address can email it" does not have to mean "anyone can direct an agent." Set both before you publish the address.
AgentMail's own reference is allowlists and blocklists.
Try it
Verify without sending anything outbound:
- Open the connection and confirm the inbox is listed and the connection is healthy.
- From an address you control and have allowlisted, send one short message to the inbox.
- Expect a new task for the owning agent within a few moments, with your message as the opening context.
That confirms the whole receiving path — credential, inbox assignment, and routing — without Paperclip sending mail. Only extend to a reply when you intend real mail to go out, and to an address you control.
Note: Procedure, not a recorded test result. It sends one message from your own account to your own inbox; nothing is delivered to a third party.
Troubleshooting and limitations
| Problem | Likely cause | Fix |
|---|---|---|
| AgentMail does not appear in Connectors | Chat connectors is off for the instance | Ask an administrator to enable it in experimental settings |
| Setup fails asking about webhook permissions | The API key cannot manage webhooks for this inbox | Grant webhook create, read, and delete permission in AgentMail, or choose Live connection |
| Mail arrives in AgentMail but no task appears | Receiving is not established, or the inbox is not assigned to an agent | Check the connection's health and that the inbox has an owning agent |
| A custom-domain inbox cannot be created | The domain is not verified in AgentMail | Verify the domain in AgentMail, then retry |
| The agent cannot read a thread you can see | The thread is on an inbox that is not assigned to that agent | Assign the inbox to that agent, or give the work to the agent that owns it |
| The inbox was disconnected and will not come back | A disconnected inbox is not reusable | Create a new inbox connection |
Limitations: one inbox, one owning agent. Paperclip does not enforce who may write to the inbox. Attachments and thread history come from AgentMail, so what an agent can see is what AgentMail retains.
Related guides
- How connector access works
- Verify a connector and fix a broken one
- Gmail — read your own mailbox instead of giving an agent its own.
- AgentMail inbox documentation