@stone-js/mcp-dev 0.8.7 → 0.8.8

package/README.md

@@ -38,26 +38,29 @@ import { StoneApp } from '@stone-js/core'
 export class Application {}
 ```
 
-Then start the server from your project:
+### Register it for your agent
+
+One command writes `.mcp.json` for you (create or merge, never clobbering your own config):
 
 ```bash
-stone mcp
+npx stone mcp --init
 ```
 
-`stone mcp` starts an MCP server over **stdio** and keeps running until you press `Ctrl+C`, exactly
-like `stone dev`. It hands the [MCP SDK](https://github.com/modelcontextprotocol) the built-in
-framework-knowledge tools and lets the SDK own the protocol and run the handlers — these are dev and
-knowledge helpers, not your domain, so they do not need to traverse the kernel. Every tool call is
-logged to **stderr** (stdout is reserved for the JSON-RPC protocol) so you watch the agent think in
-real time.
-
-### Register it for your agent
+That is the whole setup: **you never start the server yourself.** It speaks MCP over **stdio**, so the
+transport is the child process's own standard input and output. Your agent reads `.mcp.json`, spawns
+its own `stone mcp` process and performs the handshake; a server you launch in a terminal has no
+channel to your agent and would simply sit there. Restart your agent session after the first
+`--init` so it picks the entry up.
 
-Let `stone mcp` write `.mcp.json` for you (create or merge, never clobbering your own config):
+The command hands the [MCP SDK](https://github.com/modelcontextprotocol) the built-in
+framework-knowledge tools and lets the SDK own the protocol and run the handlers: these are dev and
+knowledge helpers, not your domain, so they do not need to traverse the kernel. Every tool call is
+logged to **stderr** (stdout is reserved for the JSON-RPC protocol), so running `npx stone mcp` in a
+terminal lets you read those logs live. Useful for debugging, never required.
 
-```bash
-stone mcp --init
-```
+> `npx` is used because `@stone-js/cli` is a dev dependency of your project: the bare `stone` command
+> only resolves if you also installed it globally (`npm i -g @stone-js/cli`). Inside a package script
+> the prefix is unnecessary.
 
 Or add the entry yourself (Claude Code, Cursor, Claude Desktop, …):
 
@@ -75,7 +78,6 @@ Or add the entry yourself (Claude Code, Cursor, Claude Desktop, …):
 |---|---|
 | `stone_search` | Search the knowledge base (concepts, modules, best-practices, gaps). |
 | `stone_concept` | Explain a core concept by id (omit id to list them all). |
-| `stone_docs` | Links to the authoritative documentation. |
 | `stone_modules` | The ecosystem modules and what each does. |
 | `stone_best_practices` | Conventions and anti-patterns, each with its rationale. |
 | `stone_gaps` | What the framework does not (yet) provide, and what to reach for. |

package/dist/browser.js

@@ -1,5 +1,20 @@
 import { classDecoratorLegacyWrapper } from '@stone-js/core';
 
+/**
+ * Browser stub of `@McpDev()`: a no-op.
+ *
+ * The dev MCP server (`stone mcp`) is a Node-only, development concern. Stubbing the decorator for
+ * the browser keeps an isomorphic app compiling and inert there, without dragging the CLI command,
+ * the MCP SDK server, or `node:fs` into the browser bundle (which would break a SPA). The real
+ * decorator lives in the Node build.
+ *
+ * @param _options - Ignored in the browser.
+ * @returns A no-op class decorator.
+ */
+const McpDev = (_options = {}) => {
+    return classDecoratorLegacyWrapper((_target, _context) => { });
+};
+
 /**
  * Browser stub of the MCP dev blueprint.
  *
@@ -19,19 +34,4 @@ function defineMcpDev(options = {}) {
     return { stone: { mcpDev: options } };
 }
 
-/**
- * Browser stub of `@McpDev()`: a no-op.
- *
- * The dev MCP server (`stone mcp`) is a Node-only, development concern. Stubbing the decorator for
- * the browser keeps an isomorphic app compiling and inert there, without dragging the CLI command,
- * the MCP SDK server, or `node:fs` into the browser bundle (which would break a SPA). The real
- * decorator lives in the Node build.
- *
- * @param _options - Ignored in the browser.
- * @returns A no-op class decorator.
- */
-const McpDev = (_options = {}) => {
-    return classDecoratorLegacyWrapper((_target, _context) => { });
-};
-
 export { McpDev, defineMcpDev, mcpDevBlueprint };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stone-js/mcp-dev",
-  "version": "0.8.7",
+  "version": "0.8.8",
   "description": "Serve Stone.js's knowledge to your coding agent. A single `stone mcp` command starts an MCP server (stdio) exposing the framework's concepts, modules and best-practices plus your own tools, so the LLM masters the context while you master the domain.",
   "author": "Mr. Stone <evensstone@gmail.com>",
   "license": "MIT",
@@ -47,7 +47,7 @@
     "node": ">=18.17.0"
   },
   "peerDependencies": {
-    "@stone-js/core": "0.8.7"
+    "@stone-js/core": "0.8.8"
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.29.0"

package/skills/stone-js/SKILL.md

@@ -47,7 +47,7 @@ The same class can be served over HTTP, in a Lambda, in the browser, or on the e
 ## Workflow
 
 1. **Before writing code, query the framework.** Call the `stone_search`, `stone_concept`,
-   `stone_modules`, and `stone_docs` MCP tools (served by `stone mcp`) to confirm the current
+   `stone_modules`, and `stone_brief` MCP tools (served by `stone mcp`) to confirm the current
    conventions and the right module for the job, instead of guessing from generic Node knowledge.
 2. **Inspect the app** with `stone_app`, `stone_routes`, `stone_commands`, `stone_adapters`,
    `stone_providers`, `stone_kernel`, and `stone_config` to see what it actually declares.

package/skills/stone-js-adapters/SKILL.md

@@ -53,5 +53,5 @@ platforms, and the environment decides which context applies.
 ## Verify with the MCP tools
 
 Call `stone_adapters` to list registered adapters (platform, alias, default/current) and the active
-platform. Use `stone_app` for a quick summary, and `stone_docs` for the adapter guides. `stone_search`
+platform. Use `stone_app` for a quick summary, and `stone_adapters` for what is registered. `stone_search`
 the knowledge base when picking a target or debugging selection.

package/skills/stone-js-routing/SKILL.md

@@ -57,7 +57,7 @@ class UserController {
 
 After adding routes, call `stone_routes` to confirm the resolved tree (path, methods, name,
 handler, middleware). Use `stone_kernel` to see the middleware pipeline that every route traverses.
-When unsure of an option, `stone_search` the knowledge base or `stone_docs` for the routing guide.
+When unsure of an option, `stone_search` the knowledge base or read `stone_brief` for the full brief.
 
 ## Do not