工具 API

run_data_app

Start one Data App run and return a Run object. Use after checking the input contract via get_data_app_details. Act on the returned state and next_step only: - terminal (SUCCEEDED / PARTIALLY_SUCCEEDED / FAILED / CANCELLED): records inlines the first 50 result records (structure per output_schema), pagination.total is the total count; if a handoff field is present, follow it for the rest. PARTIALLY_SUCCEEDED sets partial=true and its records are usable; FAILED explains in error. - QUEUED / RUNNING: still executing, no data yet, billing incomplete. Wait with get_run_status(run_id, wait_seconds=60), then get_run_result(run_id); cancel_run(run_id) stops it and keeps the records produced so far. Which case you get depends on wait_seconds: 0 (default) returns right after launch for every App; a positive value holds on the platform until the run ends or the budget is used up, so a quick App (execution.mode=sync) comes back terminal with its records inline when you pass wait_seconds=60. A long-running App (async) is best launched with 0. **For several targets, call this tool repeatedly with wait_seconds=0 to launch every run first, then wait**: runs execute in parallel on the platform. Other Run fields: run_id (used by every later call), progress (done/total), usage and billing (complete only in a terminal state). Pinned App-specific tools return the same shape. Errors: [invalid-input] names the offending fields, fix and retry. These three are not retryable, tell the user the cause instead: [app-not-found/not_found] (missing, renamed, or not visible to this credential; confirm via search_data_apps), [app-not-accepting-runs/forbidden] (in maintenance; relay the author's note if given), [balance-negative/forbidden] (wallet overdrawn; retry as-is after the user tops up).