How Pear Handles Your Data

Your full chat transcript never reaches Pear

Pear is an MCP (Model Context Protocol) server. Your conversation stays entirely inside your AI client (Claude, ChatGPT, Poke, Cursor, etc.). The client only sends Pear the structured tool call and arguments it decides to execute — for example create_event {title: "Team Standup"}. Pear does not receive your full chat history, system prompts, or the full conversation context. If you include personal details in a tool call argument, that specific argument is sent to Pear so the tool can run.

Credentials & encryption

We never store or see your main Apple ID, Microsoft, or Google password. For Apple iCloud, Pear requires an App-Specific Password that you generate from appleid.apple.com and can revoke at any time. Microsoft 365 uses OAuth tokens granted after you approve the connection. Compatible IMAP/SMTP mailboxes use the mailbox credential and safe server settings you choose to add. If Google provider access is enabled, Google also uses OAuth tokens and granted scopes rather than your Google password.

• Provider credentials and OAuth refresh tokens are encrypted at rest with AES-256-GCM using a server-side key
• They are only decrypted in memory for the duration of a single request
• Revoking the provider credential or OAuth grant cuts off provider access

Google access Pear requests

If you connect Google, Pear requests identity access through openid, email, and profile so it can identify the connected Google account. Pear also requests these Google Workspace scopes:

• https://www.googleapis.com/auth/calendar.calendarlist.readonly to list your calendars and select the calendar you requested
• https://www.googleapis.com/auth/calendar.events to read, create, update, and delete events
• https://www.googleapis.com/auth/calendar.freebusy to check availability and avoid scheduling conflicts
• https://www.googleapis.com/auth/tasks to read and manage Google Tasks
• https://www.googleapis.com/auth/contacts to search, read, create, update, and delete Google Contacts
• https://www.googleapis.com/auth/gmail.modify to search and read selected messages, manage labels and message state, archive or trash messages, and send an email you request

Pear does not request the broader Google Calendar scope, a separate Gmail send scope, or unrestricted Gmail access. Gmail sending is included in https://www.googleapis.com/auth/gmail.modify.

Provider reads are live, not a synced database

When your AI calls a tool like “list my events tomorrow”, Pear fetches data from the connected provider in real time. For Apple, Pear uses CalDAV (Calendar & Reminders), CardDAV (Contacts), and IMAP/SMTP (Mail). For Microsoft 365, Pear uses Microsoft Graph for Calendar, Microsoft To Do, Contacts, and Outlook Mail. Compatible mailboxes use the IMAP/SMTP servers you configure. If Google provider access is enabled, Pear uses Google Calendar, Google Tasks, Google Contacts, and Gmail APIs for the scopes you approved. For read requests, the response is processed in memory, returned to your selected AI or MCP client, and discarded after the request.

• Pear does not maintain a synced database copy of your calendars, tasks, reminders, contacts, or emails
• Full provider records are fetched live from Apple, Microsoft, your configured mailbox, or Google when enabled, and returned to your AI client
• Pear stores provider server endpoint URLs and connection metadata needed to run the service, but not full provider records as a synced content database
• Pear retains operational metadata such as usage counts, pseudonymous tool analytics, and Pro activity history, plus the approved-write records described next

Approved writes can store the exact action you approved

Pear has an approval workflow for actions that change provider data. When that workflow is used and the record is persisted, Pear keeps an approval ledger so the proposed, approved, and executed action can be compared and audited. This is different from an ordinary read request and is the main exception to live-only provider-data processing.

• Action details: the exact draft and approved payload, provider, account, tool, action, timestamps, and request identifiers
• Approval evidence: approval or rejection details, source references, risk/redaction classifications, and state changes
• Outcome: execution status, normalized failure details, provider receipt or result, and undo-plan metadata where available
• Content that may be included: email recipients, subject and body; event title, description and attendees; task details; or contact fields, depending on the exact write you approved
• Never included: provider passwords or OAuth tokens

Usage analytics and activity history

Pear records a small amount of metadata per tool call for billing, abuse prevention, product analytics, and the Pro activity page:

• Billing and limits: monthly metered action counts per user
• Analytics: tool name (e.g. list_events), response time, success/failure, error type, and timestamp
• User identity: analytics use pseudonymous, stable keyed HMAC-SHA256 identifiers rather than plain user and session IDs. Those identifiers remain linkable for authorized product and activity analysis
• Pro dashboard activity: tool name, status, response time, and timestamp. The dashboard may show only part of this metadata, but Pear still stores the operational fields needed for reliability and analytics
• Security attribution: HMAC-SHA256 hashes of the trusted request IP, coarse IP prefix, and user-agent, plus limited request metadata such as host, origin, referer origin, and country when provided by the trusted edge
• Not retained as ordinary analytics: full chat transcripts, full request payloads, raw IP addresses, full user-agent strings, or full provider response bodies. The approved-write ledger described above is separate from analytics and may contain the exact payload for an action you approved

Public marketing pages send bounded pageview metadata, approved UTM campaign fields, and the referrer origin to the configured analytics endpoint. Arbitrary query parameters and the full referrer URL are not sent.

Third parties

Pear does not sell your data. We share data only with:

• Apple iCloud — your credentials are sent to Apple's CalDAV, CardDAV, IMAP, and SMTP servers to fulfil requests
• Microsoft — OAuth tokens are sent to Microsoft Graph when you connect Microsoft 365 provider workflows
• Compatible mailbox providers — mailbox credentials and message requests are sent to the IMAP/SMTP servers you configure
• Google APIs — when Google provider access is enabled, OAuth tokens are sent to Google APIs to fulfil Google Calendar, Tasks, Contacts, and Gmail requests you initiate
• Your connected AI or MCP client — provider data and tool results needed for your request are returned to the client you chose
• Stripe — for payment processing (we never see card numbers)
• Supabase — database hosting and authentication
• Resend — transactional email delivery for product emails such as receipts and onboarding messages
• Hetzner/Coolify — production application hosting
• Vercel — preview-only deployments

Pear does not sell provider data or use Google Workspace API data for advertising. Pear does not use or transfer Google Workspace API data to develop, improve, or train generalized AI or machine learning models. Google data is sent to your selected AI or MCP client solely to provide the specific tool result you requested. The client you choose is an independent service with its own terms and privacy practices.

Pear's use and transfer of information received from Google Workspace APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Some providers may process data outside Australia. Pear limits those disclosures to the information needed to run the service.

You're always in control

• Revoke access: delete the App-Specific Password from appleid.apple.com at any time
• Revoke Google access: remove Pear from your Google Account third-party app access settings at any time
• Regenerate API key: rotate your Pear API key instantly from Settings
• Disconnect a provider: removes the active encrypted credential or token values, revokes access where supported, and marks the connection as disconnected. It does not delete existing activity or approval-ledger records
• Export activity: Pro users can export a safe metadata view from the Activity page. It excludes raw write payloads, provider content, provider responses, and OAuth tokens
• Request export or deletion: email support@pearmcp.com for a verified account-data request. Limited legal, tax, billing, security, incident, or dispute records may remain where required

Pear has proposed a 366-day retention window for MCP audit and approval-ledger records, but it is not yet an approved or deployed automatic deletion guarantee. Records may be kept longer until a production retention schedule is approved and deployed.