Add tool to get the MCP server version #147
Conversation
| logger.info("Registering meta tools") | ||
| register_meta_tools(dbt_mcp) |
There was a problem hiding this comment.
Should this be behind an env var like the other tools, DISABLE_META_TOOLS? By default, I think this should be disabled.
There was a problem hiding this comment.
My opposite take 😄 is that
- I wouldn't want to add another env var (we already have quite a few)
- using this tool doesn't require any additional config, so I don't think it will do any harm having it On automatically
- Claude Desktop (and I guess other MCP clients) allow deactivating those at the application layer
But those are just my opinions and if it doesn't change yours then I can add an env var 😉
There was a problem hiding this comment.
I still lean toward adding an env var, just to be consistent with the other tools. We can disable it by default, and we can document it in CONTRIBUTING.md instead of README.md since it is meant for debugging. So, it shouldn't add much confusion. I don't think Cursor allows you to disable individual tools.
However, it is up to you, though. I think either approach works.
There was a problem hiding this comment.
Both of your arguments are valid.
It is for debugging, makes sense. And yes, we've been very deliberate and flexible about what tools should be enabled in the first place.
In what scenarios would we need this function?
The most likely scenario I can think of is helping an end-user figure out why a certain piece of functionality does not work or works differently than expected.
The first two questions I'd ask would be:
- What version of the dbt-mcp server are you running
- Show me your config (with redacted API keys)
I'm wondering if that does not point to a different type of print_debug_info kind of tool or maybe even a resource?
For the time being the configuration is kinda manually crafted so the user knows where to find it.
oAuth will come around soon(-ish) and will hopefully wipe away most of this config overhead.
This makes a function like that more interesting.
Should that tool always be available?
Do we want an explicit "debug mode" which brings along this tool (+ others) and maybe more verbose logging?
In that case a ENABLE_DEBUG_MODE flag does make sense, you don't want to confuse the AI and fill the prompt context with tools.
If all we're providing is a get_server_version and end there, I'd see the overhead this tool adds as negligible.
There was a problem hiding this comment.
Yes, I think a tool to print out Cursor/Claude JSON config could be helpful. A tool to dump environment variables could also be helpful. In the near term, I don't think we need to add different logging levels, but that may come up.
b-per
changed the title
When using
uvxto run the server, without pinning the version, it can be difficult to know what actual version we are running.This tool retrieves the version from the package info and give it back to the users when they ask for the dbt MCP server version.