Tine

A branching notebook runtime for AI and humans.

Tine is a local-first execution engine where notebooks branch like code. Run work in the browser, connect an agent through MCP, and keep both attached to the same fast local runtime.

Tine gives AI agents a safe place to explore multiple paths in parallel while you keep the browser view over the same local state, logs, and results.

What Tine is

Tine is built around a tree-native notebook model:

• an experiment is the main working unit
• an experiment contains branches
• branches contain cells

Each experiment owns its own execution environment and kernel. Execution happens against branches and cells inside that experiment, which makes it practical to explore multiple paths without collapsing everything into one linear notebook.

In practice, that gives Tine a few important properties:

• local-first execution
• branch-aware notebook workflows
• reproducible runtime ownership
• one backend shared by the UI and MCP

Product shape

Tine has a simple surface model:

• Web UI for people
• Local Rust server as the canonical backend
• Python MCP layer for agent integrations

The UI and MCP are adapters over the same local system rather than separate runtimes.

Quick start

The release-oriented install path is:

pip install tine

Then start the local server for your workspace:

tine serve --workspace . --bind 127.0.0.1:9473 --open

If you want to sanity-check the install first:

tine doctor

Open the app at:

http://127.0.0.1:9473

That install gives you:

• tine as the public wrapper entrypoint
• tine mcp ... for MCP config and stdio adapter commands
• tine-mcp as a compatibility alias for the MCP adapter

On first use, the wrapper resolves a matching Tine engine binary for your OS and architecture.

Supported release targets today:

The server is the canonical local backend. Both the web UI and MCP connect to that same API.

If you do not want the browser to open automatically:

tine serve --workspace . --bind 127.0.0.1:9473

MCP setup

Tine supports agent workflows through MCP.

The intended flow is:

1. start the local Tine server
2. configure a host to launch tine mcp serve
3. let the MCP adapter talk to the same local API used by the UI

The standard MCP stdio command is:

tine mcp serve --api-url http://127.0.0.1:9473

tine-mcp --api-url http://127.0.0.1:9473 is also supported, but tine mcp serve is the preferred public form.

Host path caveat

Some GUI hosts do not inherit the same PATH as your interactive shell.

On macOS this matters most for Claude Desktop. A config that uses:

{
  "command": "tine",
  "args": ["mcp", "serve", "--api-url", "http://127.0.0.1:9473"]
}

is only valid if the Claude process can resolve tine from its own environment.

With pip install --user on macOS, that often means using an absolute command from ~/Library/Python/<python-version>/bin/.

If your host cannot resolve tine, register an explicit command path instead:

tine mcp register --host claude --api-url http://127.0.0.1:9473 --command "$(command -v tine-mcp)"

You can do the same with print-config if you want to manage the file manually:

tine mcp print-config --host claude --api-url http://127.0.0.1:9473 --command "$(command -v tine-mcp)"

MCP config generation

Generate an MCP config document for a supported host:

tine mcp print-config --host vscode

Supported hosts:

• vscode
• cursor
• claude
• generic

If your Tine server uses a non-default API URL, include it explicitly:

tine mcp print-config --host vscode --api-url http://127.0.0.1:9473

Example VS Code config output:

{
  "servers": {
    "tine": {
      "type": "stdio",
      "command": "tine",
      "args": ["mcp", "serve", "--api-url", "http://127.0.0.1:9473"]
    }
  }
}

Example Claude Desktop config output:

{
  "mcpServers": {
    "tine": {
      "command": "tine",
      "args": ["mcp", "serve", "--api-url", "http://127.0.0.1:9473"]
    }
  }
}

For GUI hosts such as Claude Desktop on macOS, you may prefer an absolute command path instead:

{
  "mcpServers": {
    "tine": {
      "command": "/absolute/path/to/tine-mcp",
      "args": ["--api-url", "http://127.0.0.1:9473"]
    }
  }
}

MCP config registration

To write the generated config directly into the standard host config location:

tine mcp register --host vscode --api-url http://127.0.0.1:9473

Equivalent examples:

tine mcp register --host cursor --api-url http://127.0.0.1:9473
tine mcp register --host claude --api-url http://127.0.0.1:9473
tine mcp register --host claude --api-url http://127.0.0.1:9473 --command "$(command -v tine-mcp)"

Default config targets are resolved per OS:

If you prefer to manage the file yourself, print the config and copy it into your host config manually instead of using register.

Common local setup

For the most common local setup:

pip install tine
tine serve --workspace . --bind 127.0.0.1:9473 --open
tine mcp register --host vscode --api-url http://127.0.0.1:9473

That gives you:

• the web UI talking to the local API
• the MCP adapter talking to the same local API
• one local Rust backend shared by both

Development from source

If you are working inside this repository rather than using the release package, the development startup path is:

cargo run -p tine-cli -- serve --workspace . --bind 127.0.0.1:9473 --open

That path is for repo development. For fresh user onboarding and release usage, prefer pip install tine followed by tine serve.

Repository guide

If you are navigating the repo, these are the most relevant top-level areas:

• ui/ for the browser UI
• crates/tine-server/ for the local HTTP and WebSocket server
• crates/tine-cli/ for the local launcher and operator commands
• packaging/python/ for the Python wrapper, packaging, and MCP entrypoints

Contributing

Contributions from both humans and AI agents are welcome.

For contribution rules, issue focus areas, validation guidance, and the current priority list, see the repository-level CONTRIBUTING.md.

Acknowledgements

Tine is grateful to the ipykernel and Jupyter communities. Their work helped establish the notebook and kernel patterns that make interactive computing and tool-driven workflows possible.