VS Code
Native VS Code extension
Developers who want visual discovery, workspace previews, managed runs, and one place to see project readiness.
Setup → Distribution
FAI Packages
Choose the delivery channel that fits your operating model.
Choose → compare → set up → verify. FrootAI packages expose related capabilities through different interfaces and runtime boundaries; they are not interchangeable bundles with identical behavior.
Fast recommendation
Use VS Code for the complete workbench
Choose MCP instead when your primary interface is an AI client, or Python when FrootAI belongs inside application code.
Choose a package channel
Start from where the work should happen
The selected channel shows its operating model and honest tradeoff. Installation and verification stay in the canonical Setup Guide.
- Best for
- Developers who want visual discovery, workspace previews, managed runs, and one place to see project readiness.
- Runtime model
- Native VS Code extension
- Works offline
- Bundled catalogs and local discovery remain available; hosted reasoning and cloud operations are separate boundaries.
- Key tradeoff
- Best integrated experience, but intentionally tied to VS Code as the primary interface.
What this channel is designed to do
- Workspace Home and project readiness
- Solution Play and accelerator discovery
- Preview-before-write project assembly
Compare all channels
Same ecosystem, different operating boundaries
MCP
Hosted HTTPS + local npm
AI clients, agents, and teams that want FrootAI tools without adopting a visual workbench.
Setup →Python
SDK + Python MCP
Python services, notebooks, automation, evaluation code, and teams that prefer a Python-native dependency boundary.
Setup →CLI
Node.js 18+ · project or global install
FrootAI monorepo authors, primitive maintainers, release operators, and Factory automation.
Setup →Docker
Containerized MCP runtime
DevOps, CI, Kubernetes, sidecars, and teams that require a pinnable runtime image.
Setup →What every channel shares
- The same FrootAI product vocabulary and canonical identities
- Evidence labels that separate discovery, source, build, and deployment states
- Public links to source, documentation, and community contribution paths
- No silent cloud deployment from package installation
What differs by channel
Interface
Editor, MCP client, Python process, terminal, or container runtime
Credential boundary
Hosted, local process, application environment, shell, or container configuration
Offline behavior
Varies by operation; package presence never makes an upstream or hosted dependency offline
Operational ownership
Updates, runtime lifecycle, logs, and recovery belong to the chosen channel
Related product surfaces
Useful destinations that are not packages
Keep distribution choices separate from catalogs, hosted APIs, and reusable solution products.
Plugin Marketplace
Discover integrations and extensions. This is a product catalog, not a package runtime.
REST API
Use documented hosted HTTP contracts when MCP or an SDK is not the right integration boundary.
Solution Plays
Choose a complete architecture and delivery contract before selecting how to work with it.
Solution Accelerator
Discover and inspect cross-publisher repositories, evidence, and Repo Intelligence.