Integrations Overview
How LisaOS reaches the outside world — MCP servers, command-line tools, and plugins.
LisaOS is not sealed. It reaches external systems — issue trackers, messaging, design tools, the web, backup stores — through three integration surfaces, each with a different contract.
Three surfaces
| Surface | What it is | When it is used |
|---|---|---|
| MCP servers | Model Context Protocol servers exposing typed tools to the model | Structured, tool-shaped access — issue tracking, messaging, design, the memory gateway itself |
| CLI tools | Command-line binaries invoked from the shell | Web research, workspace access, media extraction, backups, headless sessions |
| Plugins | Bundled capability packs for the local shell | Frontend workflows, code review, security guidance, and their own skills |
Credentials and coordinates
Every integration that touches a credential resolves it the same way: credential-store first, environment fallback, never a literal in source. Hosts, ports, tokens, and account identifiers are deployment coordinates and are withheld from this documentation by design — what is documented is the shape of each integration (its transport, its tool surface, and what depends on it), which is the part that describes the architecture.
The one that is different
Most integrations reach outward. One reaches inward: the memory gateway is itself an MCP server, and it is the integration every session and every agent depends on — it is the front door to the three-layer memory stack, dispatch control, and the session registry. It is documented in depth under gateway; here it is listed as what it also is — an MCP server on the standard tool surface.