Add schema to creating dashboards so LLM has context on how to craft a Dashboard JSON config

[zhuje]

Goals

• Give LLM context into how to create a Dashboard JSON config (enhancement of Add Tool Call: Create Dashboard  #23)
• Use Case: Ultimately the value for perses users is not to have to create a Dashboard JSON config manually but to give minimum specifications so the LLM can do the actual config formatting

Problem

• LLM uses the tool call perses_list_dashboards to get an example of the schema of a dashboard; this solution is brittle and incomplete
• The LLM should have access to the actual Dashboard schema and not have to rely on perses_list_dashboards to give it context on how to create a Dashboard JSON config

Example of Problem
Currently, the LLM is only guessing at how to create the JSON config. How it can correctly guess the JSON is that it uses the perses_list_dashboards tool call to get the list of dashboards and then uses this example as a context for creating a new JSON config (e.g., it is using the API response to understand what the specifications required in the schema). However, this is not ideal. We want the LLM not to have to use the perses_list_dashboards tool call because this method is brittle and incomplete. For example, the current Perses instance might not have any dashboards, so there is no context for the LLM to create an accurate JSON config.

Figure 1. A chat with Claude attempts to create a dashboard JSON config but initially fails due to an incorrect panel structure. To fix this, it searches for existing projects and calls perses_list_dashboards to retrieve valid JSON examples. Using the returned dashboard list, Claude generates a corrected JSON config—something it couldn't do without this API call.

Solutions to Explore
The goal is to provide the MCP server with context for the dashboard schema without needing to use perses_list_dashboards.

• Explore ways to incorporate cuelang schema validation into mcp-server https://registry.cue.works/docs/github.com/perses/plugins/timeserieschart/schemas/migrate@v0.9.1
• Read Building MCP Servers: Part 1 — Getting Started with Resources

[ibakshay]

Solution 3: Perses server exposes an API to expose the schema of all the currently loaded plugins in the server.

[andreasgerstmayr]

schema of all the currently loaded plugin

👍
This will also work for private plugins and it always returns the correct version of the schema.

[zhuje]

This will also work for private plugins, and it always returns the correct version of the schema.

@andreasgerstmayr What does 'private plugins' mean in this context?

Solution 3: Perses server exposes an API to expose the schema of all the currently loaded plugins in the server.

@ibakshay Is the PluginRegistry (in perses/perses) the component that would have access to the schemas of the currently loaded plugins?

[andreasgerstmayr]

This will also work for private plugins, and it always returns the correct version of the schema.

@andreasgerstmayr What does 'private plugins' mean in this context?

For plugins which are hosted in the perses/plugins repo, we could use the cuelang registry as @AntoineThebaud mentioned (example: https://registry.cue.works/docs/github.com/perses/plugins/timeserieschart/schemas@v0:model).

But for plugins which are not open source, or more general, plugins which are not hosted in the perses/plugins repository, the MCP server doesn't know where to look for the cuelang schema if Perses is not exposing it.

[ibakshay]

This will also work for private plugins, and it always returns the correct version of the schema.

@andreasgerstmayr What does 'private plugins' mean in this context?

Solution 3: Perses server exposes an API to expose the schema of all the currently loaded plugins in the server.

@ibakshay Is the PluginRegistry (in perses/perses) the component that would have access to the schemas of the currently loaded plugins?

AFIK, The PluginRegistry you're referring to is the frontend TypeScript component (perses/ui/plugin-system/src/runtime/plugin-registry.ts) which handles plugin loading but doesn't have direct access to CUE schemas - it only gets plugin metadata from the backend. The actual schema validation happens on the backend via the perses/internal/api/plugin/schema/schema.go, so we'd need to expose those schemas through a new API endpoint.

[zhuje]

The actual schema validation happens on the backend via the perses/internal/api/plugin/schema/schema.go, so we'd need to expose those schemas through a new API endpoint.

Thanks, got it! I'll take a look at perses/internal/api/plugin/schema/schema.go and try to expose these schema through a new API endpoint.

[ibakshay]

The actual schema validation happens on the backend via the perses/internal/api/plugin/schema/schema.go, so we'd need to expose those schemas through a new API endpoint.

Thanks, got it! I'll take a look at perses/internal/api/plugin/schema/schema.go and try to expose these schema through a new API endpoint.

Sounds great!! 🚀
FYI:
You have to register the new endpoint in the endpoint.go file.
Also, this is the API endpoint to list all the plugins loaded in the server - https://demo.perses.dev/api/v1/plugins. This info might be useful to you.

[AntoineThebaud]

The actual schema validation happens on the backend via the perses/internal/api/plugin/schema/schema.go, so we'd need to expose those schemas through a new API endpoint.

Thanks, got it! I'll take a look at perses/internal/api/plugin/schema/schema.go and try to expose these schema through a new API endpoint.

Btw @zhuje for this new endpoint I think you should do some processing with the cuelang.org library in order to resolve the imports of the schemas and provide a "consolidated" result that would contain only final types (simple example of before/after here). I guess that would result in something easier to process by the AI.
To do that you should call Validate() as done here but without the Concrete option.

[ibakshay]

The actual schema validation happens on the backend via the perses/internal/api/plugin/schema/schema.go, so we'd need to expose those schemas through a new API endpoint.

Thanks, got it! I'll take a look at perses/internal/api/plugin/schema/schema.go and try to expose these schema through a new API endpoint.

Btw @zhuje for this new endpoint I think you should do some processing with the cuelang.org library in order to resolve the imports of the schemas and provide a "consolidated" result that would contain only final types (simple example of before/after here). I guess that would result in something easier to process by the AI. To do that you should call Validate() as done here but without the Concrete option.

oh BTW, Can this new endpoint be used by the Perses UI as well to generate zod validation types in runtime? Or, am I crazy? 🙈

[zhuje]

Btw @zhuje for this new endpoint I think you should do some processing with the cuelang.org library in order to resolve the imports of the schemas and provide a "consolidated" result that would contain only final types (simple example of before/after here). I guess that would result in something easier to process by the AI. To do that you should call Validate() as done here but without the Concrete option.

@AntoineThebaud Thanks for the tip! I haven't been working a lot with the cuelang.org library I'll look into it and follow up when I have more questions!