Automation overview
Reviewedbyfl
🧭
Pick the right entry point.
MCP, CLI, agent skills, and a public API, where to start? This page exists to help you pick the right tool for your use case.
| Tool | What it is | Authentication | Use case |
|---|---|---|---|
| MCP server | Remote endpoint for AI agents | OAuth (via browser) | Personal AI agent |
| CLI | frbit binary, client of API | Personal API token | AI agent, script, CI jobs |
| Agent skills | Workflow instructions | Nothing of their own | Help your agent succeed |
| Public API | REST interface over HTTP | Personal API token | Build an integration |
How they relate
platform
│
├── MCP server ◀── OAuth ────── AI agent
│
└── public API ◀── API token ── own code, integrations
│
└── CLI ◀── API token ── terminal, CI job, AI agent
The public API is the base layer and the CLI is a client of it, which is why both take the same personal API token. The MCP server is a second front door with its own OAuth flow, not a wrapper around the REST API.
Agent skills sit outside that picture. They hold no credentials and open no connection — they tell an agent how a deployment is done here, how a database is synced, and which command to run over SSH. The agent acts through whatever connection it has.
The common pair is the MCP server plus agent skills: the agent sees the account and follows the platform workflows. frbit setup agent installs both in one command.
Both a token and an MCP connection?
No. Connecting over MCP issues its own credentials in the browser, bound to that one agent. A token only comes in when:
- The CLI is installed — it is an API client and signs in with a token, even for
frbit setup agent. Going through the CLI is what makes both credentials appear at once. - The MCP client has no OAuth support — the token goes in as a bearer credential instead.
- Something calls
/v1directly — a script, a CI job, or an integration in another language.