The Why
Issue #10 implements Grafana datasource validation as a prompt-driven workflow — Claude calls mcp-grafana tools and compares URLs. This works but is non-deterministic: it relies on Claude correctly executing a multi-step comparison. If this proves unreliable in practice (wrong datasource selected, URL comparison flubbed, etc.), we need a deterministic fallback.
Depends on: #10 (prompt-driven preflight must be tried first)
Context from #10 Design
The #10 design chose "Option A: Prompt-driven preflight" over "Option B: Preflight tool with user-supplied datasource config" because it's simpler and requires no extra configuration. The design explicitly noted:
"If prompt-driven validation proves unreliable, fall back to a deterministic pcp_grafana_preflight tool with user-supplied config."
This issue is that fallback.
Proposed Feature
A new pmmcp tool: pcp_grafana_preflight
Configuration:
PMMCP_GRAFANA_DATASOURCE_UID — the expected Grafana datasource UID (user pre-configures this)
Behaviour:
- Claude calls
mcp-grafana.get_datasource(uid) and passes the result to pcp_grafana_preflight
- The tool extracts the datasource's pmproxy URL from the response
- Compares it deterministically with pmmcp's configured
PMPROXY_URL
- Returns a structured result:
{ "valid": true/false, "datasource_uid": "...", "pmproxy_url_match": true/false, "details": "..." }
- Caches the result for the session
Advantages over prompt-driven:
- URL comparison is deterministic Python code, not LLM interpretation
- Structured return value — prompts can branch on
valid: true/false
- Cacheable in server state (not just conversation context)
When to Build This
Don't build this proactively. Only implement if:
- Users report that prompt-driven preflight is matching wrong datasources
- URL comparison is failing (e.g.
http://pmproxy:44322 vs http://localhost:44322 — same host, different names)
- Session context loss causes repeated unnecessary preflight checks
The URL aliasing case (same pmproxy, different hostnames) is actually the most likely failure mode — worth watching for.
Open Questions
- Should the tool accept the raw datasource JSON from mcp-grafana, or just the URL string?
- How to handle URL aliasing (localhost vs hostname vs IP)? Normalize URLs before comparing?
- Should this replace the prompt-driven flow entirely, or augment it (prompt discovers, tool validates)?
The Why
Issue #10 implements Grafana datasource validation as a prompt-driven workflow — Claude calls mcp-grafana tools and compares URLs. This works but is non-deterministic: it relies on Claude correctly executing a multi-step comparison. If this proves unreliable in practice (wrong datasource selected, URL comparison flubbed, etc.), we need a deterministic fallback.
Depends on: #10 (prompt-driven preflight must be tried first)
Context from #10 Design
The #10 design chose "Option A: Prompt-driven preflight" over "Option B: Preflight tool with user-supplied datasource config" because it's simpler and requires no extra configuration. The design explicitly noted:
This issue is that fallback.
Proposed Feature
A new pmmcp tool:
pcp_grafana_preflightConfiguration:
PMMCP_GRAFANA_DATASOURCE_UID— the expected Grafana datasource UID (user pre-configures this)Behaviour:
mcp-grafana.get_datasource(uid)and passes the result topcp_grafana_preflightPMPROXY_URL{ "valid": true/false, "datasource_uid": "...", "pmproxy_url_match": true/false, "details": "..." }Advantages over prompt-driven:
valid: true/falseWhen to Build This
Don't build this proactively. Only implement if:
http://pmproxy:44322vshttp://localhost:44322— same host, different names)The URL aliasing case (same pmproxy, different hostnames) is actually the most likely failure mode — worth watching for.
Open Questions