feat(discovery): consolidate 8 get_*_details tools into get_details

[theyostalservice]

Why

The 8 get_*_details Discovery tools (get_model_details, get_source_details, get_exposure_details, get_test_details, get_seed_details, get_snapshot_details, get_macro_details, get_semantic_model_details) are functionally identical — each is a thin wrapper that passes a fixed AppliedResourceType to ResourceDetailsFetcher.fetch_details. Having 8 separate tools means 8 descriptions and schemas sent as context on every turn. Consolidating them into one tool (get_details(resource_type, ...)) cuts 7 tool entries from every request.

What

• Add get_details(resource_type, name, unique_id) that delegates to the existing ResourceDetailsFetcher — the resource_type parameter selects the dispatch path already inside the fetcher
• Remove all 8 individual detail tools and their prompt files
• The resource_type is already encoded in the unique_id prefix (e.g. model.pkg.name), so agents can always infer it without ambiguity
• Update enum/toolset/README mappings; add parametrized unit test

Refs

DI-4002 | Stacks on #817

---

Drafted by Claude Opus 4.8 under the direction of @theyostalservice

[b-per]

Thanks.

Not a review in detail per-se for now, but comments that we'd need to clarify before getting this merged

1. (most important) -- Now that we submitted apps to OpenAI and Anthropic for our MCP server we can't remove tools like we did before. We need a plan and steps to not break the integrations. This will require publishing a new version of the app/integration. I haven't thought about it in details but we might have to "deprecate" some older tools and have them return info that tells me to call the new ones.

2. Instead of get_details, I think that get_node_details might be more relevant. A seed, a model, a test etc... are often referred to as nodes in the dbt framework. That would be a simple rename

[b-per]

There are also a few extra dependencies to this work

1. we'll need to update docs if/when this is merged
2. we will need to update a seed in Internal Analytics to add the new tool

[wiggzz]

Now that we submitted apps to OpenAI and Anthropic for our MCP server we can't remove tools like we did before. We need a plan and steps to not break the integrations. This will require publishing a new version of the app/integration. I haven't thought about it in details but we might have to "deprecate" some older tools and have them return info that tells me to call the new ones.

@b-per do you have more details on this? is this because of tool list caching?

[b-per]

@wiggzz : taken from the OpenAI docs

Treat the metadata exposed by your MCP server as a versioned API contract. When you scan a draft app’s MCP endpoint in the OpenAI Platform Dashboard, OpenAI stores the discovered metadata with that draft version. Submitting the version sends that stored snapshot for review. The snapshot includes:

The tool list, names, titles, and descriptions
Input and output schemas, annotations, and tool security schemes
Tool _meta fields, including UI resource references and visibility
Linked UI resource metadata, including content security policy (CSP) settings
MCP server instructions returned during initialization

Breaking changes to published apps are not currently supported. For example, removing or renaming a tool, making an input schema incompatible, or changing or removing the content served at a published UI resource URI can break the published version as soon as the server change deploys. Instead, make backward-compatible updates:

Add new tools, fields, or UI resources while continuing to honor the published contracts.
Submit the updated metadata as a new app version.
Publish the approved version and keep the old contracts available.

I created a PR a few days ago to catch those "breaking changes".
But while it will catch them, we don't have a process today to promote a version with breaking changes.

[theyostalservice]

@b-per -
If we can't remove the old tools, I don't think this will be useful.

Adding more tools while just saying these are deprecated will only expand the amount of tool context, right?

It seems like deprecation solves for the use case of "the old tool is slow or has a known deficiency," not for our purpose here. Or is there something I'm missing with regards to deprecation?

[theyostalservice]

An, nevermind, I just saw your slack post .