WYSIWID Project

This project follows the What You See Is What It Does (WYSIWID) architectural pattern.

Structure

concepts/

Contains independent units of behavior ("Concepts").

• Each concept is self-contained.
• Concepts do not import each other.
• Concepts do not query each other's tables.

synchronizations/

Contains the logic that orchestrates interactions ("Synchronizations").

• Listens to events/actions in Concepts.
• Triggers actions in other Concepts.
• Acts as the "glue" of the system.

Rules

1. Factor Concepts: Distinct lifecycles = distinct Concepts.
2. No Cross-Calls: Never call Concept A from Concept B.
3. Use Syncs: All interactions must go through a Synchronization.
4. Polymorphism: Use opaque IDs (UUIDs) for references.

Implementation Example: Dynamic MCP Generator

This project implements a Dynamic MCP Generator that automatically creates Model Context Protocol (MCP) servers from Swagger URLs.

Concepts Used

1. SwaggerSource

   • Responsibility: Manages the configuration of Swagger/OpenAPI sources.
   • State: A list of URLs defined in config.json.
   • Independence: It knows nothing about servers or processes; it only manages the "source of truth" for API definitions.

2. MCPServer

   • Responsibility: Manages the lifecycle of local server processes.
   • State: Running processes, port assignments.
   • Independence: It knows nothing about configuration files; it only knows how to start and stop a server given a name and arguments.

Synchronization Logic

The SyncOrchestrator binds these two concepts together:

• Trigger: It reads the current state of SwaggerSource.
• Action: It instructs MCPServer to start a server for any source that doesn't have a running process.
• Result: Adding a URL to config.json automatically spins up a new MCP server without any manual intervention.

Usage

1. Add a Swagger URL to config.json.
2. Run python run.py.
3. The system will detect the new source and start an MCP server (e.g., on port 9000).