Reference

The MCP server

Everything the saasie command line does, as tools an assistant can call — including git, so an assistant with no shell can read a repository, commit to it, and deploy.

Saasie is built on the assumption that the caller is usually a code agent. The CLI is the version of that for an agent with a terminal. This is the version for one without: a hosted assistant that can call tools but cannot run a subprocess or write a file.

Adding it

It is a remote MCP server over Streamable HTTP. Wherever your assistant takes a server URL, this is the URL:

https://mcp.saasie.io/mcp

Signing in happens in a browser the first time it connects — the same email-and-code login the CLI uses, rendered as a page. There is nothing to paste and no key to create. The assistant registers itself; you approve it once.

A client that cannot run a browser flow can send a token from saasie token as a bearer credential instead.

What the tools do

The same things the CLI does, against the same control plane, with the same permissions — a tool call is checked against your role on the space that owns the Saasie, exactly as saasie app <name> is. Connecting an assistant grants it what you can do, and revoking it is saasie logout or the client's own disconnect.

Ask the assistant to list them, or read the CLI reference — they correspond one to one, with the exceptions below.

Git, without a shell

This is the part that has no CLI equivalent, because the CLI does not need one: saasie app <name> git get-url prints an address and assumes there is a git to hand it to. A hosted assistant has no git, so the git runs on the server.

• git_list_tree — what is in the repository
• git_read_file — one file, at any branch or commit
• git_log — what has happened to it
• git_diff — what changed between two commits
• git_branches — what exists to read or push to
• git_commit — a set of file changes, committed and pushed in one call

git_commit deploys. It is an ordinary push, so everything that follows a push follows: a push to main builds and goes live at the Saasie's URL, and a push to any other branch deploys a preview with its own URL and leaves production alone. There is no separate deploy step here for the same reason there is not one in the CLI.

The whole change lands in one commit. There is no staging area to build up across calls — MCP has no session to hold one in, and one call per commit is also the unit the platform actually reacts to.

Two things that are not here

Everything an assistant passes to a tool, or gets back from one, ends up in the conversation transcript and in the logs of whoever runs the assistant. Two of the CLI's capabilities move a live credential, so they are not tools.

Setting a secret

There is no secret_set. The CLI already refuses a --value flag — a credential on a command line goes into your shell history — and the same argument is stronger when the value is generated by a model.

The tool is secret_link instead: it returns a one-time URL that sets one secret and can never read the current value. Hand it to whoever actually holds the key. That mechanism was not invented for this — it is what the platform already offers for giving a credential to somebody you would not give access to the Saasie, and an assistant is exactly that.

The database URL

There is no db_get_url. The connection string carries a live password, your application is already given DATABASE_URL in its environment, and there is no tool here that could use one — so it would be a credential in a transcript in exchange for nothing. db_info says which cluster the database is on and as whom it connects; the CLI still prints the URL for a person who wants psql.

Nothing on the platform ever reads a stored secret back, to an assistant or to anyone else. That is not an MCP rule — it is how the secrets battery works everywhere.

Which protocol version

Both eras: the current revision, which negotiates per request, and the older initialize handshake that most clients still use. You should not have to care, and that is the point of serving both.