Loading ToolBench
Treasure Data API client for MCP. Provides tools for exploring projects, managing workflows, analyzing executions, and troubleshooting workflow health.
The server defines 14 tools with moderate quality. Most tools have descriptions (10-14 are substantial), but critical gaps exist in parameter documentation, output schemas, and error handling guidance. Tool names follow verb_noun patterns well (td_diagnose_workflow, td_list_sessions, td_get_attempt). However, parameter schemas are incomplete or absent for several tools, and output structures are not documented. The diagnostic tools (td_diagnose_workflow, td_analyze_execution) and exploration tools (td_explore_project) have rich descriptions exceeding 200 chars, which is helpful context but could be optimized for token efficiency. Security-critical tools (td_explore_project downloads and examines all files) lack explicit permission gates or audit logging guidance. Error handling descriptions are missing from most tools, no guidance on what to do if a workflow_id doesn't exist, if a URL is malformed, etc.
Analyze workflow execution to understand performance and identify optimization opportunities.
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.
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.
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.
Three tools have minimal or zero descriptions: td_trace_data_lineage ('Trace data dependencies and lineage across workflows.', 12 chars), td_analyze_execution ('Analyze workflow execution to understand performance and identify optimization opportunities.', 95 chars, borderline), and td_smart_search ('Smart search across projects and workflows using flexible query syntax.', 73 chars). These descriptions are too vague to guide LLM tool selection and lack context about when to call them instead of similar tools.
No explicit output schemas are documented in the source. While some tools have descriptions of what they return ('Returns health score (0-10), failure patterns, and prioritized fixes'), there is no formal JSON Schema structure showing field names, types, or nested object layouts. LLMs cannot plan downstream tool calls without knowing the exact structure of returned data (e.g., does get_workflow return workflow_id or id? Is it a string or int?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
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.
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.
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.
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.
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.
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.
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.
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.
Smart search across projects and workflows using flexible query syntax.
Trace data dependencies and lineage across workflows.
Parameter descriptions are present for most tools but lack constraint details. For example, td_diagnose_workflow accepts time_window as a string with description '"30d", "7d", "24h" for trend analysis', but this reads like example values rather than a formal constraint. No minimum/maximum bounds are specified for numeric parameters (count in td_list_sessions defaults to 20 with no documented min/max). The diagnostic_level parameter specifies enum values ('basic', 'comprehensive') in description text rather than as a JSON Schema enum constraint.
No error handling guidance in tool descriptions. None of the tools document what happens if a resource is not found, if an API call fails, or what the LLM should do next. For example, td_get_workflow takes a workflow_id, if the ID doesn't exist, should the LLM call td_find_workflow? Should it return a 404 or a structured error? No guidance is provided. td_analyze_url accepts a URL, if the URL is malformed or unsupported, what error format is returned?
td_explore_project downloads and examines all files in a project ('downloads and examines all files'). This is a read-only operation, but the tool lacks explicit permission gates or audit logging guidance. There is no mention of rate limits, file size caps, or what happens if a project is very large (e.g., 10,000+ files). For a tool that accesses potentially sensitive project code, the description should include security boundaries.
Generic or overlapping tool names reduce clarity. td_find_project and td_get_project_by_name are both project lookups, the distinction is 'find' vs 'get by exact name', but this is subtle and wastes LLM reasoning cycles. Similarly, td_find_workflow vs td_get_workflow and td_explore_project vs td_find_project suggest overlapping responsibilities. Consolidation or more explicit naming (e.g., td_get_project_by_exact_name, td_search_project_by_keyword) would improve discoverability.
Parameter name consistency issue: td_find_workflow has a 'status_filter' parameter with values like 'success', 'error', 'running', but the description text doesn't clarify what these statuses mean in context of workflows. Is 'error' the latest execution status, or the overall workflow health? No type annotation (enum vs string) is visible in the schema.