Pick your tool: dashboard, CLI, AI or API
Four ways to build on Anythink: the dashboard, the CLI, AI assistants over MCP, and the REST API with the SDK, and when to use each one.
Last updated
You can build on Anythink four ways: the Anythink dashboard, the CLI, an AI assistant over MCP, and the REST API with the SDK. They all work on the same project, so this isn't a choice you're locked into. Pick the one that fits the job in front of you, and switch whenever it stops fitting.
The four tools at a glance#
| The dashboard | The CLI | An AI assistant (MCP) | The REST API and SDK | |
|---|---|---|---|---|
| Best for | Seeing what's possible, modelling data and editing records by hand | Scripts, CI and repeatable setup | Doing setup and exploration from plain English | The app your users actually use |
| Who uses it | Developers, editors and admins, including people who don't code | Developers and CI jobs | Developers working in Claude Code, Claude Desktop, Cursor or another MCP client | Your own app code and servers |
| How it authenticates | You sign in and get a session. The built-in AI chat acts as you | A CLI profile: a project sign-in, or an API key | Your CLI profile, or an API key you connected with | A user token for signed-in app users, or an API key for servers |
| What it can do | Model data, edit records, manage users and permissions, build workflows and charts, read your API docs, chat with an AI that can read and change your data | A command for each area of the platform, plus fetch for any endpoint |
The same as the CLI, run for you by an assistant | Every record endpoint of the generated API. The SDK handles sign-in and sessions in React apps |
| What it's not for | Repeatable or automated work | Features that need a person at a screen, such as building a chart layout | Unattended automation, or work you haven't read first | Setup tasks you do once. The SDK doesn't read or write data |
| Where to start | Build your first app | Install and use the Anythink CLI | Connect Claude to your backend with MCP | REST API reference |
When to use which#
Modelling data. Start in the dashboard, where you can see entities, fields and relationships as you build them. Once the shape settles, the CLI or an assistant can recreate it on another project. See Model your data.
A production app. Your app calls the REST API. Where people sign in, use a user token, and in a React app the SDK handles sign-in and keeps the session alive. For a server, use an API key and keep it off the client. See Anythink SDK: sign-in and sessions and API keys.
CI and scripts. Use the CLI with an API key, which needs no browser or password prompt. Name the profile on each command with --profile so a script never runs against the wrong project.
Exploring data. Ask an assistant, or use the AI chat in the dashboard. Both can answer questions about your records, and both can change them too, so say you only want to look, or connect with a key that has :read permissions only. See How AI chat and MCP work.
Letting a teammate edit content. Give them a role in the dashboard. They edit records there without touching the CLI or an API key, and the role decides what they can see and change. See Control access: roles, permissions and field-level security.
Automating. Use workflows for logic that reacts to your data, runs on a schedule or answers an API call. Create and manage them from any of the four tools, and call the REST API or the CLI from outside when something external needs to start them.
How they work together#
The dashboard, the CLI and MCP all call the same REST API that your own app uses, and they're all checked by the same roles and permissions. An action one of them can take, your code can take, and one that returns 403 in one returns 403 in the others.
That makes mixing easy, and it's how most projects end up. You might model your data in the dashboard, script seed data with the CLI, ask an assistant to set up a workflow, and have your app read the records over REST, all on one project. Nothing needs converting between them.
Two things to keep in mind. The CLI's active profile is shared by every terminal and tool on your machine, including an assistant using the MCP server, so check which project you're on before changing anything. And an assistant acts with the permissions of whoever or whatever it signed in as, so a scoped API key is the safest way to limit it. See Core concepts for how projects and permissions fit together.