Command line and MCP in app builders: what changes when the project leaves the browser
Most AI building tools live entirely inside a tab. That handles the beginning very well, and it starts to pinch as the project grows: you want to run the app on your own machine, open the files in the editor you already use, ask for a change from the assistant that is already open in your terminal.
That is where two pieces change the daily work, and where platforms differ today: a real command line and an MCP server.
What a command line solves that the browser does not
Three concrete things.
Seeing the whole project at once. On screen, the app's definition is split across tabs: entities here,
automations there, each page's configuration somewhere else. On disk, it is a folder. You open fab.schema.json
and read every entity and field on one screen, and your editor's search works on top of that.
Running before publishing. A command that brings the app up on your machine, on the same template the platform publishes with, gives you the short loop that is missing when every check depends on a deploy.
Automating. As soon as the definition is a file, it goes into version control, into review by pull request, and into CI. That does not matter to everybody, and it matters a great deal to whoever delivers apps to clients.
What an MCP server solves
MCP is the protocol that lets an assistant talk to a tool with no human in between. In practice, it is the difference between these two exchanges:
"Paste your project schema here so I can suggest the automation."
"I will read the schema and write the automation."
The second is what happens when an MCP server is running with your credential. The assistant calls the read operation, gets the real entities, the real fields and the real ids, and writes on top of that.
And this is the part that tends to be underestimated: with no schema at hand, a model invents. A wrong model id answers 404, a field that does not exist answers 422, and the assistant spends three attempts fixing arguments when the problem was not having read anything before writing.
The detail that decides the security: how the key is born
Almost every platform offering terminal access solves authentication the same way: a screen with a "generate key" button, a value shown once, and a warning to keep it somewhere safe.
The problem is not the key, it is its journey. Between that screen and your terminal it passes through the clipboard, nearly always through shell history, sometimes through a chat channel when somebody has to set up another person's machine, and often through a config file that ends up in a repository.
The alternative is the device flow, the same pattern you have used to authorise an app on a television. The terminal asks for an authorisation, shows a short code, and opens a page where you check the code matches and approve. The key is born inside the machine that will use it and is never displayed anywhere.
Three consequences are worth having:
- Nothing to copy means nothing to leak. The key never exists in a displayable form.
- Permission is asked for at the moment. A machine that only needs to look asks for read, and its credential does not even see the write operations. An assistant that cannot see a tool does not try it and does not burn rounds reading a 403 as an argument error.
- Revocation is on the right side. Logging out on a machine forgets the credential there. Revoking in the panel drops that machine on the server, which is what you need when the laptop is gone.
Where the credential lives afterwards
In the operating system's keychain, when there is one. When there is not, in a file with restricted permissions, and it is worth demanding that the tool say it fell back to that. A tool that silently picks the worse place teaches the user to assume it is always the better one.
What deliberately stays out of the terminal
Two things, and the split is on purpose:
Integration credentials. The files describing what the project has connected should be read-only: they say an integration exists and which operations to call, so an assistant can work, and never the secret itself. Connecting and rotating happens on the platform.
Deleting. A file that disappeared from your folder should not disappear from the app. Your local copy may be stale, the AI may have edited the project on the platform meanwhile, and deleting there because of an absence here destroys work. The right behaviour is to report the difference and leave the decision to you.
How to evaluate this in a platform
If you are comparing tools and this kind of access matters, five questions separate them quickly:
- Is the key copied, or born through a device flow?
- Can you ask for read only?
- Does revocation apply server-wide, or does it only forget the key on the machine?
- Does the MCP server expose schema reading, or only write operations?
- What does the publish command do with a file that disappeared?
The answers say more about the tool's maturity than the list of commands does.
At Fabapp
The command line does login through the device flow, keeps the credential in the keychain, accepts
--scopes "read" for a machine that only looks, and brings the project definition down with pull. dev runs the
app locally on the same template used for publishing, and deploy publishes. The MCP server uses the credential
login already stored and respects its permission: a read token does not list the write tools.
Connected machines live under Profile, in Keys and CLI, with each one's permission and last use. Revoking is immediate and applies server-wide.