Skip to content
This repository was archived by the owner on Sep 23, 2025. It is now read-only.

Move logic into MCP server for cross-IDE portability #19

@nikomatsakis

Description

@nikomatsakis

Cross-IDE Portability via MCP Server Logic Migration

Status: Planning

Current Understanding

Currently, significant logic resides in the VSCode extension (TypeScript), making Dialectic tightly coupled to VSCode. To support other IDEs (Cursor, Zed, Neovim, etc.), we should migrate as much logic as possible into the MCP server (Rust) and minimize IDE-specific code.

Benefits

  • Cross-IDE Support: Same core functionality works across different editors
  • Reduced Duplication: Write logic once in Rust instead of per-IDE
  • Better Testing: Rust code is easier to unit test than extension code
  • Performance: Rust implementation likely faster than TypeScript
  • Maintenance: Single codebase for core logic

Logic Migration Candidates

High Priority:

  • File reference parsing and link generation
  • Review content processing and validation
  • Terminal detection and selection heuristics
  • PID discovery and process tree walking
  • Selection context formatting

Medium Priority:

  • Code action generation logic
  • Terminal message formatting
  • Error handling and user feedback

Low Priority (IDE-specific):

  • Webview rendering (inherently IDE-specific)
  • Native file system integration
  • Editor selection APIs

Approach

  1. Audit Current Logic: Identify what's in extension vs server
  2. Design MCP Protocol Extensions: Define new MCP tools/capabilities
  3. Incremental Migration: Move logic piece by piece with testing
  4. Thin Client Pattern: Extensions become thin wrappers around MCP calls

Next Steps

  • Audit current VSCode extension to catalog logic that could be moved
  • Research MCP protocol capabilities for rich data exchange
  • Design new MCP tools for file operations, terminal management, etc.
  • Create proof-of-concept with one piece of migrated logic

Open Questions

  • How much can we move while staying within MCP protocol constraints?
  • What's the right abstraction layer for IDE-specific operations?
  • Should we create custom MCP protocol extensions or work within standard?
  • How to handle IDE-specific UI patterns (webviews, panels, etc.)?

Context

This supports the long-term vision of Dialectic as a cross-platform code review tool. By centralizing logic in the MCP server, we can support multiple IDEs with minimal per-IDE development effort.

Metadata

Metadata

Assignees

No one assigned

    Labels

    ai-managedAI is permitted to update this issue OP and add commentsarchitectureDesign and architecture worktracking-issueOngoing work item tracked across multiple sessions

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions