The Meshery MCP Server foundation is up, let's agree on what to build next

Extensions
, ,
1

Hey everyone,

I’m Akash, a pre-final year CS student, and I’ve been working on the meshery-mcp-server repo since it went live. I figured it’s about time I opened a proper thread about where the project is and what we should build next, so we’re all heading in the same direction.

Quick recap of where things stand. PR #28 has the foundation: Go module, an MCP server over stdio on mark3labs/mcp-go, config from environment variables, Makefile, Dockerfile, and a CI workflow that actually runs on this repo. The old workflows were failing every PR because they were copied over from meshery/meshery and referenced ui/ and provider-ui/ folders that don’t exist here. That’s fixed now, the scaffold is frozen, and CodeRabbit’s review is closed. It’s just waiting on merge.

I also want to say this plainly: the direction I’m proposing builds on what others already started. Yatharth’s RFC thread did a great job framing the transport-agnostic core, and Omolade’s DESIGN.md in #29 gives us a concrete contract with camelCase mapping and pagination guidance. What I suggest below sits on top of both, it doesn’t replace them.

Here’s the order I’d propose, mirroring the scope Cooper laid out:

  1. Get PR #28 merged. Everything else stacks on it.
  2. Build the shared Meshery REST client (#6) as the single integration boundary all tools use. Ping health check, env-driven config, timeouts, retries, auth header, and httptest coverage.
  3. Land the first real tool, list_designs (#30), read-only, using the response mapping and pagination from the design doc.
  4. Add SSE/HTTP transport (#5) alongside stdio, with graceful shutdown, so remote clients can connect.
  5. Define a shared registration contract for tools, resources, and prompts so future contributors implement things the same way instead of each reinventing it.
  6. Then environments, workspaces, clusters, registry queries, and performance testing, in the priority order already agreed.

A few things I’d genuinely like your opinions on before we go deep:

  • Should tools just receive an already-authenticated client and never worry about how auth works (token, cookie, whatever)? I lean yes, and it’s worth deciding before the client lands.
  • Is a small interface in internal/server the right home for the registration contract, or do you see it differently?
  • SSE now or after the first tools? I’d say after, so we validate the tools over the simpler stdio path first.

I’ll be at the weekly dev meeting and happy to hear any thoughts. Reviews on #28 are very welcome, they’ll shape everything that follows. I’m also applying for the Term 3 LFX slot for this project, and I’ll keep contributing either way.

Thanks to Lee, Cooper, and Yi Nuo for getting this initiative off the ground, and to Yatharth and Omolade for kicking off the design discussion.

@Lee @Cooper

2

Hi Akash,

Agreed on tools getting an already-authenticated client that never touches the token. I hit this exact problem building SENTINEL, an MCP security proxy: once any tool sees a raw credential, every tool implementation becomes a place that can leak it, and testing for leaks turns into testing N things instead of one. Locking auth into the client layer makes that class of bug structurally impossible to hit from a tool, which is the direction section 6 already takes.

I’d like to pick up issue #6, the shared REST/GraphQL client, building on top of #28. I’m coming from Python and JavaScript, not Go, so I won’t pretend this will be fast, but I’d rather show a working, tested client than talk about how I’d build one. I’ll open a draft PR early so the direction can get corrected if needed.

Krishna Harshith Pali (Harshith029)