Skip to main content
Glama
Gaku52

Evolution MCP Server

by Gaku52
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Evolution MCP Server v2.0

4次元（実存性・歴史性・関係性・非合理性）× シンプルさ × Figma UI

人が本当に使い続けたくなるアプリケーションを、詳しい指示なしで自動的に生成するMCPサーバー。

"詳しく指示しなくても、素晴らしいアプリケーションが作れてしまう"

🌟 特徴

水面下で常に意識される原則

Claude Codeに登録すると、以下の原則が水面下で自動的に適用されます：

1. 4次元の原則

  • 実存性: 生きて存在することから生まれる価値

  • 歴史性: 時間を生きた蓄積

  • 関係性: 他者との創発的相互作用

  • 非合理性: 論理を超えた人間の本質

→ 最低1次元を深く実装することで、ユーザーが使い続けたくなるアプリに

2. シンプルさの原則

  • 3-1-1ルール: コア機能1つ、必須サポート3つまで、Nice-to-have 1つまで

  • 機能を増やすのではなく、既存機能に4次元を込める

→ シンプルだが、深く魅力的なアプリに

3. Figma的UI（必須要件）

  • モダンでプロフェッショナルなデザイン

  • Claude的なシンプルすぎるUIは避ける

  • shadcn/ui、Tailwind CSS等を推奨

→ 美しく使いやすいアプリに

Related MCP server: @forgespace/ui-mcp

🚀 セットアップ

1. リポジトリのクローン

```bash git clone https://github.com/Gaku52/spec-generator-mcp.git cd spec-generator-mcp ```

2. 依存関係のインストール

```bash npm install ```

3. ビルド

```bash npm run build ```

4. Claude Codeへの登録

claude_desktop_config.jsonを編集：

Windows: `%APPDATA%\Claude\claude_desktop_config.json`

macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`

設定内容:

```json { "mcpServers": { "evolution": { "command": "node", "args": [ "/absolute/path/to/spec-generator-mcp/dist/index.js" ] } } } ```

※パスは実際の環境に合わせて変更してください

Windows例: ```json { "mcpServers": { "evolution": { "command": "node", "args": [ "C:\\Users\\YourName\\spec-generator-mcp\\dist\\index.js" ] } } } ```

5. Claude Codeを再起動

設定を反映するため、Claude Codeを完全に再起動してください。

💡 使い方

パターン1: 最もシンプル（推奨）

ユーザーが詳しく指示しなくても、自動的に素晴らしいアプリが生成されます。

``` あなた: 「Todoアプリを作って」

Claude Code: → 自動的に4次元を分析 → シンプルさの原則を適用 → Figma的UIで設計 → 実装開始

[結果]

  • コア機能: タスク追加・完了（シンプル）

  • 歴史性: 継続日数を大きく表示

  • 非合理性: 100個達成で花火演出

  • Figma的UI: shadcn/ui使用 ```

パターン2: 要件定義書を生成

``` あなた: 「写真共有アプリの要件定義書を作って」

Claude Code: → generate_requirement_spec ツールを実行 → 4次元とシンプルさを組み込んだ要件定義書を生成 → Figma的UI要件も含まれる ```

パターン3: Resourceを確認

原則の詳細を確認したい場合：

``` あなた: 「4次元の原則を教えて」

Claude Code: → evolution://principles/four-dimensions を読み込み → 詳細な説明を表示 ```

📚 利用可能なResource

MCPサーバーが提供するResource（常にアクセス可能）：

URI

内容

evolution://principles/four-dimensions

4次元の完全ガイド（実存性・歴史性・関係性・非合理性）

evolution://principles/simplicity

シンプルさの原則（3-1-1ルール）

evolution://principles/design

Figma的UI実装ガイド（必須要件）

🛠️ 提供されるツール

v2.0のツール

ツール

説明

v2.0の改善点

generate_requirement_spec

要件定義書を生成

4次元・シンプルさ・Figma UIを自動組み込み

generate_functional_spec

機能仕様書を生成

同上

v2.1で追加予定

ツール

説明

discover_app_ideas

AI主導でアプリアイデアを提案

initialize_project

プロジェクト初期化（4次元のDNA作成）

🎯 実際の体験

Before（従来の方法）

``` あなた: 「Todoアプリを作って」

Claude: 「どんな機能が必要ですか？」

あなた: 「タスク追加、編集、削除、カテゴリ分け、優先度設定、 期限管理、リマインダー、統計機能、共有機能...」

Claude: 「複雑なTodoアプリを作成します」

[結果] ❌ 機能過多で使いにくい ❌ UIが粗雑 ❌ 誰も使い続けない ```

After（Evolution MCP v2.0）

``` あなた: 「Todoアプリを作って」

Claude Code（自動的に）: ✅ 4次元を分析 → 歴史性を重視 ✅ シンプルさ適用 → 機能を3つに絞る ✅ Figma UI → shadcn/ui + Tailwind

[結果] ✅ シンプルだが継続したくなる ✅ 美しいUI ✅ 人が使い続けるアプリ

機能:

  • タスク追加・完了（コア）

  • タスク編集・削除（サポート）

  • 継続日数表示（歴史性）

  • 100個達成で祝福（非合理性）

  • モダンなUI（Figma的） ```

🔍 仕組み

Resource機能

MCPサーバーが原則をResourceとして提供 → Claude Codeが水面下で常に参照可能 → 自動適用

Prompt機能

明示的に原則を適用したい場合に使用 → より確実な適用

自然な統合

ユーザーは原則を意識しなくてOK → Claude Codeが自動的に最適な判断 → 「詳しく指示しなくても素晴らしいアプリができる」を実現

📖 成功の方程式

``` 爆発的人気 = シンプルさ × 4次元の魅力

最低条件: 1次元を深く実装 理想: 3-4次元を満たす + シンプル + Figma UI ```

成功事例の分析（4次元スコア）

アプリ

実存性

歴史性

関係性

非合理性

シンプルさ

結果

Instagram（初期）

⭐⭐⭐⭐⭐

⭐⭐⭐⭐

⭐⭐⭐⭐⭐

⭐⭐⭐⭐

⭐⭐⭐⭐⭐

爆発的成功

Wordle

⭐⭐⭐⭐

⭐⭐⭐

⭐⭐⭐

⭐⭐

⭐⭐⭐⭐⭐

爆発的成功

Twitter（初期）

⭐⭐⭐⭐⭐

⭐⭐⭐

⭐⭐⭐⭐⭐

⭐⭐

⭐⭐⭐⭐⭐

爆発的成功

Notion

⭐⭐

⭐⭐⭐⭐⭐

⭐⭐⭐

⭐⭐⭐⭐

⭐⭐

成功（爆発的ではない）

教訓: 4次元 + シンプルさ = 爆発的成功

🛣️ ロードマップ

v2.0（現在）✅

  • 4次元の原則をResource化

  • シンプルさの原則

  • Figma的UI推奨（必須要件）

  • Resource/Prompt機能

  • 既存ツールのv2.0対応

v2.1（近日）

  • discover_app_ideas - AI主導のアイデア生成

  • initialize_project - プロジェクト初期化

  • 知識蓄積メカニズムの基礎

v3.0（将来）

  • 過去プロジェクトからの自動学習

  • 成功パターンの分析

  • 完全な開発ライフサイクル対応

📂 プロジェクト構造

``` spec-generator-mcp/ ├── src/ │ ├── index.ts # MCPサーバー（v2.0） │ ├── resources/ # 原則（常に参照可能） │ │ ├── fourDimensions.ts # 4次元の原則 │ │ ├── simplicityPrinciples.ts # シンプルさの原則 │ │ └── designPrinciples.ts # Figma的UI │ ├── tools/ # ツール │ │ ├── requirementSpec.ts # 要件定義書（v2対応） │ │ └── functionalSpec.ts # 機能仕様書 │ └── templates/ # テンプレート │ ├── requirement.ts # v1.0 │ ├── requirementV2.ts # v2.0（4次元対応） │ └── functional.ts ├── dist/ # ビルド出力 ├── package.json # evolution-mcp v2.0.0 └── README.md ```

🔧 開発

開発モード

```bash npm run dev ```

TypeScriptファイルの変更を監視し、自動的に再ビルド。

カスタマイズ

Resourceファイル（src/resources/）を編集することで、原則をカスタマイズ可能。 ただし、4次元とシンプルさの本質は変えない方が良い。

❓ トラブルシューティング

MCPサーバーが認識されない

  1. ビルドが成功しているか確認 ```bash npm run build ```

  2. claude_desktop_config.json のパスが正しいか確認

  3. Claude Codeを完全に再起動

Resourceが読み込まれない

  1. MCPサーバーが起動しているか確認

  2. Claude Code Developer Toolsでログ確認

  3. サーバー再起動

ビルドエラー

  1. Node.jsバージョン確認（v18+推奨）

  2. 依存関係の再インストール ```bash rm -rf node_modules package-lock.json npm install ```

📝 ライセンス

MIT License

🙏 貢献

このプロジェクトは、人が本当に使い続けたくなるアプリを作るための実験です。

フィードバック・改善提案を歓迎します！

Issues: https://github.com/Gaku52/spec-generator-mcp/issues

🌐 参考リンク

Evolution MCP v2.0 - 水面下で素晴らしいアプリケーションを生み出します

「詳しく指示しなくても、素晴らしいアプリケーションが作れてしまう」

Available Tools

2 tools
generate_functional_specA

機能仕様書を生成します。機能一覧から詳細な機能仕様書（ユースケース、画面仕様、データ仕様など）を自動生成します。

ParametersJSON Schema
NameRequiredDescriptionDefault
featuresYes機能一覧
projectNameYesプロジェクト名
requirementSpecNo要件定義書の内容（オプション、より正確な仕様書生成のため）

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It does state that generation is automatic and enumerates output content (use cases, screen specs, data specs). However, it does not describe what the tool returns, whether it writes to a file, or any side effects, so some key behavior is left unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, purposeful Japanese sentences front-load the action and then add necessary detail about input and output scope. No filler or redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description should explain the return value or resulting artifact. It only says a specification is 'generated' without describing how the agent receives the result, and it ignores the optional requirementSpec input. This is a significant gap for selecting and invoking the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all parameters with 100% coverage, so the baseline applies. The description only mentions the 'feature list' and omits the optional requirementSpec parameter, adding little meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates functional specification documents ('機能仕様書を生成します') and elaborates that it creates detailed specs including use cases, screen specs, and data specs from the feature list. This specific verb+resource plus the feature-list source distinguishes it from the sibling generate_requirement_spec.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description communicates clear usage context: pass a feature list ('機能一覧から') to obtain a detailed functional specification. It does not explicitly mention when not to use it or point to the sibling alternative, but the source/input requirement provides clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_requirement_specB

要件定義書を生成します。プロジェクト名、目的、背景から詳細な要件定義書（機能要件、非機能要件、制約事項など）を自動生成します。

ParametersJSON Schema
NameRequiredDescriptionDefault
purposeYesプロジェクトの目的
backgroundNo背景情報（オプション）
constraintsNo制約条件（オプション）
projectNameYesプロジェクト名
targetUsersNo対象ユーザー（オプション）

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of explaining behavior. It states that the tool automatically generates a detailed requirements document with specific sections, which is useful. However, it does not disclose the output format, whether a file or text is returned, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately names the verb and resource, then adds the key inputs and output contents. There is no filler or redundant restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is straightforward and its parameters are fully described in the schema, but there is no output schema and the description does not state what kind of artifact or content the agent should expect in return. The missing relationship to generate_functional_spec also leaves a gap in an otherwise adequate description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds modest value by naming projectName, purpose, and background as generation inputs, but it does not clarify how constraints or targetUsers influence the output beyond their schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action and resource: generating a requirements definition document (要件定義書), and lists the inputs (project name, purpose, background) and output contents (functional requirements, non-functional requirements, constraints). It does not explicitly contrast with the sibling tool generate_functional_spec, but the resource name itself helps differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus generate_functional_spec, and no exclusions or conditions. Since a closely related sibling tool exists, the lack of selection guidance leaves the agent to infer the boundary between requirement specs and functional specs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv2.0.0
    • First observedgenerate_functional_spec
    • First observedgenerate_requirement_spec
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 2 tools

Disambiguation5/5

The two tools target clearly distinct artifacts: a requirements definition document versus a functional specification document. The naming and descriptions make the boundary obvious, so an agent should not confuse them.

Naming Consistency5/5

Both tools follow the same generate_<target>_spec pattern using consistent snake_case. This creates a predictable and uniform naming convention across the entire server.

Tool Count3/5

With only two tools, the server feels thin and borderline for a document-generation server. Each tool is purposeful, but the set lacks supporting utilities or additional artifact types to feel fully scoped.

Completeness3/5

The pair covers the requirements-to-functional-spec handoff, but the workflow stops there. There is no way to update, version, or generate adjacent artifacts such as detailed design or test specifications, leaving notable gaps in a broader specification lifecycle.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches