Доступные инструменты

Сервер dbt MCP предоставляет доступ ко многим возможностям dbt, связанным с разработкой, развертыванием и поиском данных. На этой странице перечислены инструменты, доступные на сервере dbt MCP, и описана их настройка.

Поддерживаемые инструменты по типам серверов MCP

В следующих разделах перечислены все инструменты по категориям с указанием того, какой тип сервера (локальный или удаленный) их поддерживает.

Инструменты	Локальный	Удаленный
Команды dbt	✅	❌
Семантический слой (Semantic Layer API)	✅	✅
SQL	✅	✅
Поиск метаданных (Discovery API)	✅	✅
Административный API (Admin API)	✅	✅
Инструменты генерации кода	✅	❌
Инструменты dbt v2	✅	✅
Инструменты документации продукта	✅	✅
Инструменты метаданных сервера MCP	✅	✅

Обратите внимание: доступ к Discovery API и API Semantic Layer ограничен в зависимости от вашего тарифного плана.

Инструменты удаленного сервера MCP могут изменяться без предварительного уведомления или переходного периода. Подробнее см. в разделе Изменения инструментов на удаленном сервере MCP.

Инструменты, требующие функций ИИ

text_to_sql — единственный инструмент, для работы которого в вашем аккаунте должны быть включены функции ИИ.

Если администратор отключает функции ИИ, text_to_sql не отображается в списке инструментов удаленного сервера MCP. Все остальные инструменты продолжают работать. Отключение функций ИИ не отключает удаленный MCP.

Список инструментов сервера dbt MCP

Приведенный ниже список инструментов доступен для вашего сервера MCP и автоматически загружается из README сервера dbt MCP на GitHub при сборке документации, поэтому он остается актуальным с каждым выпуском.

SQL

Tools for executing and generating SQL on dbt Platform infrastructure.

• execute_sql: Executes SQL on dbt Platform infrastructure with Semantic Layer support.
• text_to_sql: Generates SQL from natural language using project context.

Semantic Layer

To learn more about the dbt Semantic Layer, click here.

• get_dimension_values: Gets distinct values for a dimension; option to scope to specific metrics.
• get_dimensions: Gets dimensions for specified metrics.
• get_entities: Gets entities for specified metrics.
• get_metrics_compiled_sql: Returns compiled SQL for metrics without executing the query.
• list_metrics: Retrieves all defined metrics.
• list_saved_queries: Retrieves all saved queries.
• query_metrics: Executes metric queries with filtering and grouping options.

Discovery

To learn more about the dbt Discovery API, click here.

• get_all_macros: Retrieves macros; option to filter by package or return package names only.
• get_all_models: Retrieves name and description of all models.
• get_all_sources: Gets all sources with freshness status; option to filter by source name.
• get_exposure_details: (deprecated — use get_node_details instead)
• get_exposures: Gets all exposures (downstream dashboards, apps, or analyses).
• get_lineage: Gets a bounded lineage graph with type, depth, and direction filtering.
• get_macro_details: (deprecated — use get_node_details instead)
• get_mart_models: Retrieves all mart models.
• get_model_children: (deprecated — use get_lineage instead)
• get_model_details: (deprecated — use get_node_details instead)
• get_model_health: Gets health signals: run status, test results, and upstream source freshness.
• get_model_parents: (deprecated — use get_lineage instead)
• get_model_performance: Gets execution history for a model; option to include test results.
• get_node_details: Gets full details for any dbt resource type (model, source, exposure, test, seed, snapshot, macro, semantic_model).
• get_related_models: Finds similar models using semantic search.
• get_seed_details: (deprecated — use get_node_details instead)
• get_semantic_model_details: (deprecated — use get_node_details instead)
• get_snapshot_details: (deprecated — use get_node_details instead)
• get_source_details: (deprecated — use get_node_details instead)
• get_test_details: (deprecated — use get_node_details instead)
• search: [Alpha] Searches for resources across the dbt project (not generally available).
• search_public_mesh_models: Finds public dbt Mesh models across projects and confirms producer identity so you can build a verified cross-project ref (multi-project configurations only).

dbt CLI

Allowing your client to utilize dbt commands through the MCP tooling could modify your data models, sources, and warehouse objects. Proceed only if you trust the client and understand the potential impact.

• build: Executes models, tests, snapshots, and seeds in DAG order.
• clone: Clones selected nodes from the specified state to the target schema(s).
• compile: Generates executable SQL from models/tests/analyses; useful for validating Jinja logic.
• docs: Generates documentation for the dbt project.
• get_lineage_dev: Retrieves lineage from local manifest.json with type and depth filtering.
• get_node_details_dev: Retrieves node details from local manifest.json (models, seeds, snapshots, sources).
• list: Lists resources in the dbt project by type with selector support.
• parse: Parses and validates project files for syntax correctness.
• run: Executes models to materialize them in the database.
• show: Executes SQL against the database and returns results.
• test: Runs tests to validate data and model integrity.

Admin API

To learn more about the dbt Administrative API, click here.

• cancel_job_run: Cancels a running job.
• get_job_details: Gets job configuration including triggers, schedule, and dbt commands.
• get_job_run_artifacts: Downloads a specific artifact from a job run; large artifacts return a guidance message to retry with a jq_filter; supports jq filtering for targeted extraction.
• get_job_run_details: Gets run details including status, timing, steps, and artifacts.
• get_job_run_error: Gets error and/or warning details for a job run; option to include or show warnings only.
• list_job_run_artifacts: Lists available artifacts from a job run.
• list_jobs: Lists jobs in a dbt Platform account; option to filter by project or environment.
• list_jobs_runs: Lists job runs; option to filter by job, status, or order by field.
• list_projects: Lists all projects in the dbt Platform account.
• retry_job_run: Retries a failed job run.
• trigger_job_run: Triggers a job run; option to override git branch, schema, or other settings.

dbt Codegen

These tools help automate boilerplate code generation for dbt project files.

• generate_model_yaml: Generates model YAML with columns; option to inherit upstream descriptions.
• generate_source: Generates source YAML by introspecting database schemas; option to include columns.
• generate_staging_model: Generates staging model SQL from a source table.

dbt LSP

A set of tools that leverage the Fusion engine for advanced SQL compilation and column-level lineage analysis.

• fusion.compile_sql: Compiles SQL in project context via dbt Platform.
• fusion.get_column_lineage: Traces column-level lineage via dbt Platform.
• get_column_lineage: Traces column-level lineage locally (requires dbt-lsp via dbt Labs VSCE).

Product Docs

Tools for searching and fetching content from the official dbt documentation at docs.getdbt.com.

• get_product_doc_pages: Fetches the full Markdown content of one or more docs.getdbt.com pages by path or URL.
• search_product_docs: Searches docs.getdbt.com for pages matching a query; returns titles, URLs, and descriptions ranked by relevance. Use get_product_doc_pages to fetch full content.

MCP Server Metadata

These tools provide information about the MCP server itself.

• get_mcp_server_branch: Returns the current git branch of the running dbt MCP server.
• get_mcp_server_version: Returns the current version of the dbt MCP server.

Поиск заданий в разных средах проекта

Вы можете находить задания за пределами производственной среды, в том числе в средах staging, CI или UAT (пользовательского приемочного тестирования), не меняя конфигурацию MCP. Используйте инструмент list_jobs, чтобы получить список заданий. Используйте trigger_job_run, чтобы запустить выполнение.

По умолчанию, если в конфигурации MCP указана производственная среда, list_jobs возвращает задания только из этой среды: x-dbt-prod-environment-id для удаленного MCP с аутентификацией по токену или DBT_PROD_ENV_ID для самостоятельно размещаемого MCP. Подробнее см. в разделе Как найти идентификаторы dbt MCP. Если производственная среда не настроена, list_jobs может возвращать задания из всего аккаунта. Задания из сред staging, CI или UAT часто не отображаются, когда указана производственная среда.

Вы можете передать project_id (полученный через list_projects), чтобы получить задания из всех сред этого проекта.

После вашего запроса ассистент обычно выполняет следующие действия:

1. Находит идентификатор проекта с помощью list_projects (если он вам еще неизвестен)
2. Получает список заданий с этим project_id
3. Выбирает запрошенное вами задание UAT, staging или CI
4. Запускает его с помощью trigger_job_run и идентификатора задания

Вам не нужно вызывать инструменты самостоятельно. Попробуйте такой запрос: «Выведи список заданий этого проекта, найди задание UAT, staging или CI и запусти его».

Изменения инструментов на удаленном сервере MCP

Инструменты dbt MCP в основном предназначены для ИИ-агентов, поэтому их структура может меняться без предварительного уведомления или переходного периода. Не считайте их фиксированным контрактом.

• Мы стремимся не удалять существующие возможности и не переименовывать инструменты, поскольку некоторые клиенты используют имена инструментов для автоматического одобрения или в списках разрешений и запретов.
• Если вам нужен неизменный набор инструментов, входных и выходных данных, рекомендуем закрепить версию самостоятельно размещаемого сервера MCP и запускать его самостоятельно. См. примеры dbt-mcp.

Часто задаваемые вопросы

 Что делает execute_sql?

execute_sql позволяет вашему ИИ-ассистенту выполнять SQL-запросы к вашему хранилищу данных и читать результаты. Он входит в набор инструментов SQL и выполняется на dbt platform, поэтому устанавливать dbt локально не требуется.

Вот что происходит, когда ассистент вызывает этот инструмент:

1. Ассистент пишет SQL-запрос и вызывает execute_sql.
2. Сервер dbt MCP перенаправляет запрос на dbt platform вместе с вашим токеном, идентификатором среды разработки и идентификатором пользователя.
3. dbt platform компилирует SQL (включая любой код Jinja, например ref()) и выполняет его в вашем хранилище, используя ваши учетные данные для разработки.
4. Результаты возвращаются ассистенту в виде таблицы.

ИИ-ассистент вызывает execute_sql. Сервер dbt MCP перенаправляет запрос на dbt platform, где SQL компилируется, выполняется в хранилище с вашими учетными данными для разработки, а результаты возвращаются ассистенту.

 Работает ли execute_sql только в режиме чтения?

Нет. execute_sql не блокирует инструкции записи. Возможности запроса зависят от прав учетных данных хранилища, с которыми он выполняется. Для учетных данных каждого пользователя, применяемых при разработке, используйте роли хранилища с минимально необходимыми правами.

 Чьи учетные данные хранилища использует execute_sql?

Ваши личные учетные данные для разработки в среде разработки проекта, а не учетные данные для развертывания в производственной среде.

Дополнительные ответы на вопросы об execute_sql и помощь в устранении неполадок см. в разделе Часто задаваемые вопросы о dbt MCP и устранение неполадок.

Нашли ошибку?

Создать GitHub Issue