Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TD_API_KEY | Yes | Your Treasure Data API key |
Schema
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| td_list_databases | List available databases to find data sources and check access. Shows all databases you can access. Returns just names for quick overview,
or set verbose=True for details like table count and permissions.
Common scenarios:
- Discover what databases are available in your account
- Check permissions on specific databases
- Get database list for documentation or auditing
Use pagination (limit/offset) for large lists or all_results=True for everything. |
| td_get_database | Get specific database details like table count, permissions, and metadata. Shows detailed information about a named database. Use when you need to check
database properties, understand access permissions, or get table statistics.
Common scenarios:
- Verify database exists before running queries
- Check permission level (administrator, read-only, etc.)
- Get table count and creation/update timestamps
- Audit database properties for documentation
Returns creation time, table count, permissions, and protection status. |
| td_list_tables | List tables in a database to explore data structure and find datasets. Shows all tables within a specific database. Returns table names for quick
scanning, or set verbose=True for schemas, sizes, and record counts.
Common scenarios:
- Explore available data in a database
- Find specific tables by scanning names
- Check table schemas before writing queries
- Audit table sizes and record counts
- Verify table exists before querying
Supports pagination (limit/offset) or all_results=True for complete list. |
| td_list_projects | List workflow projects to find data pipelines and scheduled jobs. Shows all workflow projects containing Digdag workflows, SQL queries, and
Python scripts. Returns names/IDs for navigation or verbose=True for details.
Common scenarios:
- Discover available data processing workflows
- Find specific project by browsing names
- Get project IDs for detailed exploration
- Audit workflow projects in the account
- List user projects (exclude system with include_system=False)
Projects contain .dig files defining scheduled data pipelines. |
| td_get_project | Get workflow project details by ID to check metadata and revision. Retrieves project information including creation time, last update, and
revision hash. Use after finding project ID from td_list_projects.
Common scenarios:
- Get project metadata before downloading archive
- Check when project was last updated
- Verify project exists by ID
- Get revision for version tracking
Note: Use numeric project ID (e.g., "123456") not project name.
For project contents, use td_download_project_archive. |
| td_download_project_archive | Download a project's archive (tar.gz) and return information about the download. This tool downloads the complete archive of a Treasure Data workflow project,
which contains all SQL queries, Digdag (.dig) files, Python scripts, and other
resources. The file is temporarily stored on the server.
Args:
project_id: The ID of the workflow project to download |
| td_list_project_files | List all files contained in a project archive. This tool extracts and lists the content of a previously downloaded
project archive, showing all files and directories within the project.
Args:
archive_path: The path to the downloaded project archive (.tar.gz file) |
| td_read_project_file | Read the contents of a specific file from a project archive. This tool extracts and reads a specific file from a project archive,
returning its contents. This allows examining SQL queries, workflow
definitions, and other files without fully extracting the archive.
Args:
archive_path: The path to the downloaded project archive (.tar.gz file)
file_path: The path of the file within the archive to read |
| td_list_workflows | List all workflows to monitor executions and find failed jobs. Shows workflows across all projects with their latest execution status.
Essential for monitoring data pipeline health and finding issues.
Common scenarios:
- Check which workflows are failing (status_filter="error")
- Monitor currently running workflows (status_filter="running")
- Find workflows by name (use search parameter)
- Get overview of all scheduled jobs
- Audit workflow execution patterns
Filter options: status ('success', 'error', 'running'), search by name.
Set verbose=True for execution history. Limit count to avoid token issues. |
| td_find_project | Find project by name when you don't know the exact ID. Searches all projects and returns matches. Useful when you know project
name but need the ID for other operations like downloading archives.
Common scenarios:
- User mentions project name, need to find ID
- Looking for projects containing specific keywords
- Getting project ID before using td_download_project_archive
- Finding multiple projects with similar names
Use exact_match=True for precise name matching, False for fuzzy search.
Returns project IDs, names, and metadata for all matches. |
| td_find_workflow | Find workflows by name to get IDs and check execution status. Essential for locating specific workflows when you know the name.
Returns workflow IDs, project info, and latest execution status.
Common scenarios:
- User mentions workflow name, need to find details
- Looking for failing workflows with specific names
- Finding workflows within a specific project
- Getting workflow ID before detailed analysis
- Checking if a named workflow is running/failed
Filters: project_name (optional), status ('success', 'error', 'running').
Use exact_match=True for precise names, False for partial matches. |
| td_get_project_by_name | Get full project details using exact name instead of ID. Convenient shortcut when you know the exact project name.
Combines find + get operations for immediate detailed results.
Common scenarios:
- User provides exact project name, need full details
- Quick project metadata lookup by name
- Avoiding two-step process (find ID then get details)
- Getting revision/timestamps for known project
Requires exact name match. For fuzzy search use td_find_project.
Returns same details as td_get_project but using name lookup. |
| td_smart_search | Universal search across Treasure Data - best for broad queries. One-stop search for projects, workflows, and tables with smart ranking.
Use when unsure what resource type you're looking for or need comprehensive results.
Common scenarios:
- "Find anything related to customer analytics"
- Discovering resources around a topic/keyword
- Broad exploration of available data assets
- Finding resources when type is unknown
- Cross-resource impact analysis
Search modes:
- exact: Precise string matching only
- fuzzy: Partial matches and substrings (default)
- semantic: Word-based matching for concepts
Scopes: "all", "projects", "workflows", "tables"
Returns ranked results with relevance scores (0-1). |
| td_analyze_url | Analyze any Treasure Data console URL to get resource details. Smart URL parser that extracts IDs and fetches information. Use when someone
shares a console link in Slack, email, or documentation.
Common scenarios:
- Someone shares workflow URL during incident investigation
- Documentation contains console links to resources
- Error message includes console URL reference
- Quick lookup from browser URL copy/paste
Supported formats:
- Workflow: https://console.../app/workflows/12345678/info
- Project: https://console.../app/projects/123456
- Job: https://console.../app/jobs/123456
Automatically detects type and returns full resource information. |
| td_get_workflow | Get workflow details using numeric ID - essential for console URLs. Direct workflow lookup when you have the ID. Handles large workflow IDs
that exceed pagination limits. Returns project info and execution history.
Common scenarios:
- Extracting ID from console URL (../workflows/12345678/info)
- Looking up workflow from error logs containing ID
- Getting project context for a known workflow ID
- Checking execution status by workflow ID
Returns workflow name, project details, schedule, and recent runs.
Includes console URL for quick browser access. |
| td_explore_project | Deep-dive into project to understand workflows, SQL, and architecture. Comprehensive project analyzer that downloads and examines all files.
Essential for understanding unfamiliar projects or debugging complex issues.
Common scenarios:
- "What does this project do?" - Full project understanding
- Onboarding to new codebase - Architecture overview
- Debugging workflow failures - Code quality analysis
- Documentation generation - Structure and dependencies
- Performance optimization - Finding bottlenecks
Analysis levels:
- overview: Quick project summary and structure
- detailed: Code patterns and common issues (default)
- deep: Full analysis including all SQL/Python code
Focus areas: ["code", "data_flow", "performance", "errors"]
Returns file structure, code patterns, issues, and recommendations. |
| td_diagnose_workflow | Health check for workflows - find why they're failing or slow. Automated troubleshooting that analyzes execution history to identify
patterns, calculate health scores, and provide fix recommendations.
Common scenarios:
- Workflow suddenly failing - Find root cause
- Performance degradation - Identify slow tasks
- Reliability issues - Pattern analysis
- Pre-deployment check - Ensure workflow health
- Incident response - Quick failure diagnosis
Time windows: "30d", "7d", "24h" for trend analysis
Levels: "basic" (quick stats), "comprehensive" (full analysis)
Returns health score (0-10), failure patterns, and prioritized fixes.
Args:
workflow_identifier: Workflow name, ID, or partial match
time_window: Time period to analyze (e.g., "30d", "7d", "24h")
diagnostic_level: "basic" for quick check, "comprehensive" for deep analysis
Returns:
Health report with score, issues, trends, and optimization recommendations |
| td_trace_data_lineage | Map data flow to see what feeds into or depends on tables/projects. Critical for understanding data dependencies and impact analysis.
Traces through SQL queries to build dependency graph.
Common scenarios:
- "What happens if I change this table?" - Impact analysis
- "Where does this data come from?" - Source tracing
- Data quality issues - Track upstream problems
- Migration planning - Understand dependencies
- Documentation - Data flow diagrams
Directions:
- upstream: What tables/projects feed INTO this
- downstream: What tables/projects CONSUME this
- both: Complete dependency graph
Returns visual-ready dependency tree with table/project relationships.
Args:
table_or_project: Table name (format: "database.table") or project name/ID
direction: "upstream" (sources), "downstream" (consumers), or "both"
max_depth: Maximum levels to trace (default: 3)
Returns:
Data lineage graph with dependencies and data flow information |
| td_get_session | Get workflow session details by ID to check execution status and timing. A session is a scheduled workflow run. Use when you have a session ID and need
to check if it ran successfully, when it was scheduled, or get attempt details.
Common scenarios:
- Verify if a scheduled workflow executed at the expected time
- Get the attempt ID to investigate execution details
- Check overall success/failure status
Returns session info with workflow name, schedule time, and latest attempt status. |
| td_list_sessions | List recent workflow executions to monitor status and find failures. Shows recent scheduled runs (sessions) with their execution status. Filter by
workflow ID to see history of a specific workflow, or leave empty for all.
Common scenarios:
- Check which workflows ran recently and their status
- Find failed executions that need investigation
- Monitor execution patterns for a specific workflow
- Get session IDs for detailed analysis
Returns list with workflow names, execution times, and success/failure status. |
| td_get_attempt | Get workflow attempt details to investigate specific execution instance. An attempt is one execution try of a scheduled session. Use when you have an
attempt ID from error logs or td_get_session and need execution details.
Common scenarios:
- Investigate why a workflow execution failed
- Check how long the execution took
- See if this was a retry after previous failure
- Get execution parameters for debugging
Returns attempt status, timing, retry info, and safe execution parameters. |
| td_get_attempt_tasks | Get task breakdown to find which step failed or is slow in workflow. Shows all individual tasks (steps) within a workflow execution with their
status, timing, and dependencies. Essential for debugging failed workflows.
Common scenarios:
- Find exactly which task/query failed in a complex workflow
- Identify slow-running tasks causing delays
- Understand task execution order and dependencies
- Debug data processing issues at task level
Returns task list with names, states, timing, and failure details. |
| td_analyze_execution | Analyze workflow execution from console URL or ID - best for debugging. Smart analysis tool that accepts URLs from error alerts or IDs. Automatically
detects type and provides comprehensive execution analysis with recommendations.
Accepts:
- Console URLs (e.g., https://console.../app/sessions/123456)
- Session IDs (e.g., 123456789)
- Attempt IDs (e.g., 987654321)
Common scenarios:
- Someone shares a workflow URL in Slack during incident
- Quick analysis when you only have an ID from logs
- One-stop debugging for any execution issue
Returns analysis with failures, slow tasks, and actionable recommendations. |