Frontier

Agent-native patterns

Exposing your app to agents is one adapter, as the contexts section showed. Designing an app agents use well is a craft. This is where the framework's bet on agents as a first-class runtime turns into concrete practice.

#Tools are intentions with names

The principle

A reasoning system chooses a tool by its name and description, not by reading your code. So the unit of design is the intention: a verb, a clear contract, a predictable result. Handlers that already read as intentions make excellent tools.

In Stone.js

When the runtime agent context ships, well-named handlers become MCP tools directly, no rewrite. The work is naming and scoping them now: task.create beats doStuff, and a tight schema tells the model exactly what to pass.

app/Tasks.tsts

@Post('/', { name: 'task.create', middleware: [validate({ body: NewTask })] })
create (event) { return this.store.add(event.get('body')) }
// as a tool: name = "task.create", args validated by NewTask, result = the task

#Give agents a contract to read

An agent that can read your contract guesses less and fails less. You already produce one: the OpenAPI document derived from your schemas is a machine-readable description of every intention your app accepts.

#Teach the coding agent, too

There are two agents in the room. The runtime agent calls your app; the coding agent builds with the framework. The second one needs to understand Stone.js itself.

@stone-js/mcp-dev: stone mcp serves the framework and your app to a coding assistant, so it queries concepts, modules, routes and config live instead of scanning packages.
llms.txt: a machine-readable map of these docs, served at the site root, so any model can load the whole mental model at once.

terminalbash

curl https://stonejs.dev/llms.txt   # the docs, as a map a model can read

The model masters the context. You master the domain. Together, you ship.