feat: add MCP tool to expose server version

[b-per]

Previous implementation with a resource

Summary

Add a resource at dbt://server/version that returns the current
dbt-mcp server version. This allows clients to discover the server
version through MCP's resource discovery mechanism rather than
needing a tool call.

The version is retrieved from package metadata at runtime, falling
back to "unknown" if the package metadata cannot be read.

Testing

I tested it with mcpc:

❯ mcpc --config .mcpc.json dbt-mcp  resources-read dbt://server/version
[→ uv run --env-file .env dbt-mcp (stdio)]
contents: [
  {
    "uri": "dbt://server/version",
    "mimeType": "text/plain",
    "text": "1.7.0"
  }
]

Summary

Add a tool to get the version of the dbt MCP server

It can be useful to troubleshoot the MCP server (e.g. why some tools don't appear etc...)

[DevonFulcher]

Is this primarily for bug reporting and debugging?

[b-per]

Is this primarily for bug reporting and debugging?

Yes. You don't like the idea?

[DevonFulcher]

@b-per I think it is a bit untraditional. For MCP, resources typically refer to items in a filesystem or a similar system. Referring to this repo, resources are supported in most major clients, but not all. How does this appear in a client like Cursor or Claude? Does the UX get in the way when users aren't debugging their dbt MCP setup? Could you provide a screenshot?

I wonder if there is a different way we could get this information, for instance, by adding uvx dbt-mcp --version. Also, uvx keeps code running locally relatively up-to-date. If we suspect someone is on an older version, we just need to have them run uv cache clean. Do you run into a lot of issues with users on older clients?

[b-per]

Here is a screenshot in Claude Desktop

Which then "loads" an object with this content

You are right that it doesn't really look right.

---

What I wanted to achieve was mostly be able to compare the version running now (local MCP or remote MCP) with the latest releases. Because there is a delay between the moment we do a release and the moment it is available in the remote MCP I thought it could help people troubleshoot.

As we just saw that a resource is likely not what we want, would it be OK to create a tool instead to be able to retrieve this information?

[jairus-m]

Not to throw a wrench in the convo, but the MCPB work necessitated a bespoke/adhoc way to retrieve the version number of this package in order to keep the manifest.json's semantic version in sync with the project.

I'm wondering if there could be work to standardize an internal function/module such that we can both use it in the MCPB script as well as surface the CLI flag to the user: dbt-mcp --version

Edit: Oh, realizing that not all use of the MCP will make a CLI flag possible. Now I understand the tool call aspect

[b-per]

Not to throw a wrench in the convo, but the MCPB work necessitated a bespoke/adhoc way to retrieve the version number of this package in order to keep the manifest.json's semantic version in sync with the project.

Changing a bit topics, but shouldn't we update the logic you added to MCPB with the builtin import/function

from importlib.metadata import version

[DevonFulcher]

@jairus-m @b-per I think adding a tool for this would be okay if it were off by default. Is there any other debug information that we would want this tool to provide?

Unfortunately, I understand the issue you are referring to with certain clients not working with CLI arguments, @jairus-m. Another option would be to create a separate entrypoint: uvx dbt-mcp-debug --version.

edit: I just realized that uv tool list displays package version numbers, so perhaps that would solve for your use case, @b-per? You can also force a specific version: uvx dbt-mcp@1.7.0

[b-per]

edit: I just realized that uv tool list displays package version numbers, so perhaps that would solve for your use case, @b-per? You can also force a specific version: uvx dbt-mcp@1.7.0

But that is just part of the use case.
I am personally interested in getting this info for the remote MCP server (where we don't give the ability for folks to choose the version to use)

[b-per]

• added a new toolset mcp_server_metadata
• toolset is off by default
• 1 tool in the toolset (currently) called get_mcp_server_version

[b-per]

I was also thinking that in the future we could expend the mcp_server_metadata toolset with things like:

• list of toolsets/tools (and if they are activated/deactivated based on the current config)
• potentially some troubleshooting tool (like getting back some logs etc...)

This could maybe be used for LLMs to self troubleshoot why the MCP server is not working as expected and what config changes are required to make it work.

[DevonFulcher]

@b-per Nice I like that idea!

[DevonFulcher]

Nice! I think we should update this PR title.