Bring MCP servers to a mobile agent
You've already built (or adopted) MCP servers for your desktop agents. agentlib speaks MCP over both HTTP and WebSocket, so the same servers power your mobile agent — and their tools show up as composable CLIs in the Sh pipeline.
HTTP and WebSocket transports
agentlib implements both MCP transports. WebSocket keeps a live connection for server-initiated notifications; HTTP suits simple request/response tools. Either way, the connection is managed for you and survives the same lifecycle hooks as the rest of the run.
MCP tools become CLIs
Each MCP tool surfaces as a /bin/mcp.<server>.<tool> CLI. That means the model can pipe an MCP tool's output straight into jq, grep, or another CLI — the Unix idiom frontier LLMs are most fluent in — instead of issuing isolated JSON-RPC calls.
One protocol, device and cloud
Because agentlib and your server-side agents both speak MCP, you can run the same tool surface on the backend and on the device. Cloud handles heavy reasoning; the device handles UI orchestration and offline fallback — over the same protocol.
Related use cases
- An in-app AI assistant that ships inside your Flutter app — Build a Claude-Code-grade assistant that runs in your Flutter app on iOS and Android — no Node subprocess, no backend agent runtime.
- Offline and on-device agents with cloud fallback — Run agents on Apple Foundation Models, Gemini Nano, or llama.cpp — and fall back to Anthropic, OpenAI, or Google only when needed.
See how these fit together in the architecture overview, or browse all eight primitives in depth.