This server exposes a dlt workspace to AI agents via MCP, letting them inspect pipelines and data, manage secrets safely, discover toolkits and dltHub sources, and run read-only SQL.
Workspace overview: list pipelines, profiles, workspace info, and available AI toolkits (including toolkit contents).
Data inspection: list tables, view table schemas, get CREATE TABLE DDL, preview rows, get row counts, and export schemas as Mermaid/YAML/DBML.
Querying: execute read-only SQL SELECT queries against pipeline destination datasets.
Pipeline state: retrieve incremental cursors, resource state, and source state.
Secrets management: list secret files, view them redacted, and merge TOML fragments without exposing raw values.
Source discovery: search dltHub's catalog of 9,700+ REST API source definitions.
Allows loading data into DuckDB as a destination, and provides tools for data exploration, query, and dashboard creation on loaded data.
Enables building canonical data models and transformation pipelines from HubSpot APIs, integrating with dlt for data loading and transformation.
Provides capabilities for building data pipelines that load data from the Stripe API into various destinations, with support for ingestion, transformation, and data quality validation.
dlt (data load tool) is an open-source Python library for loading data from APIs and databases into a warehouse or lakehouse. dltHub (paid platform) extends dlt with enterprise-grade features tailored to the needs of coding agents: transformations, data quality validation, managed runtime infrastructure, managed data apps, and an AI-powered workspace environment.
The dltHub AI Harness is a collection of toolkits that give AI coding assistants step-by-step workflows to build data pipelines with dlt. You can use the harness as-is or fork and customize it for your own stack. The dlthub ai CLI installs toolkit components into the right locations for your assistant and runs the workspace MCP server.
Build toolkits cover ingestion (REST API, SQL), transformation, and data quality; Run toolkits handle deployment and exploration. The REST API toolkit is backed by the dltHub context — over 9,700 source definitions the agent queries to find verified connectors before writing code. New users can start with the quick-start toolkit for a guided end-to-end run from data to dashboard.
The dltHub AI Harness is tested with Claude Code, Cursor, and Codex and may work with other AI coding assistants. We recommend workings in accept edits (Claude) / --approval-mode (Codex) mode to review the changes and familiarizing with dlthub AI workflows when getting started with the dlthub AI Harness.
Building data pipelines is iterative and covers two major phases — ingestion and transformations — each following the same inner loop:
Build (local development)
Develop the pipeline iteratively — for ingestion: first REST API endpoint, then additional endpoints; for transformation: data model first, then the full transformation pipeline
Explore the loaded data and validate it after each step
Loop back to refine until the pipeline is solid
Run (production)
Deploy the ingestion or transformation pipeline to production
Serve insights via data apps built on top of the loaded data
The outer loop connects the two phases: insights from the transformation and serving layer feed back into ingestion refinement. The harness Build toolkits support the local development loop; the Run toolkits handle deployment and data apps.
Related MCP server: Local LLM MCP Server
The harness gives your coding assistant toolkits — that contain a structured, guided workflow for a specific phase. Instead of generating ad-hoc code, the assistant follows a defined sequence of steps from start to finish.
A Toolkit contains skills, commands, rules, and an MCP server — tied together by a workflow that tells the assistant which skill to run at each step and how to leverage the MCP.
All toolkits depend on init for shared rules, secrets handling, and the MCP server. When using the dlthub ai CLI, init is installed automatically as a dependency. When using the Claude marketplace, install the init plugin separately.
Component | What it is | When it runs |
Skill | Step-by-step procedure the assistant follows | Triggered by user intent or explicitly with |
Command | A slash command for a specific action | User invokes with |
Rule | Always-on context (conventions, constraints) | Every session, automatically |
Workflow | Ordered sequence of skills with a fixed entry point | Loaded as a rule — always active |
MCP server | Exposes pipelines, tables, and secrets as tools | During a session, via MCP protocol |
9,700+ REST API source definitions with verified connectors and pipeline patterns | During source discovery, via |
Two MCP servers give the agent structured context throughout the workflow to avoid the need for manual copy-pasting.
dlt-workspace-mcp (local, installed by dlthub ai init) exposes: data inspection tools (list_tables, preview_table, execute_sql_query, get_row_counts, display_schema, get_local_pipeline_state), secrets tools (secrets_view_redacted, secrets_update_fragment), and toolkit discovery (list_toolkits, toolkit_info).
dltHub context (remote) provides search_dlthub_sources — used by the find-source skill to search 9,700+ REST API source definitions and return verified connectors with reference links before writing code.
Toolkit | Phase | Workflow entry | What it does | Example prompts | Availability |
| Setup |
| Guided end-to-end run from data to dashboard in 3–5 prompts; routes to the right entry skill based on a chosen depth | "Use quick-start to take me through the full workflow with the GitHub API" | Run |
| Setup |
| Checks for | "Run /init-workspace to set up a Python environment with dlthub" | Try it out yourself!Run |
| Build |
| Scaffold, debug, and validate REST API ingestion pipelines | "Use find-source to load data from the Stripe API into DuckDB" | Try it out yourself!Run |
| Build |
| Scaffold, debug, and validate SQL database ingestion pipelines | "Use find-source to load tables from my Postgres database into DuckDB" | Run |
| Build |
| Load files (CSV, Parquet, JSONL, or custom) from local disk, S3, GCS, Azure, or SFTP into a destination | "Use create-filesystem-pipeline to load my S3 CSV files into DuckDB" | |
| Explore |
| Query loaded data and create marimo dashboards | "Use explore-data to explore my Stripe pipeline and create a dashboard" | Try it out yourself!Run |
| Run |
| Deploy pipelines to the dltHub Platform | "Use setup-runtime to deploy my pipeline to dltHub" | |
| Transform |
| Design a Canonical Data Model (CDM) and write dlthub transformation functions from existing pipelines | "Use annotate-sources to start building a CDM from my HubSpot and Luma pipelines" | |
| Build |
| Define, run, and review data quality checks and metrics on dlt pipeline data | "Use setup-data-quality to add validation checks to my Stripe pipeline" | |
| Build |
| Tune a slow or memory-heavy pipeline — diagnose the bottleneck stage and apply parallelism, workers, buffers, and batching | "Use optimize-performance to speed up my Postgres pipeline" |
initis a shared dependency that provides rules, secrets handling, and the MCP server. It is installed automatically bydlthub ai initor as a separate plugin via the Claude marketplace.
To set up a clean new dlthub project with AI support, run dlthub-init. It is non-interactive and AI-aware, so your coding assistant can run it for you — this is the command an agent should use to set up a clean new dlthub project. It pins dlt[hub] via a bundled lock and runs uv sync:
uvx dlthub-init@latest <dir> # scaffold a clean new project into <dir>To add the AI harness to an existing project, run the same dlthub-init in place. It uses per-file collision handling (merges pyproject.toml, never overwrites secrets.toml, unions .gitignore), pins dlt[hub], and runs uv sync — and, being non-interactive, your coding assistant can run it for you:
uvx dlthub-init@latest # set up AI support in the current directoryManual steps (fallback): if you'd rather do it step by step, or dlthub-init isn't available:
Note: All
dlthub aicommands below useuv run dlthub ...syntax. If you havedlthubinstalled globally or in an active virtual environment, you can omituv runand calldlthubdirectly. We recommend using 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 detects your coding assistant from environment variables and config files, then installs skills, rules, and the MCP server in the correct locations for that tool.
Claude Code note: Add the following to your
CLAUDE.mdto enforce safe credential handling:CRITICAL: never ask for credentials in chat. Always let the user edit secrets directly and do not attempt to read them.
Cursor note: After running the command, manually enable the dlt-workspace-mcp server in Cursor Settings > MCP. Add the following to your
.cursor/rules/security.mdcto enforce safe credential handling:CRITICAL: never ask for credentials in chat. Always let the user edit secrets directly and do not attempt to read them.
Codex note: Codex does not support commands and rules, so the installer converts those into skills and AGENTS.md. Codex also runs in a strict sandbox — consider enabling web access in your project or global config:
# .codex/config.toml web_search = "live"Add the following to your
AGENTS.mdto enforce safe credential handling:CRITICAL: never ask for credentials in chat. Always let the user edit secrets directly and do not attempt to read them.
New to dltHub and just want to try or learn it? Run dlthub-start yourself — it scaffolds a fresh playground workspace (not for production, not for setting up a real project):
uvx dlthub-start@latestRun this yourself — don't ask your coding assistant.
uvx dlthub-startmust be run by a human because it requires interaction for authentication; it only works in a real terminal (not!mode). For agent-driven setup, usedlthub-initabove.
Don't have dlthub set up yet? Follow New project or Existing project above first (or the
bootstraptoolkit's/init-workspace, which the assistant can drive). The toolkit commands below assumedlthubis installed in your environment.
uv run dlthub ai toolkit listInstall toolkits (if you are not sure which toolkits to install we recommend installing all of them):
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 performanceUse one of the example prompts from the Available toolkits table above to kick off a workflow.
Claude Code — start a new session via claude in your terminal. Restart after installation for skills and MCP to take effect.
Cursor — open the project in Cursor and use the chat panel (Cmd+L). The installed skills and rules are picked up automatically.
Codex — launch the Codex CLI via codex or use the Codex chat in the UI. Restart Codex after setup for the MCP server to take effect.
Early Access: The Claude Code plugin is currently in early access and may not provide the best linking experience between different toolkits. If you're new to dltHub and want to try or learn it, see First-time onboarding — you run
uvx dlthub-start@latestyourself. The marketplace path below is useful when you want to bootstrap an existing/empty project from inside Claude Code via thebootstraptoolkit (which prefersuvx dlthub-init@latest— the agent-runnable command for setting up a clean new or existing dlthub project — and falls back to the in-place install steps).
The harness is also available as a Claude Code plugin via the marketplace. Start a Claude Code session and run:
/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 projectStart a new session — plugins take effect only after restarting Claude Code: claude
Resuming a session? Plugins installed mid-session are not active until you start a new one.
dlthub ai CLIThe dlthub ai subcommand is the bridge between the harness and your coding assistant. dlthub ai init installs project rules, a secrets management skill, appropriate ignore files, and configures the dlt MCP server for your agent. dlthub ai toolkit install copies additional toolkit components (skills, rules, commands) into the right locations for your assistant.
Toolkit management — copies skills, rules, commands, and MCP config from the harness into your project's agent config directory (.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 detectionSecrets management — dlt stores credentials in TOML files; these commands let the assistant inspect and update them without reading raw secret values:
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 server — starts a local server that exposes your dlthub workspace (pipelines, schemas, tables, secrets) as tools the assistant can call:
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 configThe MCP server allows the assistant to answer questions like "what tables were loaded?" or "show me the schema" without you having to copy-paste output into the chat.
This project is licensed under the 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. Dates show when Glama detected each change.
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_infoEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dlt-hub/dlthub-ai-harness'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
