[Plugin Arch] Phase 6 — Refactor MCP Catalog as a Plugin

[Al-Pragliola]

Summary

Refactor the MCP Catalog (internal AI/ML operational tools catalog) to conform to the Plugin Interface, confirming that the plugin architecture supports multiple, diverse catalog implementations concurrently.

Motivation

A single plugin (model catalog) validates the interface, but doesn't prove the architecture handles diversity. The MCP catalog has different entities, different source types, and different query patterns. Successfully plugging it in confirms the generic nature of the Phase 1 primitives and the Phase 2 Plugin Interface, and is critical for achieving a truly unified catalog server that can manage all AI asset types.

Scope

• Implement the Plugin interface for the MCP catalog
• Register the MCP catalog via init() in the plugin registry
• Define MCP-specific OpenAPI specs using the split-file structure (Phase 4)
• Ensure MCP catalog and model catalog run concurrently in the unified server without conflicts
• Validate that shared primitives (sources, providers, loader, watcher, filter engine) work correctly for MCP entities

Acceptance Criteria

• MCP catalog implements the full Plugin interface
• MCP catalog self-registers via init() — no hardcoded references in the server
• MCP catalog and model catalog run concurrently in the unified server
• No shared-state conflicts between plugins (config, routes, data)
• MCP-specific OpenAPI spec lives within the plugin directory structure
• Unit and integration tests cover MCP catalog plugin behavior
• make build && make test && make lint pass

Dependencies

• Phase 5 [Plugin Arch] Phase 5 — Refactor Model Catalog as a Plugin #2531

References

• Parent: [Proposal] Plugin-Based Catalog Architecture and catalog-gen tool to generate new catalog types #2220