Skip to content
Client guide

Booster K1 and T1 email assistant development guide

Build a custom Booster robot app around Pear email and calendar tools. Covers Agent framework prerequisites, private access and software-to-hardware checks.
Custom development

Connection details

Connection values for the custom application you build.

Pear hosted endpoint
https://pearmcp.com/api/mcp

What you would be building

A custom Booster Agent could offer a private "Check my inbox" or "Next meeting" action. Its application logic would call an authenticated Pear MCP client and display or speak the answer. Pear does not ship a Booster Agent, and this workflow has not been tested on a physical K1 or T1.

Booster's documentation describes Python SDK access to K1/T1, a separate Agent development framework and speech capabilities. Confirm those interfaces for your exact model and installed firmware. This guide does not extend that evidence to every Booster model.

1. Start with the official Agent template

Use Booster Studio and its official Agent quick start. Booster describes Agents as packages running on the robot, with an interface generated in the app or Studio. The Agent framework documentation lists firmware 1.7.0 or later for execution on a physical robot. Verify the current requirements before installing.

Create a button callback that returns a fixed sample calendar summary first. This checks the application interface without connecting a real mailbox. The Booster term Agent describes an application package; it does not automatically provide an LLM or an MCP client.

Booster Agent quick start

2. Add a private Pear client to the application

Connect your iCloud or Microsoft 365 account in Pear. Add the Pear endpoint to a compatible authenticated MCP client in your application service, with the key held in its private process environment. Call pear_provider_status and inspect the available tool schemas before building a mailbox request.

A button-driven app can call MCP without a voice platform. If you want open-ended conversation, the LiveKit Python guide supplies the MCP configuration for the conversation layer. Your Booster callback and audio adapter are still application code you must implement.

LiveKit Python MCP configuration

Do not place a personal Pear key in a distributable Agent package, a public repository, a UI parameter shown to other operators or a shared template. Bind each application session to its owner. A robot shared by a lab must not silently reuse one person's mailbox for everyone.

3. Add speech after the button works

Booster documents Speech under boosteros.brain. Check the speech API and device behavior for your installed SDK. Start with fixed test text and verify playback, then pass a short answer from the read-only mailbox workflow. Input transcription and output speech need explicit implementation; an SDK section labelled Speech is not proof of a complete conversation loop.

Booster vision and speech reference

Use a bounded background task for mailbox requests and report timeout or authentication failures in the application. Keep network requests separate from motion callbacks. Allow the owner to cancel before private content is spoken.

4. Check the result and account boundaries

Test a known email, an empty result, a revoked key and a provider failure. Check that a second operator cannot use the first owner's mailbox session. Limit the prototype to selected read tools; leave sending, deletion and movement tools out of the conversation agent.

Do not distribute the app as a verified Pear integration until you have exercised authentication, reads, failure handling and revocation on the actual robot and recorded its model, SDK and firmware versions.

Humanoid robot compatibility and requirements

Choose a useful first workflow

Start with a read. Ask which calendars are connected, find an event in a specific date range, or search a mail folder for a message you already know. Specify the account and timezone when they matter.

For Apple accounts, see iCloud setup and services and iCloud Mail workflows. For Microsoft accounts, see Microsoft 365 setup, Outlook Mail, and Microsoft To Do.

Apple Reminders availability depends on the Apple account. For Apple, Pear can read and write only the legacy reminder lists Apple still exposes through CalDAV. If the account has been upgraded to Apple's newer Reminders store, Pear cannot access those native lists and does not copy them into a separate reminder store. Apple may instead return compatibility placeholders, such as repeated "Where are my reminders?" items; Pear did not create them. Pear's safe fallback hides known placeholders and blocks writes to affected lists. Reconnecting iCloud or replacing the App-Specific Password will not change this Apple limitation. Calendar, Contacts, and Mail are unaffected, and Microsoft To Do uses Microsoft Graph and is unaffected. Full modern Apple Reminders access would require an Apple-platform companion using EventKit with the user's permission; Pear does not currently provide one. Google Workspace remains coming soon.

Pear exposes tools allowed by your account and permissions. Your AI client decides when to call them. Review recipients, dates, and content before approving writes. Read how Pear handles your data and the current plans before expanding the workflow.

Sources and compatibility status

Research checked on 10 September 2026. This is a custom development path, not a tested Pear robot integration.

Booster SDK and supported development paths

Booster Agent framework and firmware requirements

Booster Agent quick start

Booster speech reference

Booster K1 / T1 + Pear

Find the right connection for your workflow.

Free includes 50 counted provider actions/month. Most provider reads or writes count as one action. Batch writes count once per item. Setup and discovery do not count. Failed actions Pear can confirm had no provider effect also do not count; actions with an unknown outcome may count. Pro removes the cap.