Stop Locking Your AI to VSCode! Nanobot Sets MCP Agents Free
What if I told you that every "revolutionary" AI agent you've built this year is secretly trapped? That slick Claude integration, that "intelligent" Cursor workflow, that ChatGPT plugin you spent weeks perfecting—they're all prisoners. Prisoners of someone else's platform, someone else's UI, someone else's rules. And here's the kicker: you built the intelligence, but you don't own the experience.
Sound painfully familiar? You're not alone.
Developers everywhere are waking up to a brutal reality. We've been so dazzled by the magic of Model Context Protocol (MCP) that we missed the cage. VSCode has an MCP host. Claude has one. Cursor, ChatGPT, Goose—they all do. But they're walled gardens. Your agent lives where they say it lives, looks how they say it looks, connects to what they allow it to connect to. Want to embed that same agent into your company's Slack? Your customer-facing website? A voice interface for warehouse workers? Good luck with that.
This is the silent crisis killing AI agent adoption in production. And until now, there was no escape hatch.
Enter Nanobot—the standalone, open-source MCP host that tears down those walls. Not another plugin. Not another closed app with an API bolted on. A real, deployable, hackable MCP host that you control completely. Built by the team at Obot Platform, Nanobot is engineered for developers who are done begging for platform permissions. Whether you need a dedicated chatbot, a headless agent API, or an embedded AI experience in your existing product, Nanobot hands you the keys.
Ready to actually own your AI agents? Let's dive deep.
What Is Nanobot? The MCP Host Developers Actually Needed
Nanobot is an open-source MCP host designed to build, deploy, and manage AI agents using the Model Context Protocol (MCP) and MCP-UI. Created by Obot Platform, it fills a critical gap in the current AI infrastructure landscape: there was no standalone, production-ready MCP host that developers could freely deploy anywhere.
Here's the problem that makes Nanobot essential. The MCP specification defines three roles: servers (tools/resources), clients (connections), and hosts (the orchestrator that combines servers with LLMs and presents the agent experience). Every major application—VSCode, Claude Desktop, Cursor, ChatGPT, Goose—implemented their own host. But these hosts are inseparable from their applications. You can't extract Claude's MCP host and run it on your Kubernetes cluster. You can't take Cursor's agent engine and embed it in your React app.
Nanobot changes everything by being host-only, application-agnostic, and completely open-source. It's the Docker of MCP hosts—run it anywhere, integrate it everywhere.
⚠️ Alpha Warning: Nanobot is under heavy development with significant breaking changes expected. The architecture is actively evolving. This is bleeding-edge territory—perfect for innovators, less ideal for risk-averse production deployments without safeguards.
Why it's trending now: The MCP ecosystem is exploding. Thousands of servers are being built, but developers are hitting the "host bottleneck"—they can prototype in Claude but can't productize. Nanobot arrived at exactly this inflection point, offering the escape velocity that MCP-based development desperately needs.
Key Features: The Technical Depth You Need
Nanobot isn't a toy. It's engineered for real infrastructure decisions. Here's what separates it from makeshift alternatives:
True Standalone MCP Host Architecture
Unlike platform-locked hosts, Nanobot runs independently. Deploy on bare metal, containers, or serverless. Embed in existing applications. Expose via API. The host logic is decoupled from any consumer interface, enabling voice, SMS, email, AR/VR, Slack, or custom web frontends.
Dual Configuration System
Nanobot offers unprecedented flexibility in how you define agents:
- Single-file
nanobot.yaml: Fast, compact, perfect for simple deployments - Directory-based with
.mdagents: Scalable, git-friendly, ideal for multi-agent systems with version-controlled prompts
Multi-Provider LLM Support (Built-In + Custom)
Stop rewriting integrations. Nanobot ships with native support for:
- OpenAI (GPT-4, GPT-4.1, and full model lineup)
- Anthropic (Claude 3, Claude 3.7 Sonnet, and beyond)
Need more? Configure any OpenAI-compatible endpoint via llmProviders with explicit dialect control:
OpenAIResponses— OpenAI's latest Responses APIOpenAIChatCompletions— Classic chat completionsAnthropicMessages— Anthropic's Messages APIOpenResponses— Generic compatibility layer for Ollama, local models, and custom endpoints
MCP-UI Compliance
Beyond raw MCP, Nanobot implements MCP-UI specifications for rich interactive experiences—forms, confirmations, streaming updates, and structured outputs that go beyond plain text chat.
Auto-Entrypoint & Agent Precedence
Smart defaults reduce boilerplate. Drop agents/main.md and it automatically becomes your default agent. Markdown-defined agents override YAML-defined ones with the same name, enabling rapid iteration without config duplication.
Development-Ready UI Hot-Reloading
The built-in UI (./ui directory) supports live development with Vite. Run Nanobot on :8080, hack the UI on :5173, and see changes instantly. No rebuild cycles killing your flow.
Use Cases: Where Nanobot Destroys the Competition
1. Customer-Facing Embedded Agents
Your SaaS product needs an AI assistant that understands your API, respects your branding, and lives on your domain. Nanobot lets you embed a fully MCP-powered agent with custom tools (billing lookup, feature flags, support escalation) without routing data through third-party platforms. Your data, your infrastructure, your control.
2. Internal Operations & DevOps Automation
Build agents that connect to your Kubernetes clusters, monitoring systems, and deployment pipelines via MCP servers. Deploy Nanobot internally with Ollama for zero data exfiltration. The directory-based config means each team maintains their agents as .md files in Git—code review for prompts, rollback for behavior changes.
3. Multi-Channel AI Orchestration
One agent logic, infinite interfaces. Nanobot's host-only design means the same MCP configuration powers your Slack bot, your email auto-responder, your SMS helpline, and your web chat. The host handles LLM orchestration and tool calling; your frontend handles presentation.
4. Gaming & Interactive Entertainment
The Blackjack demo proves Nanobot handles stateful, turn-based interactions with MCP tools for game logic. Extend this to RPG NPCs, trading card game judges, or interactive fiction where AI agents manage complex rule systems via tool calls.
5. Research & Prototyping Labs
Need to A/B test Claude vs. GPT-4 vs. local Llama on the same MCP tool suite? Nanobot's provider abstraction lets you swap models with one config change, not a rewrite. Perfect for benchmarking, safety testing, and capability evaluation.
Step-by-Step Installation & Setup Guide
Prerequisites
- macOS or Linux (Windows via WSL)
- Homebrew installed
- API keys for your chosen providers (OpenAI, Anthropic, or custom endpoints)
Installation via Homebrew
The fastest path to a running Nanobot:
# Add the Obot Platform tap and install
brew install obot-platform/tap/nanobot
# Verify installation
nanobot --version
This installs the nanobot CLI with all core functionality.
Environment Configuration
Set your provider credentials before running:
# For OpenAI models (GPT-4, GPT-4.1, etc.)
export OPENAI_API_KEY=sk-your-key-here
# For Anthropic models (Claude 3, Claude 3.7 Sonnet, etc.)
export ANTHROPIC_API_KEY=sk-ant-your-key-here
# Optional: Custom base URLs for proxies or enterprise deployments
export OPENAI_BASE_URL=https://your-proxy.example.com/v1
export ANTHROPIC_BASE_URL=https://your-proxy.example.com/v1
For persistent configuration, add these to your ~/.zshrc, ~/.bashrc, or use a tool like direnv.
Quick Start: Single File Configuration
Create nanobot.yaml:
agents:
assistant:
name: My First Agent
model: gpt-4.1
mcpServers: mytools
mcpServers:
mytools:
url: https://tools.example.com/mcp
Launch:
nanobot run ./nanobot.yaml
Access the UI at http://localhost:8080.
Production-Ready: Directory-Based Setup
Create structured, maintainable configurations:
mkdir -p my-nanobot/agents
cd my-nanobot
nanobot.yaml (shared infrastructure):
llmProviders:
ollama:
dialect: OpenResponses
baseURL: http://localhost:11434/v1
mcpServers:
store:
url: https://api.mystore.com/mcp
headers:
Authorization: Bearer ${STORE_API_TOKEN}
agents/main.md (default agent):
---
name: Shopping Assistant
model: anthropic/claude-3-7-sonnet-latest
mcpServers:
- store
temperature: 0.7
---
You are a helpful shopping assistant. Help users find products and answer their questions.
Run with:
nanobot run ./my-nanobot/
Or use the default path convention:
mkdir -p .nanobot/agents
# ... place config files ...
nanobot run # Auto-discovers .nanobot/ directory
Development Mode with Live UI
For UI customization:
# Clean previous builds
rm -rf ./ui/dist
# Rebuild binary
make
# Terminal 1: Start Nanobot
nanobot run ./my-config/
# Terminal 2: UI development server
cd ui
npm run dev # Serves on :5173, Nanobot forwards from :8080
REAL Code Examples from the Repository
Let's dissect actual implementations from the Nanobot repository, with deep technical commentary.
Example 1: Blackjack Game Agent (Production MCP Integration)
This is the live Blackjack demo—a stateful game agent using remote MCP tools:
# examples/blackjack.yaml
agents:
dealer:
name: Blackjack Dealer
model: gpt-4.1
mcpServers: blackjackmcp
# The agent identity—model handles persona via name + instructions
mcpServers:
blackjackmcp:
url: https://blackjack.nanobot.ai/mcp
# Remote MCP server hosting game logic: deal cards, calculate scores,
# enforce rules. The LLM never directly manipulates game state;
# it calls tools that do, ensuring deterministic rule compliance.
Why this matters: The LLM acts as conversational interface and strategy engine, but all state mutations flow through typed MCP tools. This prevents hallucinated card deals, cheating, or invalid game states. The separation of concerns is architecturally clean—LLM handles language, MCP server handles logic.
Example 2: Multi-Provider LLM Configuration
Nanobot's provider system is remarkably flexible. Here's the complete reference for custom endpoints:
# nanobot.yaml - llmProviders section
llmProviders:
# Built-in providers shown for override capability
openai:
dialect: OpenAIResponses # Latest OpenAI API format
apiKey: ${OPENAI_API_KEY} # Environment variable injection
baseURL: ${OPENAI_BASE_URL} # Optional: enterprise proxy, custom endpoint
anthropic:
dialect: AnthropicMessages # Claude's native message format
apiKey: ${ANTHROPIC_API_KEY}
baseURL: ${ANTHROPIC_BASE_URL}
# Azure OpenAI - enterprise deployment pattern
azureOpenAI:
dialect: OpenAIResponses
apiKey: ${AZURE_API_KEY}
baseURL: https://my-resource.cognitiveservices.azure.com/openai/v1
# Critical: Azure paths differ from standard OpenAI; baseURL must include
# deployment-specific routing
# AWS Bedrock - managed infrastructure
bedrockOpenAI:
dialect: OpenAIResponses
apiKey: ${BEDROCK_API_KEY}
baseURL: https://bedrock-mantle.us-east-1.api.aws/v1
# Bedrock's OpenAI-compatible layer; dialect handles translation
# Local/Ollama - zero-cost, private inference
ollama:
dialect: OpenResponses # Generic compatibility layer
baseURL: http://localhost:11434/v1
# No apiKey needed for local Ollama; OpenResponses dialect normalizes
# various local model APIs to consistent interface
The dialect field is Nanobot's secret weapon. Instead of brittle provider-specific code, it uses protocol adapters. Adding a new compatible endpoint means specifying the dialect—no Nanobot update required for standard cases.
Example 3: Directory-Based Agent with Markdown Frontmatter
This pattern enables prompt-as-code workflows:
---
# YAML frontmatter: machine-parsable configuration
name: Shopping Assistant # Human-readable agent identity
model: anthropic/claude-3-7-sonnet-latest # Provider/model selector with namespace
mcpServers:
- store # References mcpServers.store from nanobot.yaml
temperature: 0.7 # Creativity control: lower = more deterministic
---
# Markdown body: agent instructions (system prompt)
You are a helpful shopping assistant.
Help users find products and answer their questions.
## Behavioral Constraints
- Always confirm product availability before claiming in stock
- Suggest alternatives when items are unavailable
- Escalate to human support for refund/complaint requests
Technical significance: The YAML frontmatter is parsed as structured config; the markdown body becomes the system prompt. This enables:
- Git diffs for prompt changes (trackable, reviewable, revertable)
- Multiple agents in one repo without YAML spaghetti
- Non-technical stakeholders can edit prompts without touching infrastructure config
Example 4: Running with Directory Configuration
# Explicit path
nanobot run ./my-config/
# Default path convention (zero arguments)
nanobot run # Automatically discovers ./.nanobot/ if it exists
Resolution precedence:
- Command-line argument if provided
./.nanobot/directory if it exists- Error if neither found
This convention-over-configuration approach reduces operational friction while remaining explicit when needed.
Advanced Usage & Best Practices
Security Hardening
- Never commit API keys. Use environment variable interpolation (
${VAR}syntax) exclusively. - For production, inject secrets via your orchestration platform (Kubernetes secrets, AWS Parameter Store, Vault).
- MCP server URLs with authentication: use
headersfor bearer tokens, consider mTLS for sensitive tools.
Multi-Agent Architecture Patterns
Leverage directory-based config to build agent swarms:
agents/router.md— Intent classification and delegationagents/researcher.md— Deep information retrieval via MCP toolsagents/synthesizer.md— Response formatting and quality control
Use mcpServers in nanobot.yaml as shared services; agent-specific tool access via per-agent mcpServers lists.
Performance Optimization
- Local models via Ollama: Cut latency and costs for internal tools. The
OpenResponsesdialect handles most popular local serving frameworks. - Temperature tuning: Use
0.0-0.3for deterministic tool calling,0.7-1.0for creative content generation. - Connection pooling: Nanobot maintains persistent connections to MCP servers; ensure your servers support HTTP/2 or connection reuse.
Observability
Since Nanobot is alpha, build your own monitoring:
- Log MCP tool call latency and error rates
- Track LLM token usage per provider for cost allocation
- Implement tracing across agent → LLM → MCP server boundaries
Comparison with Alternatives
| Capability | Nanobot | Claude Desktop | Cursor | VSCode MCP | Custom Build |
|---|---|---|---|---|---|
| Standalone deployment | ✅ Yes | ❌ No | ❌ No | ❌ No | ⚠️ Months of work |
| Open source | ✅ Apache 2.0 | ❌ Closed | ❌ Closed | ✅ Partial | Varies |
| Custom UI/embed | ✅ Any interface | ❌ Claude only | ❌ Cursor only | ❌ VSCode only | ✅ If you build it |
| Multi-provider LLM | ✅ 4+ dialects | ❌ Anthropic only | ⚠️ Limited | ⚠️ Limited | ✅ Your effort |
| Directory-based config | ✅ .md agents |
❌ No | ❌ No | ❌ No | ❌ Build it |
| MCP-UI support | 🚧 Partial | ❌ No | ❌ No | ❌ No | ❌ Spec unclear |
| Production maturity | ⚠️ Alpha | ✅ Stable | ✅ Stable | ✅ Stable | Varies |
| Time to first agent | ⏱️ 5 minutes | ⏱️ 2 minutes | ⏱️ 2 minutes | ⏱️ 10 minutes | ⏱️ Weeks |
The verdict: If you need to own the infrastructure, Nanobot is your only viable choice today. If you're prototyping in a closed tool, that's fine—but when you're ready to ship, you'll hit Nanobot's problem or use Nanobot's solution.
FAQ
What exactly is an MCP host, and why do I need a standalone one?
An MCP host orchestrates LLM inference with MCP tool servers and presents the combined experience to users. Existing hosts are bundled into applications you don't control. A standalone host like Nanobot lets you deploy agent infrastructure anywhere, with any interface, under your governance.
Is Nanobot production-ready?
Not yet. The project is alpha with heavy development and expected breaking changes. Use it for prototyping, internal tools with tolerance for evolution, or contributing to shape the roadmap. Mission-critical production deployments should wait for stability commitments or maintain hard forks.
Can I use Nanobot with local models?
Absolutely. Configure Ollama or any OpenResponses-compatible endpoint in llmProviders. This is ideal for air-gapped environments, cost reduction, or data privacy requirements. The OpenResponses dialect handles most local serving scenarios without code changes.
How does directory-based configuration improve my workflow?
It separates infrastructure (shared in nanobot.yaml) from agent behavior (individual .md files). This enables Git-based prompt management, team collaboration via pull requests, and non-technical prompt editing. Agents become versioned assets, not buried configuration.
What's MCP-UI, and why does Nanobot support it?
MCP-UI extends MCP with interactive elements: forms, confirmations, progress indicators, and rich outputs. Standard MCP is text-in, text-out. MCP-UI enables sophisticated applications like multi-step wizards, file uploads, and real-time dashboards. Nanobot's partial support is ahead of most alternatives.
How do I migrate from mcp-servers.yaml?
The old format is deprecated but still supported. Move your server definitions into nanobot.yaml under the mcpServers key. The structure is similar; the main change is consolidated configuration. See the directory-config example for patterns.
Where can I get help or contribute?
The project lives at github.com/obot-platform/nanobot. Issues, PRs, and discussions are welcome. Given the alpha state, your feedback directly shapes the architecture.
Conclusion: Own Your Agent Infrastructure or Rent It Forever
The AI agent landscape is bifurcating fast. One path: convenient, closed, controlled by platforms that can change terms, raise prices, or sunset features. The other: open, portable, yours to extend and embed.
Nanobot is the infrastructure bet for developers who refuse to rent their own intelligence.
It's not perfect. It's alpha, it's evolving, and you'll hit rough edges. But it's also the only open-source, standalone MCP host that lets you build real agent products—not demos, not prototypes, but deployable systems with your branding, your data policies, your integration choices.
The examples prove it: live blackjack games, Hugging Face integrations, Shopify shopping assistants—all running on infrastructure the developers fully control. That's not possible with any other MCP host today.
My take? If you're building anything agent-shaped that needs to exist beyond someone else's app, Nanobot deserves your attention. Install it, break it, improve it, or just watch the repository. But don't pretend the host bottleneck doesn't exist. It does. And now there's a way through it.
Start building your standalone MCP agents today:
👉 github.com/obot-platform/nanobot
The future of AI agents isn't locked in a sidebar. It's open, hosted, and yours to command.