Get started

Introduction

What Fughetta is, the pieces it is made of, and the words the rest of the docs use.

Last updated October 22, 2026

Fughetta is an MCP server for coding agents. It hosts your project's source and gives agents file tools, isolated worldlines with durable receipts, and worker-backed build, test and run. The gateway and source make no model calls of their own; the browser agent sends model requests directly with the user's key.

What an agent can do

Over one MCP endpoint, an agent can:

  • Read and change files: read, write, edit, remove, move, list, glob and search. A write locks the syntax scope it changes; file-level changes lock ::.
  • Recover lost replies: a change sent with an operation_id is recorded durably, and receipt returns its result.
  • Work in isolation: worldline gives each agent its own version history, with scope locks and reverse/redo. Different worldlines do not merge.
  • Start from a template: generate previews templates and can create files in the main worldline when the caller holds ::.
  • Ask about code: language queries analysis bound to a worldline version and an analysis configuration.
  • Build, test and run: the gateway dispatches these to a worker, which executes the selected worldline version.

The MCP tools reference describes every argument and result.

The pieces

Piece What it does
Gateway (gateway) The public entry point: /mcp, the console API, OAuth, configuration and usage. It checks tokens and workspace access.
Source (source) Stores project files, node/worldline state, receipts and blobs. Only the gateway talks to it.
Worker (worker) Syncs a selected worldline version, runs build/test/run, and returns output and diagnostics.
Console The web app for workspaces, projects, settings, usage, history and members.

How it works

  1. An agent sends a JSON-RPC tool call to the gateway's /mcp endpoint with a bearer token.
  2. The gateway checks the token, resolves the workspace and project, and applies the workspace limits and the project's ignored paths.
  3. File and worldline operations go to source, which owns the files, versions, locks and receipts.
  4. A change publishes a new version. If it carried an operation_id, source records the result durably before replying, so receipt can return it after a lost reply.
  5. Build, test and run calls are dispatched from the gateway to a worker for the selected worldline version.
  6. The gateway counts the call for usage and returns the result.

Project files are plain files; worldlines keep isolated histories beside them. The gateway never runs project code and the source never calls a model, so the same input gives the same result.

Words used in these docs

Workspace: a team and its projects. Every tool call names one. A workspace has members and API tokens.

Project: a directory of source inside a workspace. Every tool call names one.

Version: the opaque identity of one worldline state. Reads report it; writes name the version they observed.

Lock: the syntax scope an editor holds before changing it. :: covers file-level changes and code outside any namespace, class or function.

Worldline: an isolated, versioned copy of a project for one agent. See Worldlines.

Language profile: the inputs and language-service command used for analysis of a project. See Project settings.

Where settings live

A project holds its ignored paths, build/run configurations and language profiles. Nothing about code is shared between projects or set for a whole workspace.

A workspace is the team around its projects: its members and the limits its projects share.

Next