A coding agent is only as good as its context. Point it at a fresh Stone.js codebase and it guesses: wrong decorators, stale APIs, routes it cannot see. Stone.js ships the fix as one command, stone mcp: it hands your agent the framework’s knowledge and a live view of your own app, so it stops guessing.

Two agents, and the one that needs help

There are two agents in the room. One calls your app at run time; that is a run-time context (coming as a capability). The other builds your app with you, in your editor, and it needs to understand Stone.js and this codebase. @stone-js/mcp-dev serves that second agent.

stone mcpMCP server (stdio)Framework knowledgestone_search · stone_docsThis appstone_routes · stone_configYour toolsproject_notes · …
One `stone mcp` server feeds the coding agent three streams: the framework’s knowledge, a read-only view of this app, and the tools you declare.

One command

Add @McpDev() to your app, then run stone mcp. It starts an MCP server over stdio and stops on Ctrl+C, exactly like stone dev. The MCP SDK owns the protocol and runs the handlers in-process, so these dev helpers never touch your domain or the kernel.

app/Application.tsts
import { McpDev } from '@stone-js/mcp-dev'
import { Routing } from '@stone-js/router'
import { NodeHttp } from '@stone-js/node-http-adapter'
import { StoneApp } from '@stone-js/core'

@McpDev()   // adds the `stone mcp` command
@Routing()
@NodeHttp({ default: true })
@StoneApp({ name: 'my-app' })
export class Application {}

It reads your app, not just the framework

This is the difference. Beyond framework knowledge, stone mcp exposes read-only tools built from your resolved blueprint, so the agent sees what this app declares and answers from fact instead of guesswork. Secrets are redacted.

agent sessiontext
agent -> tools/list
stone <- stone_routes · stone_app · stone_config · project_notes · stone_search
agent -> stone_routes
stone <- GET /tasks (Tasks.list) · POST /tasks (Tasks.create)
agent -> stone_search { query: "how do adapters collapse at runtime" }
stone <- the runtime collapse selects one adapter per invocation …

Register it, and add your own tools

Let the command write .mcp.json so your editor’s agent discovers the server; it merges and never clobbers your config. Declare project-specific tools under stone.mcpDev, and copy the bundled Agent Skills into your agent’s skills directory to teach it the conventions.

terminalbash
stone mcp --init   # create/merge .mcp.json
mkdir -p .claude/skills && cp -R node_modules/@stone-js/mcp-dev/skills/stone-js* .claude/skills/

Why it matters

  • No more guessing. The agent queries concepts, modules and your real routes live, instead of hallucinating from stale training.
  • Grounded in your app. Introspection reads the one blueprint the framework itself uses, so what the agent sees is what actually runs.
  • Zero ceremony. One decorator, one command, logs on stderr so you watch the agent think. It stops with Ctrl+C.

The full tool list and options are in the MCP dev server docs. Exposing your running domain to agents as tools is a separate, upcoming capability: the same domain, one more context.