Built by your AI. Running on Ulabase.
An AI that has to guess at your backend writes code you then have to debug. On Ulabase it reads the real documentation, configures the backend itself, and works on your service within the role you give it.
1. It reads the documentation
Over our public MCP server, so it knows the real API, the permissions and the kit, as they are today.
It needs: Nothing: no account and no token.
2. It configures your backend
It writes ulabase.setup.ts, with the collections, the indexes, the permissions and the features your app needs, and applies it with ulabase setup.
It needs: A personal access token of yours, given once to ulabase login.
3. It works on your service
Connected over MCP to the service itself, it reads and writes your data, and creates collections, indexes and the rest, as far as its role allows.
It needs: An API key for a user of the service, with the role you chose.
1. Give it the documentation
One MCP server, the same for every project.
One command in your project
claude mcp add --transport http ulabase-docs https://api.bysophia.ai/mcp/ulabaseNo account and no token: the documentation is public.
2. Let it configure the backend
The configuration of a service is a file in your repository. The assistant writes it, you read it, and one command applies it: collections, indexes, permissions, features and their settings. Run it again and it changes only what is missing.
npm install -g ulabase
ulabase login
ulabase setup --srv c0ffee --dry-run
ulabase setup --srv c0ffee--dry-run says what the service is missing and changes nothing: let the assistant run that first. The ulabase command line.
3. Connect it to your service
Every service has an MCP endpoint of its own: the one that gives the agents of your app their tools. The same endpoint serves the assistant that builds the app. It signs in as a user of the service and gets what that user's role allows over REST, no more: reading and writing data, and, when the permission says so, creating collections, indexes and the rest of the configuration.
claude mcp add --transport http my-service https://c0ffee.ulabase.app/mcp \
--header "Authorization: Bearer ulak_..."The MCP page of your service has the endpoint, the key and the snippet for your client. MCP server.
What changes in the session
Without it
- You ask for a product catalogue with search
- The assistant invents a backend shape and writes boilerplate for it
- You debug code neither of you meant to write
- You paste the real API in and explain it
- Repeat
With it
- You ask for the same thing, on Ulabase
- It looks up how collections, permissions and search actually work
- It writes the setup file and applies it: the backend exists
- It writes the frontend against the API that now exists, and checks the data over MCP
- You read it once and move on
What it can look up
Retrieved from the current documentation when it asks, not remembered from training a year ago.
- Every REST path a collection exposes, and the query, sort and page parameters that go with it
- How permissions are written, so the ACL documents it generates are the ones you meant
- The kit: useAuth(), usePayments(), and which package your framework needs
- Aggregations, change streams, GraphQL apps, webhooks — the shapes, not a guess at them
- What each plan costs and what runs on the Free tier
You decide how far it goes
The documentation server has no route to your service. The setup file is in your repository, and nothing is applied until the command runs with your token. On the service, the assistant is a user like any other: give it a user and a role of its own, and its permissions are the only thing it can do. An assistant that signs in as the administrator can do what the administrator can.