Make server instructions reflect disabled categories#579
Make server instructions reflect disabled categories#579drtootsie wants to merge 4 commits intografana:mainfrom
Conversation
|
|
sd2k
left a comment
sd2k
left a comment
There was a problem hiding this comment.
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.
Addresses grafana#552 The MCP server instructions are now dynamically built based on which tool categories are actually enabled, preventing AI clients from repeatedly attempting to use disabled features. Changes: - Added buildInstructions() method to disabledTools - Added isEnabled() helper to check if a category is enabled - Dynamically builds Prometheus & Loki line based on what's enabled - Omits disabled categories from instructions entirely Example: With --disable-loki, instructions now say: 'Prometheus: Run PromQL queries...' instead of: 'Prometheus & Loki: Run PromQL and LogQL queries...' This significantly improves the client experience by providing accurate capability information upfront.
drtootsie
force-pushed
the
fix-server-instructions-clarity
branch
from
02ee4a2 to
2a7a0a1
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
Any chance this can move forward? The issue affects users who have multiple MCP servers in their environment and tooling might be conflicting. For example, ElasticSearch is advertised through Grafana MCP even though the tool is disabled, all along we have another MCP server that offers working ElasticSearch tool. Agents tend to go for the one in Grafana MCP. |
Replace the duplicate isEnabled switch and separate buildInstructions with a shared toolCategories() method that both addTools and buildInstructions use. This ensures the mapping from disabled flags to category strings is defined in exactly one place, preventing the kind of drift the Cursor Bugbot flagged (missing "examples" case). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Resolve conflicts by incorporating new tool categories from main (elasticsearch, cloudwatch, runpanelquery) and other changes (maxLokiLogLimit) into the unified toolCategories() approach. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add proxied category to toolCategories() with nil addFunc (since proxied tools are registered separately in newServer), so the instruction text appears when proxied tools are enabled. Skip nil addFunc entries in addTools. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
@drtootsie could you please sign the CLA and I can get this merged in? thanks! |
4 participants
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
buildInstructions()method to dynamically build instructionsisEnabled()helper to check category statusExamples
With
--disable-loki: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
Medium Risk
Moderate risk because it refactors tool-category registration into a centralized map and changes how server
WithInstructionsis generated, which could inadvertently omit/incorrectly describe capabilities if the mapping drifts from flags.Overview
Server instructions are no longer hardcoded; they’re now built dynamically from the configured
enabled-toolslist and--disable-*flags viadisabledTools.buildInstructions(), omitting disabled categories and adapting the Prometheus/Loki capability line based on what’s enabled.Tool registration is refactored to use a single
toolCategories()source-of-truth (including category metadata/instruction text) andaddTools()now iterates that list instead of callingmaybeAddToolsper-category.Written by Cursor Bugbot for commit 9d1d0cd. This will update automatically on new commits. Configure here.