Mochi: a statically typed language for agent and dataset work

The gap Mochi is aimed at

Most languages used for agent work were not designed for it. You write Python or TypeScript, pull in a dataframe library, a graph library, and an MCP wrapper, and spend the first day of a project wiring them together. Mochi's claim is that the data layer belongs in the language. The README describes it as a small, statically typed language built for clarity, safety, and expressiveness, and lists agent-friendliness, declarative functional syntax, a zero-dependency single binary, and built-in `test` and `expect` blocks as the properties it is optimising for. The repository topics (agent, ai, graph, leetcode, stream) match that framing rather than contradicting it. The intended user is someone writing a tool, a data pipeline, or an agent skill who wants the query syntax and the test syntax to be part of the grammar instead of a library import. That is a narrower audience than a general-purpose language launch, and the README does not pretend otherwise.

Bytecode VM, constant folding, and what the CLI actually is

The architecture visible in the material is a bytecode virtual machine compiled into the `mochi` CLI itself. The README states that Mochi is optimised via constant folding and liveness-based dead code elimination, which places the optimiser at the bytecode level rather than in a separate ahead-of-time compiler pass. `mochi run` executes a source file against that embedded VM. There is a separate `mochi build` command that compiles to a binary or to other languages, with the README showing `mochi build --target python examples/hello.mochi -o hello.py` as the example. So the execution model has two paths: interpret through the VM, or emit a target artefact. The repository also ships a `tools/vmreport` tool, built with `CGO_ENABLED=0 go build -o vmreport ./tools/vmreport`, which the README describes as optional and free of heavy CGO dependencies. That tool exists to inspect VM output, which suggests the VM is meant to be observable rather than opaque. The primary implementation language is Scheme according to the repository metadata, while the CLI, the language server, and `vmreport` are built with Go commands. That split is worth noting: the front end and the tooling are not written in the same language, so a contributor fixing a parser bug and a contributor fixing an editor bug will be working in different codebases.

Datasets, streams, and the SQL-like query block

The most distinctive part of the language is the dataset query syntax. The README gives this form: `from p in people where p.age >= 18 select { name: p.name, age: p.age }`, with `sort by`, `skip`, and `take` listed as additional clauses. Datasets can be loaded from external files, shown as `let people = load "people.yaml" as Person` against a declared `type Person { name: string, age: int }`. The result is a value you can iterate with a normal `for` loop, and the README shows `save` as the write-side counterpart, though the excerpt cuts off mid-statement. This is the design choice that separates Mochi from a language that merely has a collection library: the query is syntax, so the compiler can see the shape of the filter and the projection. Strings are treated as read-only lists of characters and can be indexed and iterated like a list, which the README demonstrates with `text[1]` returning `"e"`. Immutability is the default: `let` binds, `var` mutates. Function values are supported, including the arrow form `let square = fun(x: int): int => x * x`. None of this is unusual on its own. The combination of a typed record declaration, a `load ... as` binding, and a `from`/`where`/`select` block inside the grammar is what makes the data path shorter than the equivalent in a host language.

Getting a binary and running the first file

Three install paths are documented. The prebuilt route is a download from the releases page followed by `chmod +x mochi` and `mochi run examples/hello.mochi`. The Docker route is `docker run -i --rm ghcr.io/mochilang/mochi run examples/hello.mochi`, with an alias suggested for interactive use: `alias mochi="docker run -i --rm -v $PWD:/app -w /app ghcr.io/mochilang/mochi"`. The source route is `git clone https://github.com/mochilang/mochi`, then `make install` (which the README says installs Deno for the TypeScript tests), `make build`, and `make test`, with `mochi` landing in `~/bin`. The CLI surface is `run`, `test`, `build`, `init`, `get`, `repl`, `llm`, `infer`, `serve`, and `cheatsheet`. Two of those deserve attention. `mochi infer go fmt` is described as inferring externs from a package, which is the mechanism for calling into an existing Go package from Mochi. `mochi cheatsheet` prints a language reference from the binary itself, so the reference ships with the tool rather than with the documentation site. For editor support, the README points at `tools/vscode`, built with `npm install` and `npm run package` to produce `mochi.vsix`, and at a separate language server built with `go build ./cmd/mochi-lsp` and placed on `PATH`. The VS Code extension launches the server automatically when it is available.

MCP server mode and the LLM configuration keys

Mochi can run as an MCP server, which is the feature most likely to bring people to the repository. For VS Code agent mode, the README gives a `.vscode/mcp.json` file with a `servers` object whose `mochi` entry runs the Docker image with `-i --rm`. The same block can go into user settings under an `mcp` key. For Claude Desktop, the config uses `mcpServers` and can pass environment variables: `MOCHI_AGENT` set to `Claude`, `LLM_PROVIDER` set to `llama.cpp`, `LLM_DSN` set to `http://localhost:11434/v1`, and `LLM_MODEL` set to a quantised GGUF filename. The native alternative is a `command` pointing at the binary with `args: ["serve"]`. The prerequisites section is explicit that using Mochi inside tools like Claude or VS Code Agent Mode may require a local LLM such as `llama.cpp`, and that container-based commands need Docker running. Two things are left open in the material. The README says to add inputs or environment variables as needed for LLM tools or runtime settings but does not enumerate them beyond the four keys above. And the `LLM_DSN` example points at port 11434, which is the Ollama default port, while `LLM_PROVIDER` is set to `llama.cpp`. That is either a deliberate compatibility shim or a copy-paste slip; the README does not say which, and it is the kind of detail you would want to confirm before building a config around it.

Where the documentation runs out

The README is a tour, not a reference. It covers variables, control flow, functions, collections, strings, and dataset queries, and then stops. Error handling is not described in the supplied material at all: there is no example of catching a failure from `load`, no discussion of what happens when a YAML file does not match the declared `type`, and no mention of an exception or result type. Module dependencies are implied by `mochi init mymodule` and `mochi get`, but the README does not show a manifest format, a registry, or a version constraint syntax. The `infer` command is documented by one example line with no explanation of how it maps Go types onto Mochi types or what happens when it cannot. The `build --target python` path is shown once, with no list of supported targets. For a language at v0.16.0, that thinness is expected, and the release cadence (three releases in the five days before the last push) suggests the surface is still moving. The practical consequence is that anything beyond the README's examples will require reading the source, and the source is split across Scheme and Go. The `cheatsheet` command is the intended mitigation, since it prints the language reference from the binary you already have, but the README does not show its output, so its coverage cannot be judged from the material here.

What you give up compared with Python plus pandas

The obvious alternative for this work is Python with a dataframe library and a separate MCP wrapper. The difference in approach is where the query lives. In Mochi, `from p in people where p.age >= 18 select { ... }` is parsed by the compiler, and the declared `type Person` gives the field names and types before the file is read. In Python, the equivalent is a runtime call into a library, and the schema is whatever the file happens to contain until you validate it yourself. Mochi trades ecosystem for that. Python has plotting, HTTP clients, database drivers, and a decade of agent frameworks; Mochi has `mochi infer` for reaching into Go packages and not much else that the README documents. The other trade-off is the embedding story. Mochi is described as embeddable, and the VM lives in the CLI, but the README does not show an embedding API for a host program, so the practical form of embedding today appears to be running the binary or driving the MCP server rather than linking a library. If your work is mostly string manipulation and API calls with a small amount of tabular data, Python is the lower-friction choice and Mochi's query syntax buys you little. If your work is mostly typed record transforms over files, the grammar does more of the work for you.

Licence, releases, and what to check before committing

Mochi is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is the permissive end of the spectrum and imposes no copyleft obligation on code you write in Mochi or on a host program that calls it. This is a description of the licence text, not legal advice; if you are redistributing the binary or embedding it in a product, read the LICENSE file in the repository rather than this summary. On maintenance cost, the material shows an active project: v0.14.0, v0.15.0, and v0.16.0 landed within six days of each other in late May and early June 2026, and the repository is not archived. That cadence cuts both ways. You get fixes quickly, and you also get language changes between minor versions at a point where the documentation has not caught up. The upgrade surface to watch is the CLI command set and the MCP config keys, since those are the parts your tooling will hard-code. Before adopting, confirm three things in your own environment: that a prebuilt binary exists for your platform in the releases page, since the fallback is a Go and Deno build toolchain; that `mochi test` runs your own `test` and `expect` blocks, not just the bundled `examples/leetcode/...` suite; and that `mochi build --target python` produces output you would actually ship, because the README shows the command but not the generated code.

Editorial conclusion

Adopt Mochi if you want a small statically typed language that speaks MCP and has SQL-like dataset queries built into the syntax, and if you are willing to read the source when the README runs out. Do not adopt it if you need a mature package ecosystem, stable language semantics, or documentation that covers error handling before you ship. Verify first that the prebuilt binary for your platform exists in the releases page, that `mochi test` passes on your own examples rather than only the bundled ones, and that your MCP client accepts the `docker run -i --rm ghcr.io/mochilang/mochi` form shown in the README.

Official sources

1. License: MIT
2. mochilang/mochi on GitHub
3. Project website
4. README
5. Releases