Skip to main content
Glama
enesjakozh
monteslu

Vibe-Eyes

by monteslu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

バイブアイズ

ベクトル化されたキャンバスの視覚化とデバッグ情報を通じて、ブラウザベースのゲームやアプリケーションで何が起こっているかを LLM が「確認」できるようにする MCP サーバー。

Vibe-Eyes はクライアント サーバー アーキテクチャを使用しており、軽量のブラウザー クライアントがキャンバス コンテンツとデバッグ情報をキャプチャし、WebSocket 経由で Node.js サーバーに送信します。その後、Node.js サーバーは画像をコンパクトな SVG 表現にベクトル化し、モデル コンテキスト プロトコル (MCP) を通じて LLM で使用できるようにします。

flowchart LR
    A["Browser Game/App<br/>(Canvas + JavaScript)"] -->|"Captures"| B["Vibe-Eyes Client<br/>(vibe-eyes-client)"]
    B -->|"WebSocket<br/>(CORS-free)"| C["Socket.IO Server"]
    
    subgraph server["Vibe-Eyes Server (mcp.js)"]
        C -->|"Process"| D["Vectorization<br/>(vectorizer.js)"]
        C -->|"Store"| E["Debug Data<br/>(logs, errors, exceptions)"]
        D -->|"Rough SVG"| F["MCP Tool: getGameDebug()"]
        E --> F
    end
    
    F -->|"SVG + Debug Info"| G["Claude/LLM<br/>(MCP Client)"]
    G -->|"Debugging<br/>Assistance"| A
    
    classDef default color:#000,font-weight:bold
    classDef edgeLabel color:#333,font-size:12px
    
    style A fill:#c0e0ff,stroke:#000,stroke-width:2px
    style B fill:#ffe0a0,stroke:#000,stroke-width:2px
    style C fill:#a0d0ff,stroke:#000,stroke-width:2px
    style D fill:#b0e0a0,stroke:#000,stroke-width:2px
    style E fill:#ffb0b0,stroke:#000,stroke-width:2px
    style F fill:#d0b0ff,stroke:#000,stroke-width:2px
    style G fill:#ffb0d0,stroke:#000,stroke-width:2px
    style server fill:#f0f0f0,stroke:#666,stroke-width:1px,stroke-dasharray: 5 5,color:#000

注: このプロジェクトは実験的なもので、視覚的なコンテキストと豊富なデバッグ情報を提供することで、LLM を使用した「バイブ コーディング」セッションを強化するように設計されています。

ビデオ説明

バイブアイズビデオ解説

Related MCP server: image-tiler-mcp-server

主な機能

  • ブラウザゲームからキャンバス要素をキャプチャしてベクトル化します

  • コンソールログとエラーをリアルタイムで収集します

  • フルスタックトレースで未処理の例外をキャッチ

  • MCPを介してLLMにビジュアル情報とデバッグ情報を提供する

  • LLM を使用する開発者にシームレスなデバッグ エクスペリエンスを提供します

仕組み

  1. 軽量クライアントはブラウザゲーム/アプリケーション内で実行されます

  2. クライアントはキャンバスのスナップショット、コンソールのログ/エラー、未処理の例外をキャプチャします。

  3. データはWebSocket経由でVibe-Eyesサーバーに送信されます（CORSの問題を回避）

  4. サーバーはキャンバス画像をベクトル化し、デバッグ情報とともに保存します。

  5. LLMはモデルコンテキストプロトコルを介して接続し、最新のデータにアクセスします。

  6. LLMは何が起こっているかを「見て」、完全なコンテキストで問題のデバッグを支援できます。

コンポーネント

1. Vibe-Eyes MCP サーバー ( mcp.js )

次の機能を備えたコア サーバー:

  • Socket.IO経由でキャンバススナップショットを受信する

  • 画像をコンパクトなSVG表現にベクトル化します（大まかな近似）

  • デバッグ情報（ログ、エラー、例外、タイミング）を保存します

  • モデルコンテキストプロトコル（MCP）を介してデータを公開します

  • 直接アクセス用のHTTPエンドポイントを提供します

  • 画像を順番に処理してリソースを管理する

2. ブラウザクライアント

ブラウザ クライアントは、vibe-eyes-client リポジトリから入手できます。

次の機能を備えた軽量ブラウザ統合:

  • ページ内のキャンバス要素を検索します

  • キャンバスのコンテンツをデータ URL としてキャプチャします

  • コンソールのログとエラーを傍受する

  • スタック トレースでグローバルな未処理例外をキャッチします

  • WebSocket経由でVibe-Eyesサーバーにデータを送信します

  • ゲームのパフォーマンスへの影響を最小限に抑えます

  • キャプチャ開始時の制御のための明示的な初期化をサポート

3. ベクトル化エンジン（ vectorizer.js ）

以下の機能を備えた高品質の SVG ベクトル化ライブラリ:

  • ラスター画像をベクターSVGに変換します

  • SVGのサイズと鮮明度を最適化します

  • データサイズを削減しながら視覚情報を保持

はじめる

インストール

# Clone the repository
git clone https://github.com/monteslu/vibe-eyes.git
cd vibe-eyes

# Install dependencies
npm install

LLMエージェントとの使用

MCP サーバーを AI エージェントに登録します。

# For Claude Code
claude mcp add

これにより、Claude は MCP を介して Vibe-Eyes 機能を使用できるようになります。

ゲーム/アプリケーションとの統合

必要なスクリプトを組み込んで、クライアントをブラウザ アプリケーションに追加します。

<!-- Include Socket.IO client -->
<script src="https://cdn.socket.io/4.7.4/socket.io.min.js"></script>

<!-- Include Vibe-Eyes client -->
<script src="https://cdn.jsdelivr.net/npm/vibe-eyes-client/dist/index.min.js"></script>

<!-- Initialize the client -->
<script>
  // Import the initialization function if using as module
  // import { initializeVibeEyes } from 'vibe-eyes-client';
  
  // Initialize with configuration
  const vibeEyes = initializeVibeEyes({
    // WebSocket URL to the Vibe-Eyes server
    serverUrl: 'ws://localhost:8869',
    // Capture interval in milliseconds
    captureDelay: 1000,
    // Start capturing automatically after connection
    autoCapture: true
  });
</script>

クロードや他のLLMと併用

MCP サーバーは、LLM がモデル コンテキスト プロトコル (MCP) を介して最新のビジュアル情報とデバッグ情報にアクセスするためのツールを公開します。

getGameDebug({ includeSvg: true/false })

LLM は以下を受け取ります:

  • アプリケーションからの最近のコンソールログとエラー

  • フルスタック トレースを含む未処理の例外 (発生した場合)

  • キャンバスのベクトル化された SVG 近似値 ( includeSvgが true の場合)

  • 視覚的な状態とログを結び付けるタイミングと相関情報

これにより、LLM はアプリケーションで何が起こっているかを「確認」し、より適切なサポートを提供できるようになります。

MCP 構成の例 (Claude Code 用)

Claude から Vibe-Eyes にアクセスするには:

{
  "name": "vibe-eyes",
  "url": "http://localhost:8869",
  "tools": [
    {
      "name": "getGameDebug",
      "description": "Retrieves the most recent canvas visualization and debug information from a browser game or application"
    }
  ]
}

Vibe-Eyesが「バイブコーディング」にどのように役立つか

従来の「バイブコーディング」セッションでは、開発者は手動でスクリーンショットを撮り、アプリケーション内で何が起こっているかを記述する必要がありました。Vibe-Eyesは、以下の方法でこのプロセスを自動化します。

  1. 視覚的なコンテキストの提供: LLMはゲーム/アプリの実際の視覚的な状態を確認できます

  2. ビジュアルとコードの問題の相関関係: コンソールログはビジュアル状態とペアになっています

  3. 手作業の削減：スクリーンショットを手動でキャプチャしてアップロードする必要はありません

  4. リアルタイムデバッグの有効化: LLMは変更が発生したときにそれを観察できる

  5. データ転送の最適化:ベクター表現はスクリーンショットよりもコンパクト

パフォーマンスに関する考慮事項

  • ブラウザクライアントは、アプリケーションのパフォーマンスへの影響を最小限に抑えるように設計されています。

  • キャンバスデータURLの作成はCPUを大量に消費する可能性があるため、キャプチャ頻度は設定可能です。

  • WebSocketトランスポートは、クロスドメイン設定でよくあるCORSの問題を回避します。

  • サーバーは過負荷を防ぐために画像を順番に処理します

  • SVGベクター化は視覚的な正確さとサイズの最適化を両立します

SVGへの直接アクセス

ベクトル化された SVG 出力を再利用したいアプリケーションの場合:

  1. WebSocket レスポンス: サーバーは WebSocket レスポンスに SVG を直接含めます。

    socket.on('debugCapture', (data, callback) => {
  // Capture and process...
  callback({
    success: true,
    id: "capture_123",
    svg: "<svg>...</svg>",  // Vectorized SVG 
    stats: { /* stats data */ }
  });
});

  2. HTTP エンドポイント: /latestエンドポイント経由で最新のキャプチャにアクセスします。

    fetch('http://localhost:8869/latest')
  .then(res => res.json())
  .then(data => {
    const svg = data.vectorized?.svg;
    // Use the SVG...
  });

APIリファレンス

ブラウザクライアント

// Initialize the client
const vibeEyes = initializeVibeEyes({
  serverUrl: 'ws://localhost:8869',
  captureDelay: 1000, // ms between captures
  maxLogs: 10,        // Max console.log entries to store
  maxErrors: 10,      // Max console.error entries to store
  autoCapture: true   // Start capturing automatically
});

// Manual control
vibeEyes.startCaptureLoop(); // Start auto-capturing
vibeEyes.stopCaptureLoop();  // Stop auto-capturing
vibeEyes.captureAndSend();   // Trigger one capture immediately

// The server responds with:
// {
//   success: true,
//   id: "capture_1234567890",
//   processedAt: 1616161616161,
//   svg: "<svg>...</svg>",  // The vectorized SVG for direct use
//   stats: {
//     vectorizeTime: 120,
//     optimizeTime: 30,
//     originalSize: 50000,
//     finalSize: 15000,
//     sizeReduction: 70
//   }
// }

MCPツール

// MCP tool available to LLMs
getGameDebug({
  includeSvg: true  // Whether to include SVG visualization
})

// Returns
{
  success: true,
  capture: {
    id: "capture_123456789",
    timestamp: 1616161616161,
    console_logs: [
      { timestamp: 1616161616000, data: ["Player position:", {x: 10, y: 20}] },
      // ...more logs
    ],
    console_errors: [
      // Any errors captured
    ],
    unhandled_exception: {
      timestamp: 1616161616100,
      message: "Uncaught SyntaxError: Unexpected token ';'",
      stack: "SyntaxError: Unexpected token ';'\n    at game.js:42:10\n...",
      type: "SyntaxError",
      source: "game.js",
      line: 42,
      column: 10
    },
    vectorized: {
      svg: "<svg>...</svg>",  // Only if includeSvg is true (rough approximation)
      imageType: "png",
      stats: {
        vectorizeTime: 120,
        optimizeTime: 30,
        originalSize: 50000,
        finalSize: 15000,
        sizeReduction: 70
      }
    }
  }
}

スタンドアロン ベクトライザー CLI

このプロジェクトには、個々のファイルをベクトル化するためのスタンドアロン CLI ツールも含まれています。

# Install CLI globally
npm install -g vibe-eyes

# Use the CLI
vibe-eyes-vectorize input.png output.svg

# With options
vibe-eyes-vectorize photo.jpg --color-precision 10 --max-iterations 100

ライセンス

ISC

Available Tools

1 tool
getGameDebugInfoWithLogsAndVisualizationD
ParametersJSON Schema
NameRequiredDescriptionDefault
includeSvgNo

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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. 1 tool update
    • First observedgetGameDebugInfoWithLogsAndVisualization
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

D1.5/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is singular and distinct by default.

Naming Consistency3/5

There is only one tool, so consistency across multiple tools cannot be assessed. The name uses camelCase, which is a valid convention, but no pattern can be established with a single tool.

Tool Count2/5

A single tool is typically too few for most server purposes, suggesting a very limited or incomplete surface. Without a description, it's unclear if this minimal scope is justified, but it likely indicates under-coverage.

Completeness1/5

With only one tool and no description provided, it is impossible to infer the domain or assess coverage. This severely limits the ability to perform any meaningful operations, indicating a highly incomplete surface.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches