The development MCP server

It inspects the workspace, not the running application

The default smrt-dev-mcp stdio server reads source, manifests, and authored documentation from a workspace on disk. It is read-only, never writes files, never executes generated code, and has no access to your application database, principals, or tenants. Level 1 and Level 3 are separate runtime paths; live data operations belong to generated local MCP, hosted application MCP, or WebMCP.

• Application-agent surfaces are generated from your @smrt() objects and perform live data operations.
• Development MCP provides code generation output and project analysis for a coding agent.
• Its review and architecture tools are model-agnostic and call no model provider.
• The standalone install lists all 21 tools but ships no smrt-core. Code generation, the knowledge and context tools, agent skills, and introspection of a built manifest work without a runtime. Source-scan enrichment and the runtime tools need @happyvertical/smrt-core installed in the selected project; without it they return a sanitized runtime_dependency_unavailable diagnostic.
• One server process loads one runtime project. A request for another project fails with runtime_project_mismatch; start a separate server or restart it for that project.

Inspect the complete declared workspace view

A coding agent can inspect project source, runtime manifests, knowledge artifacts, and installed package contracts through structured tools and resources. The results identify packages, objects, fields, relationships, generated interfaces, and authored documentation. Coverage and diagnostics state what the server did not find.

• Source and manifest paths show where each declared object came from.
• Object results include fields, relationships, methods, interface settings, and package identity when the selected evidence contains them.
• Installed package entries include the package version and the hash of its version-matched AGENTS.md.
• Review and architecture bundles carry the same coverage and diagnostics as the underlying index.

Choose the runtime path that fits the question

smrt-dev-mcp has three read-only runtime paths. The normal stdio server reads declared workspace evidence. The Level 1 diagnostics inspect selected framework tables in a development database. Level 2 boots a confined registry over loopback HTTP. Level 3 runs inside a SvelteKit development server and reads that app's live registry.

• Level 1 returns migration, job, schedule, dispatch, change, and registry-drift diagnostics. It never returns payloads, agent configuration, dispatch metadata, database paths, or driver error details.
• Level 2 exposes runtime-registry, runtime-object, runtime-schema-diff, and the six Level 1 diagnostics through a positive, loopback-only catalog. It boots once from project manifests and does not import application code.
• Level 3 adds registry-live inside the app. It is available only in SvelteKit development mode and shares the app root and configured database.
• None of these paths mounts generated CRUD, custom actions, do(), or an application-agent data surface.

Install it and point a client at the stdio server

The package publishes a smrt-dev-mcp binary. For a project-local client, declaring the stdio server in .mcp.json is enough; a compatible client launches it on demand.

{
  "mcpServers": {
    "smrt-dev-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@happyvertical/smrt-dev-mcp"]
    }
  }
}

Prefer an absolute launcher in global configuration

A user-level MCP client can start servers from repositories that do not install this package. A package-manager launcher can run dependency or build-approval checks before the server starts. Install the package in a stable location. Point the client at the built server with an absolute path.

[mcp_servers.smrt-dev-mcp]
command = "node"
args = ["/absolute/path/to/node_modules/@happyvertical/smrt-dev-mcp/dist/index.js"]

Use the current tool names

Tool names are stable strings. Generation and introspection cover the code. The knowledge tools mirror the CLI commands. The context builders return prompt bundles for any model.

• Generation and introspection: generate-smrt-class, introspect-project, review-smrt-project.
• Freshness: check-knowledge-freshness and the current knowledge index.
• build-context takes task: "review" or task: "architecture". It replaces the separate review and architecture builders.
• smrt-review and smrt-architecture remain compatibility names for one minor release and report a deprecated-tool diagnostic.
• Bundled skills: list-agent-skills, get-agent-skill.

Run the confined runtime host when a registry must boot

The Level 2 HTTP host boots manifests in one confined process. It does not import project code. Use it for a sanitized registry snapshot, one object's fields and generated DDL, or a read-only schema comparison.

• The host binds loopback only and requires a bearer token on every request. It uses stateless Streamable HTTP and does not issue MCP session ids.
• Its catalog contains runtime-registry, runtime-object, runtime-schema-diff, and the six Level 1 tools. Restart it after rebuilding manifests.

SMRT_DEV_MCP_TOKEN=local-dev-token smrt-dev-mcp --http --port 3939 --project .

Mount the in-app runtime path only in SvelteKit development

Level 3 uses the app's live ObjectRegistry, so it sees Vite SSR HMR registrations without restarting. Install smrt-dev-mcp as a development dependency and enable the generated route explicitly. The smrt() preset has no option for this route. An application that wants it calls the two public plugins, smrtConsumer() and smrtPlugin(), in place of the preset and passes devPlaneRoute to smrtPlugin.

• GET /api/_dev lists the JSON catalog, GET or POST /api/_dev/<tool> invokes a tool, and POST /api/_dev/mcp serves MCP.
• The route is 404 outside development mode and 503 until SMRT_DEV_MCP_TOKEN is set. It accepts only loopback Host and Origin requests with that bearer token.
• Use smrt dev:runtime <tool> with --url or SMRT_DEV_PLANE_URL to call the in-app route; without a URL it uses the Level 2 boot locally.

smrtPlugin({
  svelteKit: { enabled: true, devPlaneRoute: { enabled: true } }
});

Every tool declares the same result envelope

Each tool publishes an output schema requiring ok, coverage, diagnostics, and data, and returns that object as structured content beside the human-readable text result. data preserves the tool payload unchanged, while coverage and diagnostics are promoted only when the underlying result reports them. A failure returns ok false with an error-severity diagnostic rather than an empty success.

{
  "ok": true,
  "coverage": {
    "workspaceGlobs": ["packages/*", "apps/*"],
    "workspaceGlobSource": "pnpm-workspace.yaml",
    "packageDirs": ["packages/billing", "packages/ui"],
    "packagesWithObjects": ["@acme/billing (7, domain-artifact)"],
    "packagesWithoutObjects": [
      {
        "name": "@acme/ui",
        "reason": "no-smrt-objects-in-sources",
        "checkedPaths": [],
        "remedy": "No @smrt() classes were found in this package. Expected if it is a UI, contract, or tooling package."
      }
    ]
  },
  "diagnostics": [],
  "data": {}
}

Responses are budgeted, and the budget is honest

Knowledge and introspection tools return a summary by default and accept detail full for the complete payload. An introspection response that exceeds its character budget reports a truncated block naming the omitted count and how to filter, rather than being silently cut. Project metadata and diagnostics are always returned in full, because a diagnostic is how discovery reports that it found nothing.

• maxChars overrides the introspection budget and applies to the objects payload.
• Summary architecture and review results list authored docs by path instead of embedding them.
• The equivalent CLI commands request full detail, so their output is unaffected.

Catalogs are cached privately

The static tools and prompts catalogs advertise a one-day private cache lifetime. Workspace knowledge resources are also private, but they use a zero lifetime. The server rebuilds them from the current workspace for every request. The transport has no visible invalidation signal to support a longer lifetime.

An agent workflow from source to runtime evidence

The tools compose into a repeatable loop. Deterministic context comes first, the model reads the actual diff, and the checker runs again after the edits land.

• Run the downstream build or dev server so the domain artifact exists.
• Call introspect-project to establish the declared object and package view.
• Call check-knowledge-freshness before and after edits.
• Call build-context with task review or task architecture and the changed files, scope, and optional package.
• Send the returned prompt bundle to the model of your choice.
• Use runtime-object or runtime-schema-diff only when declared evidence needs a bounded development-runtime check.

Resources, prompts, and the bundled skill

Besides tools, the server exposes the composed project knowledge and package-scoped knowledge as resources, and publishes review and architecture prompts. It also ships one harness-agnostic agent skill, smrt-code-review, which get-agent-skill returns as Markdown with YAML frontmatter that skill-unaware harnesses can ignore.