Build with your own AI agent

Basable has an MCP server. Connect the AI agent you already use, such as Claude Code, Claude in the browser or Cursor, and it can create Basable projects, write their code, build it and deploy it, the same way Basable's own agent does in the editor. Your agent does the thinking; Basable builds, deploys and hosts.

MCP (Model Context Protocol) is the open standard AI clients use to call tools on other services. The client signs in to Basable once, with your consent, and then calls Basable's tools on your behalf.

Before you start

A Basable account in an organisation, created in the web app.
A git connection on that organisation: a GitHub account or organisation, or a Gitea instance, where your projects' repositories live. You set it up once in the web app.

Connecting

The server is at https://basable.com/api/mcp. It speaks streamable HTTP and signs you in with OAuth, so there is no key to copy.

Claude Code

claude mcp add --transport http basable https://basable.com/api/mcp

Then run /mcp in Claude Code and choose to authenticate.

Claude in the browser

Open Settings, then Connectors, add a custom connector, and give it the address https://basable.com/api/mcp. Connect it, and sign in when asked.

Cursor and other clients

{ "mcpServers": { "basable": { "url": "https://basable.com/api/mcp" } } }

Any client that supports remote MCP servers with OAuth works the same way.

Signing in opens a Basable page in your browser. If you are not logged in, you log in first. The page names the app that asks, says where it will send you back, and lists what it may do. Allow it and you are returned to your client; deny it and nothing is connected. An app that asks to send you back to your own computer (a terminal agent does this) is marked as such.

Two ways to work

With a local checkout

For an agent in a terminal. Your agent clones the project's repository, writes and builds the code on your machine with the project's own tools, and pushes to the dev branch with your own git credentials. Every push to dev builds and deploys the preview. The scaffold tools hand it the rendered files to write into the checkout.

Without one

For an agent in the browser, which cannot run code. Your agent sends its changes with verify_build: Basable builds them on a short-lived branch, your agent follows the build with get_build_status, fixes it if it is red, and lands a green build on dev with commit_build. Nothing reaches dev without a green build.

Either way, dev is the preview environment, and promote_to_live takes it to production when you ask your agent to. Before it changes a project, your agent reads get_system_prompt: Basable's rules for a project that builds and deploys (its CI workflow, its Kubernetes manifests, its images, its security settings), the same rules Basable's own agent follows.

The tools

Projects

list_organisations: The organisations you belong to, with your role in each.
list_projects: An organisation's projects and its git connections.
list_connectable_repositories: The existing repositories a git connection can reach.
create_project: Create a project on a new repository or an existing one. Needs permission to manage the organisation's projects.
get_project: A project's state, its repository, and the addresses its preview and live environments are served at.
get_system_prompt: Basable's instructions for building on a project, for writing code or for planning a nanoservice project, and for the way your agent works: in a local clone, or in the browser.

Reading the project

list_files: The repository's files on a branch.
read_file: One file's contents.
regex_search: A regular-expression search across the repository.
list_commits: Recent commits on a branch.
get_workflow_status: Whether a commit's CI run passed, and why not.
get_deployment_status: Where a deployment is, step by step, and what failed.
kubectl: Read-only commands against an environment: get, describe, logs and the like.

Planning and scaffolding

scaffold_project: Render a nanoservice project's skeleton from its plan: as files for your checkout, or into a build.
scaffold_nanoservice: Render one nanoservice from the plan, the same two ways.
check_scaffold: Check a scaffolded project against its plan, with your unpushed changes applied.

Building and committing

commit_docs: Commit documentation (Markdown, docs/) straight to dev.
verify_build: Build code changes on a short-lived branch, or add a fix to one of your builds.
get_build_status: Where a build is: running, green, or red with the end of its log.
commit_build: Land a green build on dev, which deploys the preview.
update_build: Bring a build up to date with dev and build it again.

Deploying

promote_to_live: Merge dev into production and deploy the live environment.
redeploy: Deploy an environment again without a code change.

What it cannot do

Read or set secret values. Secrets are added in the web app; your agent sees only which ones a deployment is waiting for.
Change anything in a cluster: kubectl is read-only, and Secrets show their keys, never their values.
Delete a project, change members or billing, or reach anything an administrator does.
Reach a project in an organisation you are not a member of. Your agent can do what you can do, and nothing more.

What it costs

Your agent's own model is yours: Basable bills no AI tokens for work done through the MCP. A build runs on your git host's runner, like any CI run. Deployments are priced as on the pricing page, the same as projects built in the editor.

Disconnecting

Account Settings in the web app lists every connected app, with when it was last used. Disconnect one and its access ends at once: the next call it makes is refused, and it has to ask you again.