The development MCP server

It inspects the workspace, not the running application

smrt-dev-mcp is the Development MCP server. It 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. 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.

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.

Runtime awareness is a separate, optional bridge

The released development server does not connect to a running application or inspect its live ObjectRegistry. A future or application-provided connection can expose bounded runtime capability metadata beside the declared workspace view. Callers must discover that bridge before they use it.

• Without a runtime bridge, the server remains fully useful and deterministic from source, manifests, generated knowledge, and installed package contracts.
• A runtime bridge should label observed facts separately from declared facts and expose capability metadata rather than application records or credentials.
• Live data operations remain on an application-agent surface and still resolve through principals, tenants, and policy.

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"]

Fifteen tools in six groups

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.
• Knowledge reflection: reflect-knowledge, reflect-domain-knowledge.
• Freshness: check-knowledge-freshness, check-domain-knowledge.
• Review context: build-review-context, build-domain-review-context, smrt-review.
• Architecture context: build-architecture-context, build-domain-architecture-context, smrt-architecture.
• Bundled skills: list-agent-skills, get-agent-skill.

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.

A downstream review workflow

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 reflect-domain-knowledge to confirm package and SDK coverage.
• Call build-domain-review-context or smrt-review with the changed files, scope, and optional package.
• Send the returned prompt bundle to the model of your choice.
• Re-run check-domain-knowledge after the edits.

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.