Concepts

How Automata works

Automata separates management from tool execution, then narrows each MCP request by connection kind and connector-token scope.

Two surfaces, one server

The web UI uses a PocketBase session cookie. People create connections, pair accounts, rotate credentials, and manage connector tokens there.

The MCP endpoint uses Authorization: Bearer <token> or /mcp/<token>. It never falls back to a browser session. An invalid token receives a proper 401 response with WWW-Authenticate; a PocketBase outage returns 503 rather than pretending the token was revoked.

Connections and tokens

A connection is exactly one WhatsApp account, Telegram account, or PostgreSQL database. Every connector token resolves to exactly one connection, so tools do not accept a connection argument.

The connection keeps upstream credentials server-side. WhatsApp uses a per-instance Evolution token, Telegram uses a per-session bridge token, and PostgreSQL uses the supplied connection string. Connector tokens are Automata credentials, not upstream API keys.

Permission enforcement

Every tool request passes two independent gates:

  1. Connection kind: a PostgreSQL token never registers messenger tools.
  2. Token scope: only explicitly enabled actions, chats, and tables are reachable.

For PostgreSQL, query plans are checked before data is read or modified. For messenger searches, chat allowlists are applied in the data query rather than filtering results afterward.

Service architecture

ServiceResponsibilityRequired when
WebManagement UI and MCP endpointAlways
PocketBaseUsers, sessions, connections, scopes, and token hashesAlways
Evolution API + Redis + PostgresWhatsApp pairing, transport, and message storageWhatsApp is enabled
Telegram bridge + PostgresPersonal-account sessions and synced chatsTelegram is enabled
User databaseThe database reached by PostgreSQL toolsA PostgreSQL connection is added
View source