InDesign MCP: Multi-Client Support & Auto-Reconnect

by Alex Johnson 52 views

In the fast-paced world of digital design, efficiency is key. When working with Adobe InDesign, integrating AI-powered tools can significantly streamline your workflow. This is where the Multiple Client Protocol (MCP) and its associated UXP plugin come into play. However, as workflows evolve and designers utilize multiple AI assistants, the need for robust, flexible connectivity becomes paramount. We're excited to introduce a solution that enables multiple MCP clients – think Claude Desktop, Claude Code, and other MCP-compatible tools – to simultaneously connect to a single InDesign instance. This isn't just about more connections; it's about a smarter, more resilient connection experience, complete with auto-reconnecting UXP plugin capabilities.

The Challenge: Bridging the Gap for Multiple AI Clients

Currently, the setup for MCP clients with InDesign presents a few hurdles. Each MCP server, designed to facilitate communication between an AI client and InDesign, typically spawns its own WebSocket server, often on a standard port like 6001. This immediately creates a bottleneck: only one MCP client can connect at a time due to port conflicts. For designers juggling multiple AI tools, this means manually switching configurations or being limited to a single AI assistant at any given moment. Furthermore, the existing UXP plugin requires a manual "Connect" button click to establish a link. If the MCP server restarts – a common occurrence during updates or troubleshooting – the connection is lost, necessitating another manual reconnection. This repetitive manual intervention can disrupt concentration and slow down the creative process. Our goal is to eliminate these friction points, creating a seamless and automated connection experience that empowers designers to leverage multiple AI tools without interruption.

Imagine a scenario where you're using Claude Desktop for content generation and Claude Code for scripting within the same InDesign project. Without multi-client support, you'd have to disconnect one to connect the other, losing the immediate context and flow. This proposed solution aims to resolve these issues by introducing a more sophisticated architecture that handles multiple connections gracefully and ensures the UXP plugin remains connected, no matter what.

The Solution: A Smarter Architecture for Seamless Connectivity

To address the limitations of the current system, we're proposing a new architecture centered around a primary/secondary MCP server pattern and a significantly enhanced UXP plugin. This design ensures that multiple MCP clients can coexist and communicate with InDesign through a single, reliable WebSocket bridge, while the UXP plugin handles connections automatically.

Architecture Overview

The core of the solution involves designating one MCP server as the "primary" and others as "secondary." The primary server acts as the central hub, hosting the main WebSocket server on the standard port (e.g., 6001). Any subsequent MCP servers launched will act as "secondary" servers. Instead of trying to host their own WebSocket server, they will connect to the primary server as WebSocket clients. This centralizes the connection point, eliminating port conflicts. The UXP plugin, in turn, connects to this primary WebSocket server. The beauty of this setup is its inherent simplicity for the end-user – multiple AI tools can be active simultaneously, and the UXP plugin ensures they are always connected.

Claude Desktop → MCP Server (PRIMARY) ──┐
                     │                  │
                     │ :6001            │
                     ▼                  ▼
Claude Code    → MCP Server ─────► WebSocket ◄──── UXP Plugin
                 (SECONDARY)        Server         (auto-connect)

This architectural shift is crucial. It allows InDesign to act as a single endpoint for multiple AI services, managed through a unified communication channel. The complexity is handled within the MCP server infrastructure, abstracting it away from the user.

MCP Server Enhancements: Primary/Secondary and Failover

The MCP server itself needs to evolve to support this new model. We'll implement a primary/secondary pattern where the first MCP server to start automatically becomes the "primary" and claims the WebSocket port (e.g., 6001). Any other MCP servers that start subsequently will detect that the port is in use and will automatically initiate as "secondary" servers. These secondary servers will then connect to the primary server's WebSocket. A key advantage here is leveraging the operating system's port binding mechanism as a natural mutex; when a server crashes, the OS cleans up the port binding, avoiding the need for complex lock files.

Failover is a critical component. If the primary MCP server crashes or is shut down, the OS will promptly release the port. The secondary servers, which are continuously monitoring their connection to the primary, will detect this disconnection. After a brief, configurable pause (e.g., 500 milliseconds) to allow the system to stabilize, the secondary servers will attempt to become the new primary. The first secondary server that successfully binds to the port will be promoted to primary status, and the others will reconnect to it as secondary servers. This ensures that the connection to InDesign remains available even if one of the MCP server instances fails.

This failover mechanism provides high availability. Designers can continue working without interruption, as a backup MCP server is always ready to take over. The implementation involves using libraries like detect-port to check port availability and standard WebSocket libraries (ws) to manage connections, offering a robust and efficient solution.

UXP Plugin: The Invisible, Reliable Connection

The UXP plugin is also undergoing a significant transformation. The manual "Connect/Disconnect" button will be removed entirely. In its place, the plugin will feature an automatic connection mechanism. Upon loading, the UXP plugin will attempt to connect to the WebSocket server at ws://localhost:6001. This connection attempt will use an exponential backoff strategy for retries, meaning it will wait progressively longer between connection attempts if the server is unavailable, up to a maximum delay. This prevents overwhelming the server during startup or recovery phases.

User interaction will be minimized to a status indicator. This indicator will visually represent the connection state: green for connected, yellow for connecting, and gray for disconnected. No user input will be required for managing the connection. The plugin will also implement continuous reconnection logic. If the WebSocket connection is lost for any reason (e.g., MCP server restart, failover event), the plugin will automatically attempt to reconnect following the exponential backoff pattern.

This automated approach ensures that the AI tools are always ready to communicate with InDesign the moment the designer needs them, without requiring any manual steps. The focus is on a set-and-forget experience, allowing designers to concentrate on their creative work rather than managing software connections.

Message Routing: Keeping Things Organized

With multiple clients potentially communicating through the primary server, a mechanism for message routing is essential. The primary server needs to distinguish between messages originating from the UXP plugin (which are typically responses to requests) and messages from secondary MCP servers (which are requests to be forwarded to InDesign). To achieve this, we can extend the communication protocol. Each message originating from a secondary MCP server and being forwarded to the primary could include a clientId field and be marked with a type: "forward". The primary server would then route the response back to the correct secondary client using the same clientId and a type: "response". Messages to and from the UXP plugin would remain in the standard JSON-RPC format. Alternatively, libraries like ws-multi-proxy can handle this message namespacing automatically, simplifying the implementation.

Technical Implementation Details

Implementing this enhanced connectivity requires careful consideration of dependencies and specific code changes within both the MCP server and the UXP plugin.

Dependencies

The primary new dependency for the MCP server is the detect-port library. This utility is crucial for identifying whether the desired WebSocket port is already in use, enabling the primary/secondary logic. The installation is straightforward using a package manager like pnpm:

pnpm add detect-port
pnpm add -D @types/detect-port # if needed for TypeScript

MCP Server (packages/mcp-server)

The MCP server codebase will need several key additions:

  • Dependency Integration: Add detect-port to the project.
  • Bridge Classes: Introduce PrimaryPluginBridge and SecondaryPluginBridge classes. The PrimaryPluginBridge will be responsible for creating and managing the WebSocketServer instance on the designated port, handling connections from both secondary MCP servers and the UXP plugin. The SecondaryPluginBridge will manage the client-side WebSocket connection to the primary server.
  • Mode Detection: Modify the server's entry point (server.ts or equivalent) to use detect-port upon startup. If the port is available, it initializes as primary; otherwise, it attempts to connect as a secondary.
  • Failover Logic: Implement the logic within SecondaryPluginBridge to detect close events from the primary server, schedule a reconnection attempt after a short delay, and attempt to transition to the primary role by trying to bind to the port.
  • Message Routing: Develop the system to distinguish and route messages correctly. This involves parsing incoming messages, identifying their origin (UXP plugin or secondary MCP server), and forwarding them appropriately, potentially using message types and client identifiers as discussed earlier.
  • Testing: Crucially, comprehensive tests must be developed to cover:
    • The coordination between primary and secondary servers.
    • The failover process when the primary server goes down.
    • Message routing accuracy.
    • Connection stability under various conditions.

UXP Plugin (packages/uxp-plugin)

For the UXP plugin, the changes focus on automating the connection and improving the user experience:

  • UI Removal: Remove the "Connect/Disconnect" button from the plugin's HTML interface (index.html).
  • Auto-Connect: Implement the connection logic directly in the plugin's JavaScript (index.js) so it runs automatically on plugin load. This involves creating a WebSocket instance pointing to ws://localhost:6001.
  • Reconnection Strategy: Implement the scheduleReconnect function using exponential backoff. This ensures that if a connection fails, the plugin retries at increasing intervals until it succeeds or reaches a maximum delay (MAX_RECONNECT_DELAY).
  • Status Indicator: Update the plugin's UI to display a visual status indicator (e.g., color-coded dots or text) showing "Connected," "Connecting," or "Disconnected." This provides immediate feedback without requiring user interaction.
  • Testing: Test the plugin's behavior rigorously:
    • Ensure it connects automatically upon loading.
    • Verify that it reconnects successfully when the MCP server restarts or fails over.
    • Test disconnection scenarios and ensure the exponential backoff and status updates work as expected.

Documentation and Acceptance Criteria

Clear documentation and well-defined acceptance criteria are vital for the successful adoption and implementation of this feature.

Documentation Updates

  • README: The main README.md file for the MCP server and potentially the UXP plugin should be updated to reflect the new multi-client capabilities. This includes instructions on how to configure multiple AI clients.
  • Architecture Documentation: A dedicated section explaining the primary/secondary server architecture and the failover mechanism should be added. This helps developers understand the underlying system.
  • Troubleshooting Guide: Enhance the troubleshooting section to cover common connection issues related to the new architecture, providing guidance for users experiencing problems.

Acceptance Criteria

To confirm that the implementation meets the desired functionality, the following criteria must be satisfied:

  1. Multi-Client Configuration: A user must be able to configure both Claude Desktop and Claude Code (or other compatible MCP clients) to connect to the InDesign MCP server simultaneously.
  2. Dual Client Functionality: Both configured clients must be able to send commands to InDesign. While commands will be processed sequentially by the primary server to avoid conflicts, the system should function correctly for both clients.
  3. UXP Auto-Connect: The UXP plugin must connect automatically without user intervention as soon as the MCP server is available.
  4. UXP Auto-Reconnect: When the MCP server restarts or experiences a failover, the UXP plugin must automatically detect the disconnection and re-establish its connection.
  5. Zero Manual Intervention: No manual steps should be required from the user to manage the connection between the UXP plugin and the MCP server after the initial setup.
  6. Graceful Failover: The system must handle the shutdown or failure of the primary MCP server gracefully, with a secondary server seamlessly taking over the primary role and maintaining the connection.

Design Decisions and Future Considerations

During the development of this multi-client support, several design decisions have been made to ensure robustness and a streamlined user experience. Understanding these decisions provides clarity on the system's behavior.

Handling Simultaneous Commands

A key consideration is how to manage commands sent from multiple MCP clients at the exact same time. To prevent race conditions and ensure predictable behavior within InDesign, commands will be queued. The primary MCP server will maintain a request queue. When multiple requests arrive nearly simultaneously, they will be processed in the order they are received by the primary server. This ensures that InDesign receives instructions in a controlled, sequential manner, regardless of how many clients initiated the requests.

UXP User Interface Simplicity

Regarding the UXP plugin's user interface, the decision has been made to keep it minimal. The UI will primarily display the connection status (connected, connecting, disconnected). There will be no need to show which specific MCP client is currently active or connected. This design choice prioritizes a clean, uncluttered interface for the designer, focusing on the essential information: whether the AI tools are ready to communicate with InDesign.

Scalability: Maximum Clients

There is no artificial cap imposed on the number of connected MCP clients. The architecture is designed to support an unlimited number of secondary MCP servers connecting to the primary. While practical system limits may exist based on hardware resources, the software design itself does not impose a limit, allowing for maximum flexibility as users adopt more AI tools.

Conclusion

This proposed solution for multi-client MCP support with an auto-reconnecting UXP plugin represents a significant leap forward in integrating AI assistance with Adobe InDesign. By introducing a primary/secondary MCP server architecture and automating the UXP plugin's connection management, we eliminate common pain points such as port conflicts and manual reconnection. Designers can now confidently use multiple AI tools simultaneously, benefiting from a stable, resilient, and seamless connection to InDesign. This enhanced workflow empowers creativity and boosts productivity by ensuring that the tools are always ready when inspiration strikes. We believe this upgrade will be invaluable for professionals seeking to leverage the full potential of AI in their design processes.

For further information on WebSockets and network programming, you can explore resources from the World Wide Web Consortium (W3C), which provides comprehensive standards and documentation related to web technologies, including WebSocket APIs. Additionally, understanding network port management can be aided by resources from organizations like the Internet Assigned Numbers Authority (IANA), which manages IP addresses and port numbers, providing insights into how network services are identified and communicate over the internet. You can find more about port assignments at IANA Port Numbers.