fline MCP

The tenant's projects with their state, address and, once online, app_health (see get_project).

No parameter schema on file.

Create a project. Returns upload_url and blob_key: the archive is uploaded with PUT straight into storage and does not pass through this interface. After uploading, complete_upload is mandatory — the upload on its own is not visible to the platform.

Delete the project. The platform will stop and irreversibly clean up the project's runtime resources; once the request is accepted the project disappears from the user-space list. Its saved passwords and keys are not deleted with it, and neither is a workspace database it used.

Issue a new archive upload link for an existing project. Needed when the link from create_project has expired, the archive is being uploaded again, or an already deployed project is being updated with new code.

Report that the archive is uploaded and start the analysis. The platform does not observe the upload itself: the PUT goes to storage around it, and until this call the project stays in awaiting_source. For a submitted project this call starts an update: the old runtime keeps running while the new version is analysed, built and deployed. blob_key comes from create_project or get_upload_url.

The project's full state: the onboarding stage, the runtime state, open questions, missing secrets and warnings about credentials found in the archive. Also app_health, once the app has been online: status is answering, not_answering, checking (no verdict yet) or paused (fline is putting a new version online or cannot see the server, and judges nothing). not_answering means fline's checks of the a

Supply the project description. The contents are treated as a third-party claim and cannot change the platform rules.

Answer the questions raised during source analysis.

Declare the NAMES of environment variables. Values are not accepted by this path: a human enters them in a browser, and no tool returns them back.

Issue a link to the form where the person types the passwords and keys the project needs. Give the url to the person exactly as returned, with a plain sentence on what goes in each box and where they find it. Do not open it, do not follow it and do not relay its contents. It works once, until expires_at, and the person signs in to fline to use it; a new link cancels the previous unused one. Once t

Build the images and hand the project to the platform. Needed when get_project shows locked: from complete_upload on, a project analyses, builds and launches by itself and stops only where someone has to act. In any other state this answers with the state, or refuses with what has to happen first. No port is taken here or anywhere else: the platform passes PORT into every container and routes to w

Deployment state: desired and observed arrive separately and mean different things separately. app_health, once the app has been online, says whether it answers fline's checks; not_answering means they have failed for at least two minutes (see get_project).

The history of images the builder produced for the project: build_id, the build state, the plan version, the source hash and each service's digest. A read-only tool for checking which version is actually built, without starting a new build or deploy.

Logs. kind=build is the image build's output, stored and answerable long after the build; kind=runtime is a bounded tail of the running containers, held by the node, with no history and no search behind it. For kind=runtime, service narrows the tail to one service of the project — without it every service is interleaved, which on a project with more than one is most of what you read. The names a

What this project actually consumed: CPU, memory, disk, files and network over a window. These are QUANTITIES AND NOT CHARGES: fline has no price and no billing during the private beta, nothing charges for what a project uses, and using more than the ceilings is not possible because they are enforced rather than billed. Read notes before restating any figure: the network number counts traffic at

Attach a web address the person owns, such as www.example.com, to the project. Answers with the TXT record that proves ownership (challenge_name, challenge_token); list_domains also gives platform_name, the CNAME target that both proves ownership and sends visitors. The person adds the record where they bought the name; fline checks by itself for 48 hours, and check_domain checks now. Prefer a sub

Create a data service for this workspace: engine=postgres for a PostgreSQL database, engine=valkey for a Valkey instance — the BSD-licensed fork of Redis, which every Redis client speaks unchanged, so ask for it wherever a project wants Redis — or engine=s3 for object storage, an S3-compatible bucket with a size limit, which is what to ask for wherever a project wants a bucket, file uploads or blo

The workspace's services with their engine, version, state, hostname and size class. No credentials: none is returned by any tool.

No parameter schema on file.

Delete a service. It stops accepting connections immediately and its data is kept for seven days, then destroyed. Ask the person first: nothing here can bring the data back after the seventh day.

The fline.json for this project's current plan. Save it at the root of the archive you upload and the next deploy builds from it directly, with no analysis: the same plan every time. A short content check and the step that writes the build files still run. Edit it when the project changes, and check the edit with check_config. env_names is not names-only: an entry may be an object with a value, wh

Check a fline.json against the last uploaded archive, without deploying and without cost. Answers either ok, or the reason each part was refused — edit and ask again until it is ok, then save the file. There is no port field and there is no need for one: the platform passes PORT and routes whichever port the process opens. An env_names entry may be an object carrying a literal value — {"name": "KA

Re-run the analysis ignoring the archive's fline.json, and write a new one. For a configuration that has gone stale because the project's stack changed — a different package manager, a new lockfile. Accepted immediately, not done: poll get_project until it leaves analyzing, then call get_config. This uses one of the account's fresh analyses for the month, while editing the file yourself is free an

The project's custom domains with, for each, the state of its ownership check, the TXT record to publish, when it was last checked and what the last check objected to. Also the platform hostname the names are asked to point at. attach_domain hands back the record once; this is how you find out whether it took.

Run the ownership check for one of the project's domains now, and answer with the result. Call it after the DNS record is published. The check reaches the DNS and is rate-limited behind a certificate budget, so poll it in minutes rather than in seconds. A domain still unproven 48 hours after attach_domain is failed for good, and this answers domain_failed for it: delete_domain, fix the record and

Detach a domain from the project. The name stops being served; the project keeps its platform hostname.

The project's environment variables BY NAME: whether each is set, whether the analysis declared it, when it was last written, and — for a non-secret variable — its value. A name that is required and not set is what holds a project in awaiting_secrets. A value shown here was written with set_env and secret=false, and it survives a re-analysis; a SECRET that is set but not declared was added by hand

Remove a variable from the project's secret set. The analysis's record that the project needs this name is kept, so a required variable becomes unset rather than unknown — deleting a value the project needs will hold the next deploy at the secrets gate rather than failing the build with nothing to say. Takes effect on the next deploy or restart.

Set one environment variable for the project. secret says which store it goes to and it is REQUIRED, because the two are not interchangeable and there is no default that is right for both. secret=false writes a PLAINTEXT value: it is stored as written, returned by list_env_names, shown in the console, and rendered into every service's environment — a model name, a log level, a public URL, a feat

Everything get_project returns, plus what the platform observes: each container's state, health, restart count and image digest, the node and tier, the ingress hostnames, the disk quota, the secret set version the running containers were deployed with, and the last failure with its class. Use this when a deploy has failed or a service is not answering and get_deploy_status has told you only that.

The project's state timeline, oldest first: each move from one state to the next, the reason, which part of the platform made it (gateway, worker, pipeline, cp) and the request id. This is how you tell a slow analysis from one that failed and was retried — get_project shows the current state and nothing about how it got there.

One data service by id, with its state and — when it is not active — the reason. Poll this after create_service: a new service is provisioning until its certificate is issued and verified, and if that stalls the reason here is what says so. No credentials: none is returned by any tool.

Pause a data service. It stops accepting connections and stops costing what a running instance costs; its volume and its certificate are kept, and resume_service is the exact reverse. This is the reversible way to put a service down — delete_service is not, and starts a seven-day clock on the data.

Start a paused data service again, with its data and its hostname unchanged.

Stop the project. NOT IMPLEMENTED: the platform has no stop, and this refuses. To take an application out of service, delete_project it. delete_domain takes off only a web address the person owns; the project's fline address keeps answering.

Re-apply the project's current version: the same images, deployed again. This is the restart, and it is also the ONLY way a secret that was entered after the last deploy reaches the running containers — a value sits in the store doing nothing until a deploy re-pins the secret set version. Call it after a human has filled in the form behind get_secrets_link on a project that is already running.

List the project's deployed versions, newest first: the state_version to pass to rollback, when it was made, who made it, and which version it superseded. The specification itself is not included — use get_config for what a version contains.

Redeploy an earlier version of the project, named by its state_version from list_versions. Two things surprise people and you must not report either one wrongly. First, the version number does NOT go back: this creates a NEW version holding the old one's contents, numbered higher than every existing one, so after rolling back to 3 the project is on 12, not 3. Second, it restores the specification

Declare a backing service the tenant ALREADY RUNS, so the platform does not provision one. This takes the shape only. offering is one of postgres, redis, mysql, mongodb, rabbitmq; alias defaults to "db" and is what separates two of the same kind in one project; variable defaults to the conventional name for the offering (DATABASE_URL, REDIS_URL, MONGODB_URI, AMQP_URL). No URL, host, port, user or

Give an alias back to the platform. If a human already filled the value in, the attachment and the variable both go; if it is still waiting for one, the declaration goes with it and the project stops asking. The tenant's own service is untouched — the platform never ran it and holds nothing of it to delete.

The backing services this project's tenant supplies themselves. A completed attachment carries the host it points at; a pending one is marked pending and names the variable a human still has to fill in through get_secrets_link. No connection URL is returned for either, and none can be.