Hi everyone! I’m Yatharth Katta
Over the last couple of days I’ve been studying the Meshery ecosystem, the MCP specification, and the initial roadmap for meshery-mcp-server. Rather than just reading Issues #4 - #17 independently, I tried to understand them as parts of a single system. One thing that stood out to me is that many of the implementation issues share a small number of architectural dependencies, and I think aligning on those early will make later feature work much smoother.
From my current understanding, the project naturally fits into something like this:
My current interpretation is that the MCP server should primarily provide an AI-native interface to Meshery rather than exposing REST endpoints directly. Ideally, the server core remains transport-agnostic while domain functionality is implemented through Tools, Resources, and Prompts on top of a shared Meshery client.
While reading through the roadmap, a few cross-cutting questions came up that seem to affect several issues at once.
1. MCP SDK
Issue #5 mentions both mark3labs/mcp-go and the official Go SDK. Since this decision affects tool registration, resources, prompts, testing, and transport support, has the project already settled on one? If not, I’d be happy to compare both SDKs against the project’s requirements and document the trade-offs.
2. Shared registration model
Several issues describe Tools, Resources, and Prompts, but I couldn’t find a common registration contract yet. It feels like establishing a shared interface early would make it much easier for multiple contributors to implement features consistently instead of each introducing their own pattern.
3. Session and context
Issues around workspaces, multiple Meshery instances, authentication, and cluster context all seem related. Before implementing higher-level tools, it would be helpful to understand the intended session model—for example, how active context, workspace, and authentication state should be managed throughout an MCP session.
4. REST vs GraphQL responsibilities
My understanding is that some capabilities are naturally request/response, while others (especially anything related to MeshSync or live state) may eventually benefit from subscriptions or streaming. Is there already a preferred direction for how those responsibilities should be divided between REST and GraphQL within the client layer?
My intention isn’t to redesign the roadmap—quite the opposite. I’d like to make sure the foundational contracts are aligned before more feature-specific implementations begin, so that later work builds on consistent abstractions rather than different assumptions.
I’m planning to start with the foundational work (repository scaffolding and MCP server infrastructure), and if it’s useful, I’d also be happy to draft a small RFC describing a shared registration interface for Tools, Resources, and Prompts that other issues can build upon.
I’d really appreciate any feedback from the maintainers on whether my understanding aligns with the intended direction, or if there are existing design decisions I should build around before opening PRs.