Update an existing data spec, step 2: run analysis after uploading
finish_data_spec_updateCall ONLY after the file(s) returned by update_data_spec have actually been uploaded (each PUT returned HTTP 200) — kicks off AI analysis and waits until the spec reaches "ready" or "failed". The upload is verified against storage first: if a file is missing this refuses, spends no credits, and hands back a fresh upload URL with the curl command to use. If it returns before the spec settles (timedOut: true), do NOT call this tool again just to keep checking — that re-attempts starting analysis. Poll with get_status (specId) instead until it reaches a terminal status.
Upload EVERY file update_data_spec listed before calling this. Analysis regenerates the parser and mapping from the spec's full stored input set, so a half-finished upload means the new files are combined with the old versions of the ones that did not make it — which produces a wrong mapping, not a failure. If an upload did not go through, go back and complete it first.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| specId | Yes | specId returned by update_data_spec. | |
| specName | Yes | Name of the data spec being updated. | |
| runAnalysis | No | Default true — set false to skip analysis and just confirm the upload. | |
| workspaceId | No | Workspace to act on. Defaults to your only workspace if you have exactly one. | |
| loadSampleData | No | Whether analysis should also trigger the data-load job (default true). |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| error | No | ||
| specId | No | ||
| status | No | "processing" | "ready" | "failed" | |
| message | Yes | ||
| progress | No | ||
| timedOut | No | ||
| lastJobId | No | ||
| workspaceId | No | ||
| errorDetails | No | ||
| statusMessage | No | ||
| analysisEndTime | No | ||
| analysisStartTime | No | ||
| analysisDurationMs | No | ||
| hasTransformationConfig | No |