Connect your favorite AI coding agents with BYOB ->
How do you connect agents with BYOB CLI and MCP? #
Coding agents are only as good as their context. Out of the box, most agents know nothing about your deployments, your database state, your environments, or your project conventions. They guess. Sometimes the guesses compile.
Think of MCP as a universal adapter for agent context. Before it, every data source needed its own custom wiring, like traveling with a bag of country-specific plugs. Anthropic open-sourced the Model Context Protocol in late 2024 precisely to replace those fragmented integrations with one standard (https://www.anthropic.com/news/model-context-protocol). BYOB CLI builds on that standard to plug your agents straight into your projects.
| Agent | Install command | After install |
|---|---|---|
| Codex | npx byob cli codex install | Approve in dashboard |
| Claude Code | npx byob cli claude install | Approve in dashboard |
| Gemini | npx byob cli gemini install | Approve in dashboard |
| OpenCode | npx byob cli opencode install | Approve in dashboard |
| Any agent | byob projects listing | Verify account scope |
[!TIP] Try it: JSON Formatter
What does MCP standardize? #
The spec defines an open protocol for connecting LLM applications with external data and tools over JSON-RPC (https://modelcontextprotocol.io/specification/2026-07-28). Three roles participate: hosts are the LLM applications, clients are connectors inside them, and servers provide context and capabilities. The design borrows from the Language Server Protocol, which solved the same fragmentation problem for programming language tooling years earlier.
Servers expose three features. Tools are functions the model can invoke, like querying a database or triggering a deploy. Resources are data the model can read, like files, schemas, or environment details, each identified by URI. Prompts are templated messages and reusable workflows. That trio covers nearly everything an agent needs: the ability to see, the ability to act, and the ability to follow a playbook.
Two details from the spec matter for daily use. Tools are model-controlled, meaning the language model discovers and calls them from context, but the spec urges a human in the loop with visible indicators and confirmation prompts for consequential operations (https://modelcontextprotocol.io/specification/2026-07-28/server/tools). Resources are application-driven, with hosts deciding how to surface them, from explicit pickers to automatic inclusion (https://modelcontextprotocol.io/specification/2026-07-28/server/resources). BYOB CLI respects both: the agent proposes, you approve, and project context arrives without copy pasting.
How does the BYOB bridge work? #
Installing the BYOB CLI spins up a local MCP server that bridges your agent and the BYOB control plane. Your agent gains tools like database inspection and deployment plus resources like preview URLs, active workspaces, and synced coding skills.
A natural language request like "check my database schema and deploy this project" stops being a fantasy. The agent routes the database half to a schema tool and the deploy half to a deploy tool, both speaking the same protocol. No plugins per agent. No bespoke glue per project. One bridge, every supported agent.
How do one-command installers work? #
Each supported agent gets a dedicated installer that handles OAuth, configuration, and skill syncing. Copy the command from the Agent Connections tab in your Project Control Center, where it arrives pre-filled with your project ID.
Codex:
npx -y byob-cli codex install --project-id YOUR_PROJECT_IDThis triggers the OAuth device flow, configures the Codex config file, and installs the BYOB skill into the agent skills directories.
Claude Code:
npx -y byob-cli claude install --project-id YOUR_PROJECT_IDThis registers the MCP server in the Claude configuration and installs the shared skill alongside it.
Antigravity (Gemini):
npx -y byob-cli gemini install --project-id YOUR_PROJECT_IDThis writes the MCP server config and installs the shared skill into the agent skills path.
OpenCode:
npx -y byob-cli opencode install --project-id YOUR_PROJECT_IDAfter running the installer locally, click Approve agent in the dashboard. That click closes the authorization loop: the device flow proves who you are, the approval binds the agent to the project, and grants stay scoped to your account. Until you approve, the agent waits outside. That ordering is deliberate.
How do synced AIR coding skills work? #
Tools let the agent act. Skills teach it how your project thinks.
Running an installer, or a manual skill sync, downloads BYOB AIR coding skills into the local agent environment. These skills carry reusable implementation knowledge for the core stacks: SvelteKit and UI quality standards, Cloudflare D1 patterns, Better Auth with magic links, and payment orchestration. The agent writes code matching BYOB production conventions instead of hallucinating generic boilerplate that you rewrite later.
This is the difference between a contractor who read your handbook and one who is winging it. Same hourly rate. Very different pull requests.
You can also authenticate without linking an agent by running the standalone login, which starts the device flow and stores credentials for direct CLI usage.
How do multiple projects and targeting work? #
Grants are account-scoped, so one approval covers your access while individual commands target specific projects. The agent passes the project ID through the MCP server per request. To see what your account can reach, list projects directly:
byob projectsFor direct IDE access instead of agent mediation, install the workspace SSH configuration and connect VS Code or Cursor straight to the underlying environment:
npx -y byob-cli workspace ssh-config --install --project-id YOUR_PROJECT_IDTwo doors into the same room. Agents use the protocol door. Humans use SSH. Both respect the same grants.
How are security and local telemetry handled? #
Credentials stay on your machine. The CLI stores the OAuth token locally and records compact diagnostics like command outcomes and durations in a local telemetry file. Project IDs, URLs, emails, tokens, and raw server errors are explicitly redacted from those diagnostics. Telemetry can be disabled entirely with one command.
The posture matches the protocol philosophy: least privilege, local secrets, explicit approval. An agent with deploy tools is powerful, which is exactly why the approve click, the scoped grants, and the redacted logs exist. Power with receipts.
What do you do when the connection misbehaves? #
Three fixes cover most bad days. If the agent cannot see tools, confirm the MCP server block actually landed in the agent config file and restart the agent process, since most agents read that config once at startup. If approval never completes, check that the project ID in the install command matches the project open in the dashboard, then rerun the device flow. If the agent acts on stale context, ask it to re-list resources or restart the session rather than arguing with yesterday state. Config, identity, freshness. In that order, every time.
What are the trade-offs? #
Wiring agents through MCP replaces copy pasted context with live tools. Standards help, and they add surface.
| Where this path wins | Where it loses |
|---|---|
| One open protocol (https://modelcontextprotocol.io/specification/2026-07-28) replaces per agent glue, with tools and resources split the way the spec intends (https://modelcontextprotocol.io/specification/2026-07-28/server/tools) (https://modelcontextprotocol.io/specification/2026-07-28/server/resources) | Each agent still has quirks in config paths and approval UX, so setup help varies by tool |
| One command installers plus synced skills mean the agent follows project conventions instead of inventing them | Credentials live on your machine and grants need dashboard approval, which slows a first run |
| Human in the loop stays the default for consequential calls, per the spec's own guidance | The bridge only knows what the server exposes. Unusual local setups still need manual context |
Pick the alternative, pasting context by hand or calling the API directly, for one off tasks where install cost exceeds the payoff. For daily work across projects, the bridge pays back within the week.
What we learned building this #
The BYOB CLI starts a local MCP server that exposes tools and resources like preview URLs and workspace tables, a bridge you see wired through src/routes and the control plane. The installer syncs AIR skills into the agent env so SvelteKit and D1 patterns match production, and credentials stay local. We verify the landing page at https://byob.studio returns 200 before handing project context to the model.
Who this is for (and who should skip it) #
This guide helps if you use an AI coding agent and want live project context like preview URLs and skills instead of copy paste.
If you work only in the BYOB editor and never bring an external agent, you can skip the MCP bridge and stay with chat prompts.
One limit to know. External agents only help when they point at the right project and preview URL. A common mistake is sharing connection details too broadly or skipping revocation when a machine is lost, which leaves access open.
- Best for developers connecting external AI agents to live BYOB projects.
- Best for agencies skipping copy paste with shared preview context.
- Best for startups keeping agent work tied to real project state.
The payoff #
A connected agent stops being a code generator and starts behaving like a team member. It sees the schema before suggesting the migration. It knows the preview URL before describing the change. It follows the project conventions because they arrived as skills, not as hopes.
Run one installer tonight, approve it, then ask the agent something that requires live context, like the current database tables or the latest preview link. The moment it answers from your project instead of its training data, the bag of adapters goes in the drawer for good.
Explore the BYOB CLI documentation and connect your agent today ->
