Skip to main content
Glama
enesjakozh
monteslu

Vibe-Eyes

by monteslu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

氛围眼

MCP 服务器使 LLM 能够通过矢量化画布可视化和调试信息“看到”基于浏览器的游戏和应用程序中发生的情况。

Vibe-Eyes 使用客户端-服务器架构，其中轻量级浏览器客户端捕获画布内容和调试信息，通过 WebSockets 将其发送到 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 的“氛围编码”会话。

视频讲解

Vibe-Eyes 视频讲解

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

  • 拦截控制台日志和错误

  • 使用堆栈跟踪捕获全局未处理的异常

  • 通过 WebSockets 将数据发送到 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 代理一起使用

使用您的 AI 代理注册 MCP 服务器：

# 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>

与 Claude 或其他法学硕士合作

MCP 服务器为 LLM 提供了一个工具，可以通过模型上下文协议 (MCP) 访问最新的视觉和调试信息：

getGameDebug({ includeSvg: true/false })

法学硕士将获得：

  • 应用程序的最新控制台日志和错误

  • 未处理的异常及其完整堆栈跟踪（如果发生）

  • 画布的矢量化 SVG 近似值（如果includeSvg为真）

  • 将视觉状态与日志连接起来的时间和相关信息

这使得 LLM 能够“看到”应用程序中发生的情况并提供更好的帮助。

MCP 配置示例（适用于 Claude 代码）

要从 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 编码”

传统的“Vibe 编码”流程需要开发者手动截取屏幕截图并描述应用程序的运行情况。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

执照

国际学习中心

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