June '25 Updates

TL;DR:
MCPs released: AI agents can now configure Terra and answer Terra questions from editors — automation FTW.
New SDK majors: Fern-powered Python & JS clients bring iron-clad typing, model validation, and cleaner errors.
Expo plugin: Terra React 1.8.0 lets you integrate natively without ejecting — full power, zero hassle.
Terra MCPs are live — work with AI right inside your tools 🤖
🛠 ️ What?
We released two Model Context Protocol servers that let AI agents configure and operate your Terra setup directly from your favorite environments. The Terra Config MCP Server gives LLMs tools to manage providers, destinations, and integration states (terra_get_integrations, add_developer_destination, set_provider_state, and more), effectively giving agents the tools to manage the Terra Dashboard. The Terra Knowledge MCP makes Terra know-how queryable by agents, giving assistants all of Terra's Docs. Assistants in editors like VS Code, Cursor, Claude Desktop, or Zed can both understand and change your Terra configuration with natural instructions. 🧰⚡
⚙️ How?
Both servers implement the open Model Context Protocol so editors and agent clients can safely call Terra-aware tools. We exposed a suite of actions for listing and activating integrations, rotating credentials, and pinging destinations, plus knowledge endpoints that surface “how Terra works” in plain language. Because MCP is transport-agnostic, you can run locally with UV or pip, or deploy remotely (e.g., Workers) and connect from Claude/Cloudflare Playground. Guardrails, auth via your API key/dev ID, and idempotent operations keep changes safe and auditable. 🔐🛠️
🤔 Why?
Teams increasingly want copilot-style workflows where setup, troubleshooting, and day-two ops are co-piloted by AI. MCPs remove busywork: an agent can enable Garmin, add an S3 destination, or fetch the popularity of providers, then explain what changed. That shortens onboarding, cuts context switching, and turns “read the docs + click through dashboard” into “tell the agent what you want.” Less yak shaving, more building—and a consistent pathway to automate repetitive configuration at scale. 🚀
Terra API SDK Clients — new Python & JavaScript majors 🧑💻📦
🧪 What?
We shipped major new versions of the Python and JavaScript/TypeScript SDKs, now generated with Fern. You get stronger end-to-end type safety, precise request/response models, and better validation on every call. Errors are cleaner, models are exhaustive, and IDEs understand Terra objects deeply—so auto-complete, inline docs, and refactors “just work.” For TS users, this means first-class generics and discriminated unions; for Python users, dataclass-like models with validated fields. ✨
⚙️ How?
The SDKs are produced from a single canonical spec, then compiled to idiomatic clients per language. We layered in stricter schemas for enums, pagination, and unions, plus runtime checks for required fields and well-formed payloads. CI gates verify that SDK versions align with API changes, reducing drift. The result: predictable semver, safer updates, and consistent behavior across ecosystems. We also tuned ergonomics—sensible defaults, clearer errors, and helper utilities for common flows. 🧪🧰
🤔 Why?
Developers lose time wrestling with mismatched models, vague error shapes, or breaking changes. Strong typing and validated models catch mistakes at compile/run time, turning “mystery 400” into a pinpointed fix. A single source of truth means faster features with less risk, and onboarding is easier when the SDK mirrors the docs and the wire format perfectly. In short: fewer integration bugs, faster delivery, and happier teams. ✅
Terra React — official Expo plugin support from v1.8.0 📱🌈
🔐 What?
Our React package now ships official Expo plugin support (from 1.8.0), so you no longer need to eject to access native capabilities. You can configure permissions, deep links, and native modules through app config, keep OTA updates, and stay fully inside the Expo workflow while integrating Terra’s native features for iOS and Android. 🎉
⚙️ How?
The plugin wires platform settings for you—auto-linking native dependencies, adding required permissions/entitlements, handling background modes, and standardizing build steps—so your app.json/app.config becomes the single source of truth. We tested across common Expo targets and made the setup resilient to typical pitfalls (e.g., Health-related permissions, URL schemes, Gradle bits). Add the plugin, rebuild, and ship—no manual native edits or ejecting. 🔗🧩
🤔 Why?
Ejecting increases risk and slows iteration, especially for product teams that rely on Expo’s rapid build pipeline. By removing that step, you keep velocity high, cut CI complexity, and reduce native maintenance overhead. New teams adopt Terra faster, and existing apps can expand wearable features without overhauling their build system—freeing you to focus on UX, not plumbing. 🚢