dlt (data load tool) es una biblioteca Python de código abierto para cargar datos desde APIs y bases de datos a un warehouse o lakehouse. dltHub (plataforma de pago) amplía dlt con funciones de nivel empresarial adaptadas a las necesidades de los agentes de codificación: transformaciones, validación de calidad de datos, infraestructura de ejecución gestionada, data apps gestionadas y un entorno de workspace con IA.
El dltHub AI Harness es una colección de toolkits que proporcionan a los asistentes de codificación con IA flujos de trabajo paso a paso para crear pipelines de datos con dlt. Puedes usar el harness tal cual o hacer un fork y personalizarlo para tu propio stack. La CLI de dlthub ai instala los componentes de los toolkits en las ubicaciones correctas para tu asistente y ejecuta el servidor MCP del workspace.
Los toolkits de Build cubren la ingesta (REST API, SQL), la transformación y la calidad de datos; los toolkits de Run gestionan el despliegue y la exploración. El toolkit de REST API está respaldado por el contexto de dltHub: más de 9.700 definiciones de fuentes que el agente consulta para encontrar conectores verificados antes de escribir código. Los nuevos usuarios pueden empezar con el toolkit quick-start para un recorrido guiado de principio a fin, desde los datos hasta el dashboard.
El dltHub AI Harness está probado con Claude Code, Cursor y Codex, y puede funcionar con otros asistentes de codificación con IA. Recomendamos trabajar en modo accept edits (Claude) / --approval-mode (Codex) para revisar los cambios y familiarizarse con los flujos de trabajo de dlthub AI al empezar con el dltHub AI Harness.
La creación de pipelines de datos es iterativa y abarca dos fases principales — ingesta y transformaciones — cada una siguiendo el mismo bucle interno:
Build (desarrollo local)
Desarrolla el pipeline de forma iterativa — para la ingesta: primero el endpoint de REST API, luego endpoints adicionales; para la transformación: primero el modelo de datos, luego el pipeline de transformación completo
Explora los datos cargados y valídalos después de cada paso
Vuelve a iterar para refinar hasta que el pipeline sea sólido
Run (producción)
Despliega el pipeline de ingesta o transformación a producción
Ofrece insights mediante data apps construidas sobre los datos cargados
El bucle externo conecta las dos fases: los insights de la capa de transformación y de servicio retroalimentan el refinamiento de la ingesta. Los toolkits de Build del harness admiten el bucle de desarrollo local; los toolkits de Run gestionan el despliegue y las data apps.
Related MCP server: Agentled MCP Server
El harness proporciona a tu asistente de codificación toolkits — que contienen un flujo de trabajo estructurado y guiado para una fase específica. En lugar de generar código ad-hoc, el asistente sigue una secuencia definida de pasos de principio a fin.
Un Toolkit contiene skills, comandos, reglas y un servidor MCP — unidos por un workflow que le indica al asistente qué skill ejecutar en cada paso y cómo aprovechar el MCP.
Todos los toolkits dependen de init para las reglas compartidas, el manejo de secretos y el servidor MCP. Al usar la CLI de dlthub ai, init se instala automáticamente como dependencia. Al usar el marketplace de Claude, instala el plugin init por separado.
Componente | Qué es | Cuándo se ejecuta |
Skill | Procedimiento paso a paso que sigue el asistente | Se activa por intención del usuario o explícitamente con |
Command | Un comando de barra para una acción específica | El usuario lo invoca con |
Rule | Contexto siempre activo (convenciones, restricciones) | Cada sesión, automáticamente |
Workflow | Secuencia ordenada de skills con un punto de entrada fijo | Se carga como regla — siempre activo |
MCP server | Expone pipelines, tablas y secretos como herramientas | Durante una sesión, mediante el protocolo MCP |
Más de 9.700 definiciones de fuentes REST API con conectores verificados y patrones de pipeline | Durante el descubrimiento de fuentes, mediante |
Dos servidores MCP proporcionan al agente contexto estructurado a lo largo del flujo de trabajo para evitar la necesidad de copiar y pegar manualmente.
dlt-workspace-mcp (local, instalado por dlthub ai init) expone: herramientas de inspección de datos (list_tables, preview_table, execute_sql_query, get_row_counts, display_schema, get_local_pipeline_state), herramientas de secretos (secrets_view_redacted, secrets_update_fragment) y descubrimiento de toolkits (list_toolkits, toolkit_info).
contexto de dltHub (remoto) proporciona search_dlthub_sources — utilizado por el skill find-source para buscar más de 9.700 definiciones de fuentes REST API y devolver conectores verificados con enlaces de referencia antes de escribir código.
Toolkit | Fase | Entrada del workflow | Qué hace | Ejemplos de prompts | Disponibilidad |
| Configuración |
| Recorrido guiado de principio a fin, de datos a dashboard, en 3–5 prompts; enruta al skill de entrada correcto según la profundidad elegida | "Usa quick-start para guiarme por el flujo de trabajo completo con la GitHub API" | Ejecuta |
| Configuración |
| Comprueba | "Ejecuta /init-workspace para configurar un entorno Python con dlthub" | ¡Pruébalo tú mismo!Ejecuta |
| Build |
| Crear el esqueleto, depurar y validar pipelines de ingesta de REST API | "Usa find-source para cargar datos de la Stripe API en DuckDB" | ¡Pruébalo tú mismo!Ejecuta |
| Build |
| Crear el esqueleto, depurar y validar pipelines de ingesta de bases de datos SQL | "Usa find-source para cargar tablas de mi base de datos Postgres en DuckDB" | Ejecuta |
| Build |
| Cargar archivos (CSV, Parquet, JSONL o personalizados) desde disco local, S3, GCS, Azure o SFTP a un destino | "Usa create-filesystem-pipeline para cargar mis archivos CSV de S3 en DuckDB" | |
| Exploración |
| Consultar los datos cargados y crear dashboards de marimo | "Usa explore-data para explorar mi pipeline de Stripe y crear un dashboard" | ¡Pruébalo tú mismo!Ejecuta |
| Run |
| Desplegar pipelines en la Plataforma dltHub | "Usa setup-runtime para desplegar mi pipeline en dltHub" | |
| Transformación |
| Diseñar un Canonical Data Model (CDM) y escribir funciones de transformación de dlthub a partir de pipelines existentes | "Usa annotate-sources para empezar a construir un CDM a partir de mis pipelines de HubSpot y Luma" | |
| Build |
| Definir, ejecutar y revisar comprobaciones y métricas de calidad de datos en los datos de pipelines de dlt | "Usa setup-data-quality para añadir comprobaciones de validación a mi pipeline de Stripe" | |
| Build |
| Ajustar un pipeline lento o con uso intensivo de memoria — diagnosticar la etapa de cuello de botella y aplicar paralelismo, workers, buffers y batching | "Usa optimize-performance para acelerar mi pipeline de Postgres" |
inites una dependencia compartida que proporciona reglas, manejo de secretos y el servidor MCP. Se instala automáticamente condlthub ai inito como plugin independiente a través del marketplace de Claude.
Para configurar un proyecto dlthub nuevo y limpio con soporte de IA, ejecuta dlthub-init. Es no interactivo y compatible con IA, por lo que tu asistente de codificación puede ejecutarlo por ti — este es el comando que un agente debe usar para configurar un proyecto dlthub nuevo y limpio. Fija dlt[hub] mediante un lock incluido y ejecuta uv sync:
uvx dlthub-init@latest <dir> # scaffold a clean new project into <dir>Para añadir el AI harness a un proyecto existente, ejecuta el mismo dlthub-init in situ. Utiliza manejo de colisiones por archivo (fusiona pyproject.toml, nunca sobrescribe secrets.toml, une .gitignore), fija dlt[hub] y ejecuta uv sync — y, al ser no interactivo, tu asistente de codificación puede ejecutarlo por ti:
uvx dlthub-init@latest # set up AI support in the current directoryPasos manuales (alternativa): si prefieres hacerlo paso a paso, o dlthub-init no está disponible:
Nota: Todos los comandos
dlthub aique aparecen a continuación usan la sintaxisuv run dlthub .... Si tienesdlthubinstalado globalmente o en un entorno virtual activo, puedes omitiruv runy llamar adlthubdirectamente. Recomendamos usar 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 detecta tu asistente de codificación a partir de las variables de entorno y los archivos de configuración, y luego instala las skills, las reglas y el servidor MCP en las ubicaciones correctas para esa herramienta.
Nota de Claude Code: Añade lo siguiente a tu
CLAUDE.mdpara garantizar un manejo seguro de las credenciales:CRITICAL: never ask for credentials in chat. Always let the user edit secrets directly and do not attempt to read them.
Nota de Cursor: Después de ejecutar el comando, habilita manualmente el servidor dlt-workspace-mcp en Cursor Settings > MCP. Añade lo siguiente a tu
.cursor/rules/security.mdcpara garantizar un manejo seguro de las credenciales:CRITICAL: never ask for credentials in chat. Always let the user edit secrets directly and do not attempt to read them.
Nota de Codex: Codex no admite comandos ni reglas, por lo que el instalador los convierte en skills y en AGENTS.md. Codex también se ejecuta en un sandbox estricto — considera habilitar el acceso web en tu proyecto o en la configuración global:
# .codex/config.toml web_search = "live"Añade lo siguiente a tu
AGENTS.mdpara garantizar un manejo seguro de las credenciales:CRITICAL: never ask for credentials in chat. Always let the user edit secrets directly and do not attempt to read them.
¿Eres nuevo en dltHub y solo quieres probarlo o aprenderlo? Ejecuta dlthub-start tú mismo — genera un espacio de trabajo playground nuevo (no para producción, no para configurar un proyecto real):
uvx dlthub-start@latestEjecútalo tú mismo — no se lo pidas a tu asistente de codificación.
uvx dlthub-startdebe ejecutarlo una persona porque requiere interacción para la autenticación; solo funciona en una terminal real (no en modo!). Para una configuración dirigida por agentes, usadlthub-initmás arriba.
¿Aún no tienes dlthub configurado? Sigue primero Nuevo proyecto o Proyecto existente más arriba (o el
/init-workspacedel toolkitbootstrap, que el asistente puede ejecutar). Los comandos de toolkit que aparecen a continuación asumen quedlthubestá instalado en tu entorno.
uv run dlthub ai toolkit listInstala los toolkits (si no estás seguro de qué toolkits instalar, recomendamos instalarlos todos):
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 performanceUsa uno de los prompts de ejemplo de la tabla Toolkits disponibles de más arriba para iniciar un flujo de trabajo.
Claude Code — inicia una nueva sesión mediante claude en tu terminal. Reinícialo después de la instalación para que las skills y el MCP surtan efecto.
Cursor — abre el proyecto en Cursor y usa el panel de chat (Cmd+L). Las skills y las reglas instaladas se detectan automáticamente.
Codex — inicia la CLI de Codex mediante codex o usa el chat de Codex en la interfaz. Reinicia Codex después de la configuración para que el servidor MCP surta efecto.
Early Access: El plugin de Claude Code está actualmente en early access y puede que no ofrezca la mejor experiencia de vinculación entre los distintos toolkits. Si eres nuevo en dltHub y quieres probarlo o aprenderlo, consulta Primera configuración — ejecutas
uvx dlthub-start@latesttú mismo. La ruta de marketplace que aparece a continuación es útil cuando quieres hacer bootstrap de un proyecto existente o vacío desde dentro de Claude Code mediante el toolkitbootstrap(que prefiereuvx dlthub-init@latest— el comando ejecutable por agentes para configurar un proyecto dltHub nuevo o existente desde cero — y recurre a los pasos de instalación in-place).
El harness también está disponible como plugin de Claude Code a través del marketplace. Inicia una sesión de Claude Code y ejecuta:
/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 projectInicia una nueva sesión — los plugins solo surten efecto después de reiniciar Claude Code: claude
¿Reanudando una sesión? Los plugins instalados a mitad de sesión no están activos hasta que inicies una nueva.
dlthub aiEl subcomando dlthub ai es el puente entre el harness y tu asistente de codificación. dlthub ai init instala las reglas del proyecto, una skill de gestión de secretos, los archivos de ignore adecuados y configura el servidor MCP de dlt para tu agente. dlthub ai toolkit install copia componentes adicionales del toolkit (skills, reglas, comandos) en las ubicaciones correctas para tu asistente.
Gestión de toolkits — copia skills, reglas, comandos y configuración de MCP desde el harness al directorio de configuración del agente de tu proyecto (.claude/, .cursor/, .agents/, etc.):
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 detectionGestión de secretos — dlt almacena las credenciales en archivos TOML; estos comandos permiten al asistente inspeccionarlas y actualizarlas sin leer los valores secretos en bruto:
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 fileServidor MCP — inicia un servidor local que expone tu espacio de trabajo de dlthub (pipelines, schemas, tablas, secretos) como herramientas que el asistente puede invocar:
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 configEl servidor MCP permite al asistente responder preguntas como «¿qué tablas se cargaron?» o «muéstrame el schema» sin que tengas que copiar y pegar la salida en el chat.
Este proyecto está licenciado bajo la 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.
