Make server instructions reflect disabled categories

[drtootsie]

Addresses #552

Problem

The MCP server instructions were hardcoded and always listed all capabilities, even when categories were disabled. This caused AI clients to repeatedly attempt using disabled features.

Solution

Made instructions dynamic - they now reflect only enabled categories.

Changes

• Added buildInstructions() method to dynamically build instructions
• Added isEnabled() helper to check category status
• Prometheus & Loki line now adapts based on what's enabled
• Disabled categories are completely omitted

Examples

With --disable-loki:

• Before: "Prometheus & Loki: Run PromQL and LogQL queries..."
• After: "Prometheus: Run PromQL queries..."

With --disable-loki --disable-oncall --disable-incident:
Only enabled categories appear in the instructions.

Impact

AI clients now receive accurate capability information upfront, preventing wasted attempts to use disabled features.

---

Note

Low Risk
Changes only the human/AI-facing instructions string generation; tool registration and request handling are untouched, so impact is limited to messaging correctness.

Overview
Server startup instructions are no longer hardcoded: cmd/mcp-grafana/main.go now builds the MCP WithInstructions text dynamically from the enabled/disabled tool categories.

Adds disabledTools.isEnabled() and buildInstructions() to omit disabled capabilities entirely and to tailor the Prometheus/Loki wording based on which of those categories are enabled.

^{Written by Cursor Bugbot for commit 02ee4a2. This will update automatically on new commits. Configure here.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Pepper Pancoast seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sd2k]

I agree that we should do this but I don't like defining another isEnabled function with lots of untyped strings. We already do 'stuff' conditional on each flag being enabled in addTools. I think we could change that to processTools, and wrap each call to maybeAddTools in a function that also builds up the instruction string; that way we only have a single place mapping fields of disabledTools to strings representing the flag.