data-ai MCP Server
OpenSail is the open-source alternative to Codex App, Claude Desktop, Cursor, and Cowork for agentic software work.
Discovered via github-topic:mcp and last synced 2mo ago.
Install instructions not detected yet
Check the source repository for the latest setup steps.
Description
What runs here
About 99% of agent operations run on the first two tiers. Containers hibernate when idle and wake on demand. The whole system is backed by a custom CSI driver built on BtrFS that handles snapshot management, S3-backed storage, and backup/restore. Agent workspaces persist independently of any running container and mount on demand across tiers. **Multi-container by default.** Each project gets its own K8s namespace. Every container gets its own Deployment, Service, and Ingress. Pod affinity pins all containers in a project to the same node so they can share the BtrFS volume. Inter-container networking uses cluster DNS (`backend.proj-abc123.svc.cluster.local:8000`). Infrastructure containers (Postgres, Redis) get their own isolated PVCs. Start a project and the orchestrator creates the namespace, provisions the PVC, deploys the file manager, clones repos, and spins up all containers with readiness probes gating traffic. **Hibernation is volume-level.** Hibernate a project and it snapshots the entire shared volume, then tears down the namespace. Restore from snapshot and all containers come back together with their files intact. Atomic save and restore for multi-container projects. <p align="center"> <img src="assets/agents-parallel.png" alt="Agents running in parallel — close the tab and they keep working" width="85%" /> </p> --- ## Gateway API and MCP Server Rent your compute to other agents. OpenSail exposes your running instance to the outside world through two interfaces: **Gateway API:** External users (agents or humans) can interact with your OpenSail instance using an API key. They get their own sandboxed containers, can invoke agents, and run workflows. The API supports webhook callbacks on completion, scoped permissions per key, and project-level isolation. **MCP Server (in development):** OpenSail itself becomes an MCP tool server. External coding agents (Claude Code, Cursor, Codex, or your own) can connect to your OpenSail instance, get sandboxed compute, use your agents, and publish apps directly from their development environment. Your instance becomes infrastructure that other agents can build on. --- ## Connectors Every tool your agent needs, already wired. <p align="center"> <img src="assets/connectors.png" alt="Connect any tool, API, MCP server, or webhook" width="85%" /> </p> Agents can gather context and take action across dozens of tools. OpenSail supports MCP (Model Context Protocol) natively. Plug in Slack, Gmail, Google Drive, Linear, Jira, Notion, GitHub, Salesforce, HubSpot, Confluence, databases, internal APIs, or anything with an MCP server or a REST endpoint. Connectors are first-class. When you build an agent, you pick the tools it needs, set the permissions, and it just works. Add new connectors while keeping the agent's core instructions stable. MCP tool schemas are cached and bridged into the agent's tool registry automatically. Build your own connectors for internal systems. Publish them for your team. The protocol is open, so nothing is locked in. --- ## Agent skills Teach an agent once. Any agent can use it forever. Skills are reusable capabilities you teach your agents. Package what works into a skill and let the agent use it when it needs to. Skills are loaded progressively: a lightweight catalog (name + description) is injected into the agent's context, and the full skill body is pulled on demand only when the agent decides to use it. This keeps the context window lean. Skills can be anything: a data analysis pipeline, a writing style, a code review checklist, a research methodology, a report template. Build them once, attach them to any agent or workflow. Share them on the marketplace. --- ## Desktop App The full cloud platform, running on your laptop. OpenSail ships as a native desktop app built on Tauri v2. It runs the exact same orchestrator as the cloud version, locally, with zero network dependency by default. Install and start building with the local runtime. The desktop app is a Tauri shell wrapping a PyInstaller-frozen FastAPI sidecar. The sidecar binds to localhost on a random port, mints a per-launch bearer token, runs migrations against a local SQLite database, and starts the same server you'd get in the cloud. The frontend is identical. The agent is identical. The tools are identical. **Three runtimes per project, your choice:** - **Local** - Subprocesses on your machine with the default local runtime. - **Docker** - Docker Compose if you have it installed. Full container isolation on your machine. - **Kubernetes** - Connect to a remote K8s cluster (your own or Tesslate's cloud). Get sandboxed multi-container environments, BtrFS snapshots, tiered compute, the full infrastructure. You pick the runtime per project. A personal script can run local. A multi-container app can run on Docker. A production workflow can run on your own K8s cluster. Same UI, same agent, same workspace for all three. **Cloud pairing.** Pair your desktop app to a cloud instance (Tesslate's or your own self-hosted cluster) and you get Codex-style cloud sandboxing from your own machine. Your projects sync bidirectionally. Build locally, push to the cloud, run at scale. Pull results back down. The desktop stays your home base, the cloud is your compute. **What lives on your machine:** ``` $OPENSAIL_HOME/ ├── projects/{slug}-{uuid}/ # your project files ├── cache/ # cloud token, marketplace cache, port allocations ├── agents/{slug}/manifest.json # installed agents ├── skills/{slug}/manifest.json # installed skills ├── logs/ └── opensail.db # local SQLite database ``` One folder. Wipe it, you get a clean install. **Offline-first marketplace.** Agents, skills, bases, and themes install locally from the cloud marketplace with SHA-256 verified downloads. Once installed, they work offline. Local items and cloud items merge, local wins by slug. Cache is stale-while-revalidate with background refresh. **Permissions per project.** Each project has a `.tesslate/permissions.json` that gates what agents can do: shell access, network calls, git push, file writes, process spawning. Three policies per capability: `allow` (silent), `deny`, `ask` (approval prompt in the tray, TUI, or browser). "Always allow" persists your decision back to the file. Budget caps with monthly limits and alert thresholds are built in. **Approval workflow.** When an agent hits a gated tool, the desktop shows a tray notification with an approval card. Approve, deny, or "always allow" for that tool. Human-readable ticket refs (TSK-0001, TSK-0002) so you can track what the agent asked for and what you approved. **Adopt existing folders.** Point OpenSail at any directory on your machine and it becomes a project. POSIX uses symlinks; Windows writes a marker file. Git root detection groups sessions by repo automatically. One agent session can span multiple directories. --- ## Model Providers One agent. Every model. OpenSail is model-agnostic. All model calls route through LiteLLM. Switch providers while keeping your agents intact. **Supported providers:**
Platform/runtime contributors
Targets