feat: mcp server for validate plugin

[s4kh]

Exposes plugin-validator CLI as MCP server. Tool: validate_plugin

1. Separate release for mcpserver - published to npm
2. MCP server uses npx to run the latest validator CLI
3. Includes configs for vscode extension, claude code, openAI codex configs in the README

[s4kh]

We have to do same stuffs we do in plugincheck2/main.go (reading archive, checksum, etc.) Maybe extract those into separate package and reuse it.

[s4kh]

Extracted from plugincheck2/main.go.

[s4kh]

.local/bin exists both on macos and linux

[s4kh]

plugincheck2 used to check this using GetIdAndVersion from quickmeta and if it returns error it would add an invalid structure report to the result.

[s4kh]

https://grafana.com/blog/how-i-write-http-services-in-go-after-13-years/ -> func main() only calls run()

[academo]

I would like you to reconsider the approach for the mcp server

the validator already supports outputting as json, could you invoke the validator binary here and parse the output instead?

here are my two concerns with this approach:

1. single source of truth: now we are effectively creating two different software that embed the same engine. I much rather prefer we keep a single entry point (the validator cli binary) and make MCP just another user, like for example github actions is an user of the validator, and ci-workflows, and the community pipeline.

We don't need to create separate binaries for those cases because we have a common serialized output any user can read.

2. updates: this binary will be out of date very quickly. instead we can have this wrapper checking the latest version (once a day?), downloading it and executing it to get the json output.

I don't see a mechanism to update mcp servers, they need to auto-update. People that use the validator mainly use it via docker or npx that always pulls the latest version (except NPM when it wants to be a pain)

my bottom line: we can make this wrapper simply call npx or docker or yarn dlx or similar (support several fallbacks) and parse the json output.

[s4kh]

We are running the tests locally. In CI it will be skipped due to docker and npx not present.

[s4kh]

Validator itself is tested in https://github.com/grafana/plugin-validator/blob/main/pkg/cmd/plugincheck2/main_test.go

[academo]

CI has docker available.

[s4kh]

So we run the tests using mage -v build:ci inside a container which uses goalpine(Dockerfile) thus no docker or npm. I have created a new job inside the test.yml of the github workflows.

[academo]

curious on why we need this step. actions/checkout doesn't fetch tags?

[s4kh]

Yeah it came in from release.yml -> which was a requirement for old gorealeaser for generating the correct changelog.

[academo]

since the running docker inside docker is so problematic,. let's skip the docker release?

[academo]

I feel these instructions are going too far on how to set up. trying to cover every possible single client that could use it.

In reality most agents will work with adding

"mcpServers": {
    "grafana-plugin-validator": {
      "command": "npx",
      "args": ["-y", "@grafana/plugin-validator-mcp@latest"]
    }
  }

in the correct place and developers already know how to do that in their agent or can figure out how to do it.

What if we reduce all this text to a simple "hey, put this in your agent mpc settings. most of the times is in .mpc.json file" or something like that?

maybe we can give a direct command for agents that allow one-command setup without messing with files (e.g. claude code has a mcp command to add servers from the cli)

I feel most of these instructions will quickly be outdated.

[s4kh]

It is mainly codex and claude code/desktop the content itself is same but the file locations are different. Codex uses .toml files for the config.