0.32.0

Connecta 0.32.0 makes each endpoint simply writable or read-only, and lets a deployment keep chosen callers, such as an agent's token, off plain /mcp (#820, #821). A deployment can then give an agent one token and per-person pools, and the agent sees only the pool its client picks for each turn.

Every deployment must now choose readOnly, and this breaks existing configurations (#822). readOnly replaces the pool trust setting. The deployment's value applies to /mcp, and each pool inherits it unless it sets its own. A deployment that sets neither readOnly nor trust fails at startup and asks the operator to choose. One that still sets trust anywhere fails with a message naming readOnly. Replace trust: "trusted" with readOnly: false, and trust: "read-only" with readOnly: true. On a read-only endpoint, write tools are left out of search and describe, and every write is refused with read_only_endpoint before validation or dispatch, whether it comes from call_tool, call_destructive_tool or a program. That includes call_destructive_tool, which a read-only pool used to allow with host approval. On a writable endpoint, call_destructive_tool and programs write, and the MCP client owns approval. Guides are documentation and are not filtered, so a guide may name a tool the endpoint refuses. A deployment that set no trust used to let programs read only and allow host-approved direct writes. Choose readOnly: true to stop all writes, or readOnly: false to let programs write too. A pool that relied on the old read-only default now inherits the deployment's value, so set readOnly: true on every pool that must stay read-only. The Node template and Worker example set readOnly: false.

A new top-level grant(identity) admits callers to plain /mcp the way pool grants admit callers to pools (#824). Without it, everyone admitted today is still admitted. Only a literal true admits. A refused caller gets the same 404 as a refused or undeclared pool, and can still open any pool whose own grant admits it. Result paging and the operator UI's catalog and config reads apply the same grant, so a refused token cannot read the full catalog through /ui. OAuth protected-resource metadata stays public, so MCP clients can still discover where to sign in. Deployments that don't set grant need no changes.

mixpanel() gains a REST implementation, via: "api", for what the hosted MCP server cannot answer (#825). It covers raw event export with a size bound, one user's activity stream, profile queries, saved Insights and Funnels reports, retention queries and event import. It authenticates with an operator-managed service account, takes project_id per call (with optional defaultProjectId) and lists the projects the account can reach. Profile updates are left out because Mixpanel's profile endpoint requires the project token, which service-account credentials alone don't provide. The hosted MCP implementation stays the default, so existing Mixpanel configurations are unchanged. A deployment that wants both declares two connections.

The release also adds excludeApps to planningCenter(), Gmail get_attachment and a maintained Wispr Flow provider, and updates the Notion connector to Notion's current limits and errors. CI now runs its checks in parallel, and the redaction tests no longer depend on wall-clock time.