dlt（数据加载工具）是一个开源的 Python 库，用于将 API 和数据库中的数据加载到数据仓库或湖仓中。dltHub（付费平台）在 dlt 的基础上扩展了面向编码代理需求的企业级功能：数据转换、数据质量验证、托管运行时基础设施、托管数据应用，以及 AI 驱动的工作区环境。
dltHub AI Harness 是一组工具包，为 AI 编码助手提供使用 dlt 构建数据管道的分步工作流。您可以按原样使用该工具集，也可以分叉并针对自己的技术栈进行定制。dlthub ai CLI 会将工具包组件安装到您的助手的正确位置，并运行工作区 MCP 服务器。
构建工具包涵盖数据摄取（REST API、SQL）、数据转换和数据质量；运行工具包负责部署和探索。REST API 工具包由 dltHub context 提供支持——代理在编写代码之前会查询超过 9,700 个源定义，以找到经过验证的连接器。新用户可以从 quick-start 工具包开始，获得从数据到仪表板的引导式端到端运行体验。
dltHub AI Harness 已通过 Claude Code、Cursor 和 Codex 测试，也可能适用于其他 AI 编码助手。我们建议在 accept edits（Claude）/ --approval-mode（Codex）模式下工作以审查更改，并在开始使用 dlthub AI Harness 时熟悉 dlthub AI 工作流。
构建数据管道是迭代式的，涵盖两个主要阶段——摄取和转换——每个阶段都遵循相同的内部循环：
构建（本地开发）
迭代式开发管道——对于摄取：先开发第一个 REST API 端点，然后添加其他端点；对于转换：先设计数据模型，然后构建完整的转换管道
在每一步之后探索已加载的数据并验证
循环回退并优化，直到管道稳定可靠
运行（生产环境）
将摄取或转换管道部署到生产环境
通过基于已加载数据构建的数据应用提供洞察
外部循环连接两个阶段：来自转换和服务层的洞察反馈到摄取优化中。工具集的构建工具包支持本地开发循环；运行工具包负责部署和数据应用。
Related MCP server: Agentled MCP Server
该工具集为您的编码助手提供工具包——其中包含针对特定阶段的、结构化的引导式工作流。助手不会生成临时拼凑的代码，而是从头到尾遵循一系列明确的步骤。
一个工具包包含技能、命令、规则和一个 MCP 服务器——通过一个工作流将它们串联起来，该工作流告诉助手在每一步运行哪个技能以及如何利用 MCP。
所有工具包都依赖 init 来提供共享规则、密钥处理以及 MCP 服务器。使用 dlthub ai CLI 时，init 会作为依赖项自动安装。使用 Claude 市场时，请单独安装 init 插件。
组件 | 它是什么 | 何时运行 |
技能（Skill） | 助手遵循的分步流程 | 由用户意图触发，或通过 |
命令（Command） | 用于特定操作的斜杠命令 | 用户通过 |
规则（Rule） | 始终生效的上下文（约定、约束） | 每个会话自动加载 |
工作流（Workflow） | 具有固定入口点的有序技能序列 | 作为规则加载——始终生效 |
MCP 服务器 | 将管道、表和密钥作为工具暴露 | 在会话期间，通过 MCP 协议 |
超过 9,700 个 REST API 源定义，包含经过验证的连接器和管道模式 | 在源发现期间，通过 |
两个 MCP 服务器在整个工作流中为代理提供结构化上下文，避免手动复制粘贴的需要。
dlt-workspace-mcp（本地，由 dlthub ai init 安装）暴露：数据检查工具（list_tables、preview_table、execute_sql_query、get_row_counts、display_schema、get_local_pipeline_state）、密钥工具（secrets_view_redacted、secrets_update_fragment）以及工具包发现（list_toolkits、toolkit_info）。
dltHub context（远程）提供 search_dlthub_sources——由 find-source 技能使用，用于搜索超过 9,700 个 REST API 源定义，并在编写代码之前返回带有参考链接的经过验证的连接器。
工具包 | 阶段 | 工作流入口 | 功能 | 示例提示 | 可用性 |
| 设置 |
| 3–5 个提示即可完成从数据到仪表板的引导式端到端运行；根据所选深度路由到正确的入口技能 | "使用 quick-start 带我完成使用 GitHub API 的完整工作流" | 运行 |
| 设置 |
| 检查 | "运行 /init-workspace 以设置带 dlthub 的 Python 环境" | 亲自试试！运行 |
| 构建 |
| 搭建、调试和验证 REST API 摄取管道 | "使用 find-source 将 Stripe API 的数据加载到 DuckDB" | 亲自试试！运行 |
| 构建 |
| 搭建、调试和验证 SQL 数据库摄取管道 | "使用 find-source 将我的 Postgres 数据库中的表加载到 DuckDB" | 运行 |
| 构建 |
| 从本地磁盘、S3、GCS、Azure 或 SFTP 加载文件（CSV、Parquet、JSONL 或自定义格式）到目标位置 | "使用 create-filesystem-pipeline 将我的 S3 CSV 文件加载到 DuckDB" | |
| 探索 |
| 查询已加载的数据并创建 marimo 仪表板 | "使用 explore-data 探索我的 Stripe 管道并创建仪表板" | 亲自试试！运行 |
| 运行 |
| 将管道部署到 dltHub 平台 | "使用 setup-runtime 将我的管道部署到 dltHub" | |
| 转换 |
| 设计规范数据模型（CDM）并从现有管道编写 dlthub 转换函数 | "使用 annotate-sources 开始从我的 HubSpot 和 Luma 管道构建 CDM" | |
| 构建 |
| 在 dlt 管道数据上定义、运行和审查数据质量检查与指标 | "使用 setup-data-quality 为我的 Stripe 管道添加验证检查" | |
| 构建 |
| 调优缓慢或内存占用高的管道——诊断瓶颈阶段并应用并行、工作进程、缓冲区和批处理 | "使用 optimize-performance 加速我的 Postgres 管道" |
init是一个共享依赖项，提供规则、密钥处理和 MCP 服务器。它由dlthub ai init自动安装，或作为独立插件通过 Claude 市场安装。
要设置一个带有 AI 支持的干净的新 dlthub 项目，请运行 dlthub-init。它是非交互式的且支持 AI，因此您的编码助手可以为您运行它——这是代理应使用的命令，用于设置一个干净的新 dlthub 项目。它通过捆绑的锁文件固定 dlt[hub] 版本并运行 uv sync：
uvx dlthub-init@latest <dir> # scaffold a clean new project into <dir>要将 AI 工具集添加到现有项目，请在原地运行相同的 dlthub-init。它使用逐文件冲突处理（合并 pyproject.toml，绝不覆盖 secrets.toml，合并 .gitignore），固定 dlt[hub] 版本，并运行 uv sync——而且由于它是非交互式的，您的编码助手可以为您运行它：
uvx dlthub-init@latest # set up AI support in the current directory手动步骤（备选）： 如果您更愿意逐步操作，或者 dlthub-init 不可用：
注意： 下面所有的
dlthub ai命令都使用uv run dlthub ...语法。如果你已在全局或当前虚拟环境中安装了dlthub，则可以省略uv run并直接调用dlthub。我们建议使用 uv。
# Initialize the environment
uv init
# Install dlthub
uv add "dlt[hub]"
# Initialize the dlthub workspace and follow its instructions (most importantly `uv sync`)
uv run dlthub init
# Set up AI support (auto-detects your coding assistant)
uv run dlthub ai init
# If multiple coding assistants are detected, specify one explicitly:
uv run dlthub ai init --agent <agent> # <agent>: claude | cursor | codexdlthub ai init 会从环境变量和配置文件中检测你的编码助手，然后将技能、规则和 MCP 服务器安装到该工具的相应位置。
Claude Code 注意： 将以下内容添加到你的
CLAUDE.md中，以强制实施安全的凭据处理：CRITICAL: never ask for credentials in chat. Always let the user edit secrets directly and do not attempt to read them.
Cursor 注意： 运行命令后，请在 Cursor Settings > MCP 中手动启用 dlt-workspace-mcp 服务器。将以下内容添加到你的
.cursor/rules/security.mdc中，以强制实施安全的凭据处理：CRITICAL: never ask for credentials in chat. Always let the user edit secrets directly and do not attempt to read them.
Codex 注意： Codex 不支持命令和规则，因此安装程序会将这些内容转换为技能和 AGENTS.md。Codex 还在严格沙箱中运行——请考虑在项目或全局配置中启用网络访问：
# .codex/config.toml web_search = "live"将以下内容添加到你的
AGENTS.md中，以强制实施安全的凭据处理：CRITICAL: never ask for credentials in chat. Always let the user edit secrets directly and do not attempt to read them.
刚接触 dltHub，只想尝试或学习它？请亲自运行 dlthub-start —— 它会搭建一个全新的试用工作区（不用于生产，也不用于设置真实项目）：
uvx dlthub-start@latest请亲自运行——不要让你的编码助手代劳。
uvx dlthub-start必须由真人运行，因为它需要交互以进行身份验证；它只能在真实终端中运行（不能在!模式下运行）。对于由智能体驱动的设置，请使用上面的dlthub-init。
还没有配置好 dlthub？ 请先按照上面的 新项目 或 现有项目 操作（或使用
bootstrap工具包的/init-workspace，该命令可由助手驱动）。下面的工具包命令假定你的环境中已安装dlthub。
uv run dlthub ai toolkit list安装工具包（如果你不确定要安装哪些工具包，我们建议全部安装）：
uv run dlthub ai toolkit install quick-start
uv run dlthub ai toolkit install bootstrap
uv run dlthub ai toolkit install rest-api-pipeline
uv run dlthub ai toolkit install sql-database-pipeline
uv run dlthub ai toolkit install filesystem-pipeline
uv run dlthub ai toolkit install dlthub-platform
uv run dlthub ai toolkit install data-exploration
uv run dlthub ai toolkit install transformations
uv run dlthub ai toolkit install data-quality
uv run dlthub ai toolkit install performance使用上方 可用工具包 表格中的示例提示之一来启动工作流。
Claude Code —— 通过终端中的 claude 启动新会话。安装后重新启动，以便技能和 MCP 生效。
Cursor —— 在 Cursor 中打开项目，并使用聊天面板（Cmd+L）。已安装的技能和规则会自动加载。
Codex —— 通过 codex 启动 Codex CLI，或在 UI 中使用 Codex 聊天。设置完成后重新启动 Codex，以使 MCP 服务器生效。
早期访问： Claude Code 插件目前处于早期访问阶段，可能无法在不同工具包之间提供最佳的衔接体验。如果你是 dltHub 新手，想尝试或学习它，请参阅 首次入门 —— 你需要亲自运行
uvx dlthub-start@latest。当你希望通过bootstrap工具包从 Claude Code 内部初始化一个现有/空项目时，下面的市场路径会很有用（该工具包优先使用uvx dlthub-init@latest—— 这是一种可由智能体运行的命令，用于配置一个干净的全新或现有 dlthub 项目 —— 并回退到就地安装步骤）。
该 harness 也可通过市场作为 Claude Code 插件使用。启动一个 Claude Code 会话并运行：
/plugin marketplace add dlt-hub/dlthub-ai-harness
/plugin install init@dlthub-ai-harness --scope project
/plugin install quick-start@dlthub-ai-harness --scope project
/plugin install bootstrap@dlthub-ai-harness --scope project
/plugin install rest-api-pipeline@dlthub-ai-harness --scope project
/plugin install sql-database-pipeline@dlthub-ai-harness --scope project
/plugin install dlthub-platform@dlthub-ai-harness --scope project
/plugin install data-exploration@dlthub-ai-harness --scope project
/plugin install transformations@dlthub-ai-harness --scope project
/plugin install data-quality@dlthub-ai-harness --scope project启动一个新会话 —— 插件只有在重新启动 Claude Code 后才会生效：claude
正在恢复会话？ 在会话中途安装的插件在启动新会话之前不会生效。
dlthub ai 命令行工具dlthub ai 子命令是 harness 与你的编码助手之间的桥梁。dlthub ai init 会安装项目规则、一个机密管理技能、适当的忽略文件，并为你的智能体配置 dlt MCP 服务器。dlthub ai toolkit install 会将额外的工具包组件（技能、规则、命令）复制到你的助手的正确位置。
工具包管理 —— 将技能、规则、命令和 MCP 配置从 harness 复制到你的项目的智能体配置目录（.claude/、.cursor/、.agents/ 等）：
uv run dlthub ai status # show installed agent, dlthub version, active toolkits
uv run dlthub ai toolkit list # list available toolkits from the harness
uv run dlthub ai toolkit info <name> # show a toolkit's skills, commands, and workflow
uv run dlthub ai toolkit install <name> # install a toolkit for the detected agent
uv run dlthub ai toolkit install <name> --agent <agent> # <agent>: claude | cursor | codex - override agent detection机密管理 —— dlt 将凭据存储在 TOML 文件中；这些命令让助手无需读取原始机密值即可检查和更新这些凭据：
uv run dlthub ai secrets list # show which secret files exist and where
uv run dlthub ai secrets view-redacted # print secrets with values masked
uv run dlthub ai secrets update-fragment --path <file> '<toml>' # merge a TOML snippet into a secrets fileMCP 服务器 —— 启动一个本地服务器，将你的 dlthub 工作区（管道、模式、表、机密）作为可供助手调用的工具暴露出来：
uv run dlthub ai mcp run # run in SSE mode (default)
uv run dlthub ai mcp run --stdio # run in stdio mode (for assistants that require it)
uv run dlthub ai mcp install # register the MCP server in the agent's configMCP 服务器让助手能够回答诸如“加载了哪些表？”或“显示 schema”之类的问题，而无需你将输出复制粘贴到聊天中。
本项目采用 dltHub AI Harness License 许可。
Execute a read-only SQL query against the pipeline's destination dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| output_format | No | Output format: 'markdown' or 'jsonl' | markdown |
| pipeline_name | Yes | ||
| sql_select_query | Yes | SQL SELECT query to execute (only SELECT is allowed) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'read-only', which is critical, but does not mention performance, error handling, or limitations beyond SELECT. More detail would benefit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word is necessary and contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is almost complete. It covers the essential read-only nature and target dataset. The presence of an output schema likely covers return values. Pipeline_name is left unexplained, but overall sufficient for a clear tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 parameters have descriptions). The tool description adds context that aligns with the schema's SELECT restriction but does not clarify the missing pipeline_name parameter or further explain output_format. Description adds marginal value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute', resource 'SQL query', and scope 'read-only against the pipeline's destination dataset'. It distinguishes itself from sibling tools which are primarily schema inspection and pipeline management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for executing read-only SQL queries, and the input schema restricts to SELECT. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, though siblings are different enough that confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the pipeline schema as a diagram or structured dump.
| Name | Required | Description | Default |
|---|---|---|---|
| schema_name | No | ||
| hide_columns | No | Hide column details for better readability of large schemas | |
| save_to_file | No | Save the schema to this file path instead of returning it. Use an absolute path (e.g. /home/user/schema.yaml). | |
| output_format | No | Output format: 'mermaid', 'yaml', or 'dbml' | mermaid |
| pipeline_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not state whether the operation is read-only, if save_to_file overwrites existing files, or how output is returned. The term 'export' implies non-destructive but no explicit safety guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it lacks essential details about tool behavior and parameters. It is not feature-complete enough to be considered effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description is insufficient. It omits key details like output formats, filtering by schema_name, hiding columns, and saving to file. The description fails to provide a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about any of the five parameters. Schema coverage is 60% but the description does not explain the optional schema_name, hide_columns, save_to_file, or output_format parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'export' as the action and 'pipeline schema' as the resource. It mentions two output types ('diagram or structured dump') which distinguishes this tool from sibling tools like get_table_schema that focus on individual table schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_table_schema, execute_sql_query). No contexts, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pipeline state: incremental cursors, resource state, and source state.
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It reveals the returned state categories but does not mention whether the operation is read-only, requires permissions, or has side effects. The name implies read-only, but the description does not confirm safety or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no irrelevant words. It front-loads the purpose and key output details, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, output schema exists), the description adequately explains the output structure. It could be improved by noting error conditions or prerequisite checks, but it is sufficiently complete for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (pipeline_name, required) with 0% description coverage. The description adds no meaning or constraints to this parameter beyond its name, failing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get pipeline state') and specifies the content ('incremental cursors, resource state, and source state'), distinguishing it from sibling tools like 'list_pipelines' which list all pipelines. It is specific but does not explicitly differentiate from other getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., pipeline existence), or when not to use it. This leaves the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get row counts for all data tables in a pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| output_format | No | Output format: 'markdown' or 'jsonl' | markdown |
| pipeline_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not mention read-only nature, performance impact, or any side effects. Basic transparency about safety is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, which is efficient. However, it could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values are covered. But description lacks details like what constitutes a 'data table', ordering, or limits. Adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only output_format has description). The description adds no detail on pipeline_name (e.g., format, source) and does not clarify how it identifies the pipeline. Minimal added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get row counts for all data tables in a pipeline' clearly states the verb (get) and resource (row counts for all data tables) and distinguishes it from sibling tools like list_tables or get_table_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like execute_sql_query or list_tables. The description implies use for row counts, but lacks exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CREATE TABLE DDL for the table in the destination's SQL dialect.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | ||
| pipeline_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether the tool is read-only (likely safe), requires specific permissions, or has side effects. The description is minimal and lacks transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of missing important details like parameter explanations. For a tool with two parameters, it could be slightly expanded to include parameter context while remaining short. It is front-loaded with the action but lacks completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required params, no nested objects), the description provides some context (destination SQL dialect) but does not explain the output or how the DDL relates to the pipeline. While an output schema exists, the description could still mention that the result is a SQL DDL statement. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add meaning to the two parameters. It does not explain valid values for 'pipeline_name' or 'table_name', nor does it clarify if 'table_name' should include a schema prefix. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get'), the resource ('CREATE TABLE DDL'), and the context ('for the table in the destination's SQL dialect'). It distinguishes from siblings like 'get_table_schema' (which returns schema structure, not DDL) and 'execute_sql_query' (which runs arbitrary SQL).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contexts. For example, it does not indicate that this tool is ideal for obtaining the exact DDL for replication or migration purposes, or when 'get_table_schema' might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get table schema with column names, data types, and escaped sql_identifier fields.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | ||
| pipeline_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states what is returned, omitting behavioral traits like whether the schema is live or cached, performance implications, or any required permissions. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous words. Front-loaded with the core action and output details. Every part earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are documented. However, the description lacks context on how the schema relates to the pipeline, error conditions, or usage with sibling tools. Adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not describe 'pipeline_name' or 'table_name', leaving their purpose implied by naming. Adds little value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving table schema with specific fields (column names, data types, escaped sql_identifier). This distinguishes it from siblings like 'get_table_create_sql' or 'export_schema'. However, it could explicitly differentiate from 'list_tables' and 'preview_table'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. Usage is implied: use when you need schema information before querying. No alternatives are mentioned, but the purpose is self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get workspace info: name, directories, active profile, and config providers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It indicates a read operation (get) and lists outputs, but does not disclose any side effects, idempotency, or error conditions. However, for a simple getter, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and output list. No extraneous words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description sufficiently covers what the tool does and returns. Given its simplicity, no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, schema coverage is 100%. The description adds value by enumerating the output fields, which provides context beyond the empty input schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves workspace info and lists specific attributes (name, directories, active profile, config providers), making it distinct from sibling tools like list_profiles (which lists profiles) or toolkit_info (which gets toolkit info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of prerequisites, exclusions, or scenarios where other tools might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all dlt pipelines available in this workspace
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, authentication needs, or result characteristics. It simply restates the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys exactly what the tool does with no wasted words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, straightforward list operation) and the presence of an output schema, the description provides sufficient context to understand its purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially). Per the rubric, a baseline of 4 is assigned when there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'dlt pipelines available in this workspace', making the purpose unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives is provided, but the simplicity of the tool (listing all pipelines) makes usage implicitly clear. There are no sibling tools that serve the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available workspace profiles with status flags (current, pinned, configured).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation listing profiles with flags, with no indication of side effects or destructive behavior. It could specify pagination or caching behavior but is otherwise clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the key action and resource, no unnecessary words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description fully specifies what the tool does. It names the resource and the included status flags, which is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema description coverage is 100% (empty schema). Per guidelines, baseline is 4 for 0 parameters. The description does not need to add param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all available workspace profiles') with additional detail about the status flags included. It clearly distinguishes from sibling list tools (e.g., list_tables, list_pipelines) by the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the action but does not provide context on when to use this tool versus alternatives, nor does it mention prerequisites or post-conditions. For a simple listing tool, this is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all data tables for a pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior like error handling, ordering, or safety. It only states the basic function, leaving the agent unaware of potential outcomes (e.g., empty list, pipeline not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words), with no wasted words. However, it could be slightly expanded to include key details without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (unspecified), the description need not detail return values. Still, it lacks context about typical use cases and error scenarios, making it barely adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameter semantics. It implies 'pipeline_name' but provides no details on format, constraints, or valid values, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all data tables') and clearly indicates the scope ('for a pipeline'). It distinguishes well from siblings like get_table_schema or preview_table, which operate on individual tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives (e.g., get_table_schema for schema details). Prerequisites (e.g., pipeline existence) and typical usage context are omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available dlt AI toolkits with their names and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It indicates a read operation ('List'), but does not disclose any additional behavioral traits such as required permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys all necessary information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, output schema exists), the description is complete. It tells the agent what it does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params), so the schema coverage is 100%. The description does not need to add parameter info. Per rubric, baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('dlt AI toolkits'), and the returned data ('names and descriptions'). It distinguishes from sibling 'toolkit_info' which provides details on a specific toolkit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are given. However, the purpose is straightforward, and usage is implied as an overview listing, with sibling tools like 'toolkit_info' for detailed queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the first 10 rows from a table.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | ||
| output_format | No | Output format: 'markdown' or 'jsonl' | markdown |
| pipeline_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it returns the first 10 rows, but does not disclose whether it is read-only, if authentication is needed, or any side effects. For a data retrieval tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It could be improved by adding context without excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. However, it lacks information about ordering, pagination, or behavior for empty tables. For a simple preview tool, it is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (output_format has a description). The description does not explain the required parameters 'pipeline_name' and 'table_name'. It adds no additional meaning beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'first 10 rows from a table'. It distinguishes itself from sibling tools like 'execute_sql_query' which runs arbitrary SQL, and 'get_table_schema' which returns schema, by specifying a preview of data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention limitations, prerequisites, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for available dlt sources on dlthub by name or description.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term to find sources by name or description. Empty string returns all sources alphabetically. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only says 'Search', implying read-only, but does not explicitly state side effects, auth requirements, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler, achieving maximum conciseness while still conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and an output schema, the description is adequate. It could optionally mention the return format, but the existence of an output schema minimizes the need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the single parameter 'query' is already detailed and covers coverage at 100%. The tool description adds minimal additional meaning beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search', the resource 'available dlt sources on dlthub', and the method 'by name or description'. It is specific and distinguishes from sibling tools that deal with SQL, schema, or pipeline state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without indicating when it is appropriate or when another tool might be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List secret file paths, profiles, and whether each file exists.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, but the description does not disclose behavioral traits like authentication requirements, side effects, or error handling. It only states what is listed without deeper context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's function. It is front-loaded and concise with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has zero parameters and an output schema (not shown). The description covers the essential aspects of what the tool lists, so it is complete enough for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and schema description coverage is 100%, so the description adds no parameter info beyond the schema. Baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists secret file paths, profiles, and existence status. This is a specific verb+resource combination, distinct from sibling tools like secrets_update_fragment or secrets_view_redacted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to use list vs view vs update secrets. There is no mention of context or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep-merge a TOML fragment into a secrets file; returns the redacted result. The file is created if it does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the secrets file to update (from secrets_list). | |
| fragment | Yes | TOML fragment to deep-merge into the secrets file |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the merge behavior and file creation, but does not detail permissions, side effects, error cases, or merge conflict resolution. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with the primary action and key outcome. Extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, description need not explain return values. It covers creation behavior and redacted output. Could mention idempotency or error handling, but overall sufficient for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaningful context: path is 'from secrets_list' and fragment is for 'deep-merge'. This enriches the schema descriptions, helping the agent understand source and operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Deep-merge a TOML fragment'), the resource ('secrets file'), and key results ('returns the redacted result; file created if not exists'). It distinguishes from siblings like secrets_list and secrets_view_redacted which are read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating or creating secrets files but does not explicitly guide when to use this tool over alternatives. No exclusion conditions or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show secrets TOML with every value replaced by '***'.
Without path: returns the unified merged view across all project secret files (read-only, shows effective configuration). With path: returns that single file redacted. Use secrets_list to discover file paths.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute path to a specific secrets file (from secrets_list). Omit to get the unified merged view of all secret files. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains that the tool is read-only, returns redacted content, and provides a unified merged view. No contradictions or missing behavioral details for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value. Front-loaded with main action. No redundant information. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, no need to describe return values. Mentions related tool secrets_list. Complete for a read-only tool with one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with path parameter described. Description adds meaning: optional, absolute path required if used, omission gives unified view. This goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it shows secrets TOML with values replaced by '***', and distinguishes between with and without path. Sibling tools include secrets_list and secrets_update_fragment, so purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use with path vs without path, and references secrets_list for file paths. However, no explicit when-not-to-use or alternatives beyond the one sibling mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show detailed contents of a dlt AI toolkit.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the toolkit to inspect |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| tags | Yes | |
| rules | Yes | |
| skills | Yes | |
| version | Yes | |
| commands | Yes | |
| has_ignore | Yes | |
| description | Yes | |
| mcp_servers | No | |
| dependencies | No | |
| workflow_entry_skill | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description should disclose behavioral traits. It does not mention side effects, read-only nature, or any other behavioral aspects beyond a simple retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence, no wasted words. However, it could be expanded slightly to include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, output schema present), the description is minimally adequate. But considering sibling tools and lack of usage guidance, it's not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the single parameter. The tool description adds no additional semantic meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Show' and the resource 'detailed contents of a dlt AI toolkit', distinguishing it from sibling tools like 'list_toolkits' which likely provide summaries, not details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_toolkits or other inspection tools. Missing context about prerequisites or typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0execute_sql_queryexport_schemaget_local_pipeline_stateget_row_countsget_table_create_sqlget_table_schemaget_workspace_infolist_pipelineslist_profileslist_tableslist_toolkitspreview_tablesearch_dlthub_sourcessecrets_listsecrets_update_fragmentsecrets_view_redactedtoolkit_infoScored across 17 tools
Each tool has a clearly distinct purpose: SQL queries, schema export, pipeline state, row counts, table DDL, table schema, workspace info, pipeline listing, profiles, tables, toolkits, preview, source search, and secrets management. No significant overlap.
All tool names follow a consistent verb_noun snake_case pattern (e.g., execute_sql_query, list_pipelines, secrets_update_fragment). No mixing of conventions.
17 tools is well-scoped for a dlt pipeline workbench, covering schema, state, secrets, and workspace information without being overwhelming.
Covers most exploration and configuration needs, but lacks pipeline execution or creation tools, which could be a gap for an AI workbench.
Remote data science agents for Snowflake, Databricks & BigQuery in Claude/Cursor via MCP
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
