MCP Architector

 

Model Context Protocol (MCP) server for architecture and system design

Local-first MCP server that stores and manages project architecture information. All data is stored locally in ~/.mcp-architector for maximum privacy and confidentiality.

📦 Install: npm install -g mcp-architector or use via npx 🌐 npm: https://www.npmjs.com/package/mcp-architector 🔗 GitHub: https://github.com/theSharque/mcp-architect

How to connect to Claude Desktop / IDE

Add the server to your MCP config. Example for claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "architector": {
      "command": "npx",
      "args": ["-y", "mcp-architector"],
      "env": {
        "MCP_PROJECT_ID": "${workspaceFolder}"
      }
    }
  }
}

For Cursor IDE: Settings → Features → Model Context Protocol → Edit Config, then add the same block inside mcpServers. See the Integration section for more options.

Cursor rule (recommended)

For Cursor IDE and Cursor Cloud Agents, use a phased onboarding rule so the agent does not dump the whole repo into context in one shot.

1. Copy .cursor/rules/architector-onboarding.mdc into your project (the repo you are documenting):

   mkdir -p /path/to/your-app/.cursor/rules
   cp /path/to/mcp-architector/.cursor/rules/architector-onboarding.mdc /path/to/your-app/.cursor/rules/

1. Ensure MCP Architector is configured with MCP_PROJECT_ID pointing at that workspace (see How to connect).

1. Ask in chat, for example: "Onboard this repo into architector — phase 0 plan first" or "Import architecture module by module".

The rule is alwaysApply: false — Cursor attaches it when the task matches architecture import/onboarding. It enforces: structure → one module per step → validate after each step → compact tools only.

If you develop this server repo, keep the same file here so contributors and Cloud Agents follow the same workflow when updating ~/.mcp-architector/_qs_mcp-architector/.

Overview

Store and manage project architecture, modules, scripts, data flow, and usage examples - all locally with complete privacy.

Features

• Local Storage: All data stored in ~/.mcp-architector (privacy-first)
• Project Architecture: Store and retrieve overall project architecture
• Module Details: Detailed information about each module
• Resources: Access architecture data via resources

Storage Structure

~/.mcp-architector/
└── {projectId}/
    ├── architecture.json      # Modules + dataFlow (vertical structure)
    ├── modules/
    │   ├── {moduleId}.json
    │   └── ...
    ├── entries/
    │   ├── index.json         # Catalog (no duplicate bodies)
    │   └── {entryId}.json     # Canonical facts (API, domain, flows, …)
    ├── slices/
    │   └── {sliceId}.json     # Custom filters only (no items)

Data model

| Layer | Purpose | Tools | |-------|---------|-------| | Modules | Vertical structure: components, dependencies, dataFlow | set-project-architecture, set-module-details, set-module-data-flow, rebuild-data-flow, validate-architecture | | Entries | Single source of truth for horizontal facts (one fact = one file) | set-entry, set-entries, get-entry, list-entries | | Slices | Read-only views over entries (built-in or custom filters) | list-slices, get-slice |

Anti-patterns (no duplication): Do not copy module.description into entry.summary. Link with refs.moduleName. Slices never store item copies—only filters in slices/*.json.

Do not edit ~/.mcp-architector directly — always use MCP tools so timestamps, merge semantics, and dataFlow inverse sync stay consistent.

Agent workflow

1. list-projects — confirm projectId if data looks empty or wrong.
2. Structure task → get-project-architecture / set-project-architecture.
3. Each module → set-module-details with files + facts[] (endpoints, entities, glossary) in the same call, or set-entries / set-entry with refs.moduleName.
4. Single module graph edge → set-module-data-flow.
5. Bulk rebuild flow (many modules) → rebuild-data-flow.
6. After edits, verify everything → validate (summary + issues[]; no full project load).
7. Need a category (all APIs, all domain terms) → list-slices → get-slice with format=compact or table; use offset when hasMore is true.
8. Find by name → search-entries → get-entry for full payload.
9. After code refactor (same modules) → refactor-architecture: scan → dryRun preview → apply with confirm=true.

| Scenario | Tool | |----------|------| | Update one module + its APIs/facts | set-module-details with facts[] | | Bulk facts for a domain | set-entries with moduleName | | Patch dataFlow for one module | set-module-data-flow | | Rebuild all module edges | rebuild-data-flow | | Diagnose graph + empty slices | validate (or validate-architecture) | | Sync paths/names after refactor | refactor-architecture (dryRun, then confirm) | | Index out of sync | rebuild-entry-index | | Create project from scratch | set-project-architecture with replaceModules: true | | Onboard a fresh git clone (phased) | Copy .cursor/rules/architector-onboarding.mdc → ask agent to onboard phase by phase |

Full project picture: modules alone do not populate slices — without http-endpoint (and other kinds) entries, slice api stays empty. New module → add facts or entries in the same step.

Example: set-module-details with facts: [{ kind: "http-endpoint", title: "POST /orders", ... }], then get-slice sliceId=api format=table.

Quick Start

For Users (using npm package)

# No installation needed - use directly in Cursor/Claude Desktop
# Just configure it as described in Integration section below

For Developers

1. Clone the repository:

git clone https://github.com/theSharque/mcp-architect.git
cd mcp-architect

1. Install dependencies:

npm install

1. Build the project:

npm run build

Usage

Development Mode

Run with hot reload: ``bash npm run dev ``

Production Mode

Start the server: ``bash npm start ``

MCP Inspector

Debug and test your server with the MCP Inspector: ``bash npm run inspector ``

Integration

Cursor IDE

1. Open Cursor Settings → Features → Model Context Protocol
2. Click "Edit Config" button
3. Add one of the configurations below

Option 1: Via npm (Recommended)

Installs from npm registry automatically:

{
  "mcpServers": {
    "architector": {
      "command": "npx",
      "args": ["-y", "mcp-architector"],
      "env": {
        "MCP_PROJECT_ID": "${workspaceFolder}"
      }
    }
  }
}

Option 2: Via npm link (Development)

For local development with live changes:

{
  "mcpServers": {
    "architector": {
      "command": "mcp-architector",
      "env": {
        "MCP_PROJECT_ID": "${workspaceFolder}"
      }
    }
  }
}

Requires: cd /path/to/mcp-architector && npm link -g

Option 3: Direct path

{
  "mcpServers": {
    "architector": {
      "command": "node",
      "args": ["/path/to/mcp-architector/dist/index.js"],
      "env": {
        "MCP_PROJECT_ID": "${workspaceFolder}"
      }
    }
  }
}

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "architector": {
      "command": "npx",
      "args": ["-y", "mcp-architector"],
      "env": {
        "MCP_PROJECT_ID": "${workspaceFolder}"
      }
    }
  }
}

Continue.dev

Edit .continue/config.json:

{
  "mcpServers": {
    "architector": {
      "command": "npx",
      "args": ["-y", "mcp-architector"],
      "env": {
        "MCP_PROJECT_ID": "${workspaceFolder}"
      }
    }
  }
}

Using Project ID

When calling tools, you can:

1. Use automatic project ID (from ${workspaceFolder} env var): Just omit the projectId parameter
2. Override per call: Pass projectId explicitly in the tool call
3. Use default: If neither is provided, uses "default-project"

Tools

set-project-architecture

Creates or updates the overall architecture for a project. By default merges modules and dataFlow by name; omit dataFlow to preserve existing flow. dependsOn is canonical; providesTo is recomputed on save.

Input:

• projectId (optional): Project ID (defaults to "default-project")
• description: Overall project description
• modules: Array of module objects with:
• name: Module name
• description: Brief description of the module
• inputs (optional): What this module requires to work
• outputs (optional): What this module produces or generates
• dataFlow (optional): Object describing data flow between modules (omit to keep existing):
• Key: module name
• Value: object with:
• dependsOn (optional): Array of module names this module depends on
• providesTo (optional): Derived on save from all dependsOn edges
• dataTransformation (optional): How data is transformed between modules
• replaceModules (optional): Replace entire modules list (default false = merge by name)
• replaceDataFlow (optional): Replace entire dataFlow (default false = merge by module name)

Output:

• Project ID and success message

get-project-architecture

Retrieves the overall architecture of the project.

Input:

• projectId (optional): Project ID (defaults to "default-project")

Output:

• Complete project architecture

list-projects

Lists all projects in local storage (~/.mcp-architector). Use when the workspace may map to a different normalized projectId.

Input:

• query (optional): Filter by substring in projectId or description (case-insensitive)

Output:

• Array of project summaries: projectId, description, moduleCount, updatedAt, isCurrent (matches current MCP_PROJECT_ID)

Entries and slices

| Tool | Purpose | |------|---------| | set-entry | Upsert one fact; response may include reminder if modules missing or unlinked | | set-entries | Bulk upsert (max 200); optional moduleName sets refs.moduleName on all | | get-entry | Full entry by id | | delete-entry | Remove entry | | list-entries | Catalog without payload; filter by kind, tags, query | | search-entries | Compact text search with snippet, slices, moduleName, pagination; filters: moduleName, kind, tags | | list-slices | Built-in + custom slices with entry counts | | get-slice | Filtered view: sliceId, format, query, limit, offset, hasMore | | set-slice | Save custom filter (kinds, tags) — no items | | delete-slice | Remove custom slice | | rebuild-entry-index | Rebuild entries/index.json from entry files |

Built-in sliceId values: api, persistence, events, domain, flows, integrations, config, runtime, decisions, scripts.

search-entries

Compact navigation search—returns enough context to pick a hit, then call get-entry for full payload.

Input: query (required), moduleName, kind, tags, limit (default 10, max 50), offset (default 0)

Output: summary, total, returned, offset, hasMore, results[] with snippet, matchedIn, slices, moduleName plus legacy summary, tags, refs

Recommended kind examples (any string allowed):

| sliceId | kinds | |---------|-------| | api | http-endpoint, grpc-method, mcp-tool, cli-command, … | | persistence | db-table, entity, repository | | domain | glossary, invariant, lifecycle | | scripts | script — use set-entry / get-slice sliceId=scripts |

set-module-details

Creates or updates detailed information about a module. Slices read entries, not module text — pass facts[] to create linked entries in one call.

Input:

• projectId (optional): Project ID
• name: Module name
• description: Detailed description of the module
• inputs: What the module accepts as input
• outputs: What the module produces as output
• dependencies (optional): List of module dependencies (syncs to dataFlow.dependsOn when provided)
• files (optional): List of files belonging to this module
• facts (optional): Array of horizontal facts (kind, title, summary, …) — each upserted as entry with refs.moduleName = module name
• usageExamples (optional): Array of usage examples with fields:
• title: Example title
• description (optional): Description of the example
• command (optional): Command or code snippet
• input (optional): Input data
• output (optional): Expected output
• notes (optional): Additional notes about the example
• notes (optional): Additional notes

Output:

• Module ID and success message

set-module-data-flow

Patches dataFlow for a single module without sending the full architecture.

Input:

• projectId (optional): Project ID
• moduleName: Module name
• dependsOn (optional): Modules this module depends on (canonical)
• dataTransformation (optional): How data is transformed
• syncInverse (optional): Recompute providesTo (default true)

Output:

• Module name and success message

rebuild-data-flow

Rebuilds dataFlow for all modules from module file dependencies or existing dependsOn edges. Replaces bulk manual edits to architecture.json.

Input:

• projectId (optional): Project ID
• source (optional): module-dependencies (default) or dataFlow-dependsOn
• syncInverse (optional): Recompute providesTo (default true)
• pruneOrphans (optional): Remove invalid module references (default true)

Output:

• edgesAdded, edgesRemoved, modulesUpdated, message

validate

Primary post-edit check. Read-only validation with a compact agent-friendly report. Does not modify data.

Checks (only rules we can verify from stored JSON):

• dataFlow: inverse drift, dangling dependsOn/providesTo, orphan flow keys
• module.dependencies vs dataFlow.dependsOn
• entries: entries-without-modules, entry-unlinked, orphan-entry-module, module-no-entries, module-missing-api / module-missing-persistence, entry-slice-orphan, module-too-many-entries, module-too-few-entries
• storage: missing modules/{id}.json, orphan module files, entry index drift
• slices: empty built-in api / domain / persistence when modules exist

Input: projectId, checkInverse, checkModuleDeps, checkEntryCoverage, checkStorage, checkEmptySlices, checkSliceCoverage, checkModuleEntryCounts, moduleEntryMax (default 50), moduleEntryMin (optional; omit to disable min check) — all boolean flags default true unless noted

Output: valid, issueCount, summary, stats, issuesByKind, issues[], coverage, checksRun

refactor-architecture

Preview or apply in-architector sync after a code refactor when module boundaries stay the same. Agent is the source of truth — no workspace or git access. Default dryRun=true.

Workflow: (1) scan with file or text → compact hits, (2) build mutation ops, (3) dryRun preview, (4) apply with dryRun=false and confirm=true.

Operations (max 10 per call): scan, move-file, replace-path-prefix, rename-text, patch-entry, merge-files, remove-file-ref.

Scope (optional): moduleName, kinds, tags — limits which entries/modules are touched.

Orphan entries with empty refs.files and no refs.entryIds are deleted after file operations.

Input: projectId, operations[], scope, dryRun (default true), confirm (required when applying), limit, offset

Output: summary, stats, hits (scan) or paginated changes, warnings, hasMore

validate-architecture

Same as validate (legacy alias). Prefer validate after edits.

Output:

• valid (boolean), issues array

get-module-details

Retrieves detailed information about a specific module.

Input:

• projectId (optional): Project ID
• moduleName: Name of the module to retrieve

Output:

• Complete module details

list-modules

Lists all modules in the project architecture.

Input:

• projectId (optional): Project ID

Output:

• Array of module summaries

delete-module

Deletes a module from the project architecture.

Input:

• projectId (optional): Project ID
• moduleName: Name of the module to delete

Output:

• Success message

Resources

architecture

Provides access to project architecture as a resource.

Usage: Access via URI: arch://{projectId}

module

Provides access to module details as a resource.

Usage: Access via URI: module://{projectId}/{moduleId}

Development

Project Structure

mcp-architector/
├── src/
│   ├── index.ts          # Main server implementation
│   ├── types.ts          # Type definitions
│   └── storage.ts        # Storage utilities
├── dist/                 # Compiled output (generated)
├── package.json
├── tsconfig.json
└── README.md

Project ID and Workdir

The server uses projectId to organize data in separate directories. The priority for determining project ID is:

1. Explicitly passed in tool call parameters (highest priority)
2. From environment variable MCP_PROJECT_ID (set during initialization)
3. Default fallback "default-project" (lowest priority)

For Cursor integration, set MCP_PROJECT_ID to use the workspace directory automatically as the project ID.

Extending the Server

To add new tools, resources, or prompts, edit src/index.ts:

// Add a tool
server.registerTool(
  "tool-name",
  { /* tool config */ },
  async (params) => { /* handler */ }
);

// Add a resource
server.registerResource(
  "resource-name",
  new ResourceTemplate("uri-template", { /* options */ }),
  { /* resource config */ },
  async (uri, params) => { /* handler */ }
);

// Add a prompt
server.registerPrompt(
  "prompt-name",
  { /* prompt config */ },
  (args) => { /* handler */ }
);

License

MIT