Skip to main content
Glama
iflytek

dolphin-mcp-pilot

Official
by iflytek
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

ds_complement_data

Backfill missing workflow data for specified date ranges or partitions, with options to start from selected tasks and control serial or parallel execution.

Instructions

Backfill (complement) workflow data for date range or single partition.

Recommended usage (v2.0.14):

  • Single partition: partition_date="2024-01-01" (clearer semantics, recommended)

  • Date range: start_date + end_date (multi-partition backfill)

  • From specific task: start_task_names + task_depend_type="TASK_POST"

  • Single task only: start_task_names + task_depend_type="TASK_ONLY"

⚠️ Important (v2.0.19):

  1. Default mode: RUN_MODE_SERIAL (one partition at a time, safer)

  2. Parallel mode: run_mode="RUN_MODE_PARALLEL" (multiple partitions concurrently, higher risk)

  3. Before backfill: check dependency chain with ds_get_workflow → analyze upstream deps

  4. Minimize scope: prefer start_task_names + TASK_POST to backfill from target task forward

  5. Mandatory standard: don't backfill entire workflow unless full-chain rerun is explicitly needed

Args: project_name: Project name workflow_code: Process-definition code start_date: Start date yyyy-MM-dd (for range backfill) end_date: End date yyyy-MM-dd (for range backfill) partition_date: Single partition yyyy-MM-dd (alternative to start_date+end_date, recommended for clarity) start_task_names: Optional list of task names to start from (backfills these + their downstream tasks) task_depend_type: Dependency type (default TASK_POST: from start tasks forward; TASK_ONLY: start tasks only; TASK_PRE: start tasks + upstream) run_mode: RUN_MODE_SERIAL (default, one at a time) or RUN_MODE_PARALLEL (concurrent)

Serial ordering guarantee (v2.0.18): In RUN_MODE_SERIAL, the request is submitted using DS's continuous range fields complementStartDate / complementEndDate, so DS generates instances strictly in ascending day order. Discrete date-list formats (complementScheduleDateList / comma-separated) do not guarantee ordering and are only used as fallbacks. The chosen format is reported in the return value's "format" field ("date_range" / "comma_separated" / "json_list").

Examples: # Single partition (recommended) ds_complement_data(workflow_code=123, partition_date="2024-01-01")

# Date range (serial mode, safer)
ds_complement_data(workflow_code=123, start_date="2024-01-01", end_date="2024-01-31")

# From specific task forward (minimize scope)
ds_complement_data(workflow_code=123, partition_date="2024-01-01",
                   start_task_names=["ads_table"], task_depend_type="TASK_POST")

# Parallel mode (higher concurrency, more resource usage)
ds_complement_data(workflow_code=123, start_date="2024-01-01", end_date="2024-01-10",
                   run_mode="RUN_MODE_PARALLEL")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_dateNo
run_modeNoRUN_MODE_SERIAL
start_dateNo
project_nameYes
workflow_codeYes
partition_dateNo
start_task_namesNo
task_depend_typeNoTASK_POST

Tool Definition Quality

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains default serial mode, the risks of parallel mode, and even details the serial ordering guarantee, including the fallback mechanisms and how the format is reported in the return value. This goes well beyond basic operation to explain internal behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Despite being long, the description is well-structured with clear sections (Recommended usage, Important, Args, Serial ordering guarantee, Examples). Every sentence adds value: usage warnings, parameter details, and behavioral guarantees. No filler or redundancy is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is exceptionally complete for a complex tool with 8 parameters, no annotations, and no output schema. It covers usage, parameter semantics, and behavioral nuances. However, it only partially describes the return value (the 'format' field), leaving success/error response details unspecified, which is a minor gap given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates with an explicit 'Args:' section explaining every parameter, including the semantics of start_task_names and task_depend_type. The examples further illustrate how parameters combine, providing meaning that the schema completely lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Backfill (complement) workflow data for date range or single partition,' using a specific verb and resource, and clearly distinguishes this from sibling tools like ds_run_workflow or ds_create_dag_workflow by focusing on backfilling existing workflow data. The various usage modes are enumerated, making the scope explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides detailed recommended usage patterns for single partition, date range, and task-specific backfills, plus explicit warnings about when to avoid full workflow backfills ('Mandatory standard: don't backfill entire workflow unless full-chain rerun is explicitly needed'). It also references a sibling tool (ds_get_workflow) as a prerequisite, offering clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iflytek/dolphin-mcp-pilot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server