Every change Wellknown observed on this MCP server, newest first, with what it was before and what it became. Tool-surface changes carry the definition diff. Nothing here is edited after the fact.
Changed the definition of "finish_data_source_onboarding", "finish_data_spec_update", "list_data" and 2 more
CallafterONLYuploadingafter the file(s) returned by onboard_data_source have actually been uploaded (each PUT returned HTTP 200) — kicks off AI analysis and waits until the spec reaches "ready" or "failed". This tool verifies the upload against storage before starting anything. If a file is not there it refuses, spends no credits, and returnsbeforea fresh upload URL plus the exact curl command — complete the upload and call this again. Calling it in the hope that analysis will work without the upload cannot succeed; if you have no filesystem access, ask the user to attach the file and upload it first. If it returns before the spec settles (timedOut: true), do NOT call this ⟨22 unchanged words⟩
CallafterONLYuploadingafter 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 beforethatthe spec settles (timedOut: true), do NOT call this ⟨14 unchanged words⟩ 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.
⟨52 unchanged words⟩ ; pass the returned nextCursor to fetch more. A spec row also carries its stored input set — sourceType, sampleFileName, formatFileName, targetOption/targetTables/targetSchemaFileName, sourceTables, merge and additionalPrompt — which is exactly what AI code generation re-reads on every re-analysis. Read that set here BEFORE calling update_data_spec: an update regenerates the parser and mapping from all of it, not just from the fields you change, so it is the only way to tell which components are about to be reused as-is. This is NOT a table listing — specs ⟨72 unchanged words⟩
⟨112 unchanged words⟩ items":{"additionalProperties":false,"properties":{"additionalPrompt":{"description":"Stored AI guidance, reused verbatim on every re-analysis","type":"string"},"computeSize":{"enum":["small","large" ⟨16 unchanged words⟩ "type":["string","null"]},"formatFileName":{"description":"sourceType \"file\" only: the stored format spec, if one was provided","type":"string"},"hasTransformationConfig":{"type":"boolean"},"lastJobId":{"type":["string","null"]},"lastRunTs":{"type":["string","null"]},"merge":{"type":"boolean"},"progress":{"type":"number"},"sampleFileName":{"description":"sourceType \"file\" only: the stored sample the generated parser was built from","type":"string"},"sourceTables":{"description":"sourceType \"tables\"/\"compaction\" only","items":{"type":"string"},"type":"array"},"sourceType":{"description":"\"file\" | \"tables\" | \"compaction\"","type":"string
⟨24 unchanged words⟩ the sample file (and optional format/target-schema file).—Creating the spec does NOT uploadtheanything: you must PUT each file to its URL yourself (sor have the user attach it so your platform can),perconfirm the PUT returnedinstructionsHTTP 200, and only then call finish_data_source_onboarding with the returned specId to kick off AI analysis and wait for it to complete. finish_data_source_onboarding checks storage and refuses if the upload never landed, so skipping the upload cannot be worked around by retrying it. Use sourceType "tables" instead when the request ⟨298 unchanged words⟩
⟨64 unchanged words⟩ change — omitted fields keep their current value. IMPORTANT — re-analysis is a full regeneration, not a patch. It throws away the spec's existing parser and column mapping and rebuilds BOTH from the spec's stored input set as a whole: the sample file, format file, target-schema file, source tables and additionalPrompt, each read from storage exactly as it was last uploaded. A component you leave out is NOT left untouched in the generated code — it is fed to the AI again alongside the parts you changed. So updating a target schema without re-sending the source sample maps the new target against whatever sample was uploaded when the spec was onboarded, and the result is a complete, plausible-looking, WRONG mapping rather than an error. Therefore, before changing anything that feeds code generation: call list_data (resource: "specs") to read this spec's stored input set, show the user what each component currently is, and re-send in THIS SAME call every component that is stale or that the user is now describing differently — then pass confirmedCurrentInputs: true. Keeping a stored component is a decision to make deliberately, not a default to fall into by only mentioning the field you were asked about.
⟨103 unchanged words⟩ ,"large"],"type":"string"},"confirmedCurrentInputs":{"description":"Required (true) whenever this update changes something that feeds AI code generation and analysis will run. It asserts that you have read the spec's stored input set (list_data, resource: \"specs\"), checked each component — sample file, format file, target-schema file, source tables, additionalPrompt — against what the user now wants, and re-sent every stale one in this same call. Set it only once that is actually true: re-analysis rebuilds the entire parser and mapping from that set, so one component left at an older version silently contradicts the ones you changed.","type":"boolean"},"description":
Changed the definition of "create_workspace", "manage_trigger" and "onboard_data_source"
⟨46 unchanged words⟩ :"object"},"type":"array"},"userPermission":{"type":"string"},"workspaceId":{"type":"string"}},"required":["workspaceId","name","createdBy","createdAt","userPermission","permission","permissions"],"type":"object"}
⟨190 unchanged words⟩ target a table-source (sourceType: "tables") or compaction (sourceType: "compaction") spec (see onboard_data_source) — they have no file to load, only a generated query tore-run.re-run
Certificate recorded, valid to 2027-01-06
Authorization not required
First tool surface recorded: 18 tools (server version 1.0.0)
Showing the latest 5 events. The API returns up to 500 and filters by kind: ?kind=tool_surface_changed
⟨254 unchanged words⟩ data spec.","type":"string"},"expirePriorSnapshots":{"description":"sourceType \"compaction\" only, default false. When false the job commits the compacted files and changes nothing else — prior snapshots still reference the replaced files, so no storage is freed. When true it also expires every snapshot older than its own commit and deletes the replaced files in the same run, which frees storage but ends the ability to roll back to before the compaction.","type":"boolean"},"formatFileName":{"description":"sourceType \"file\" ⟨164 unchanged words⟩ :"string"},"sourceTables":{"description":"Names of existing workspace tables. Required for sourceType \"tables\"only: names of existing workspace(the tables the generated query readsfrom.from)Requiredand for sourceType \"tables\compaction\" (the tables to compact).","items":{"type":"string"} ⟨24 unchanged words⟩ sourceTables — instead of loading a new file. Use \"compaction\" to bin-pack the small data files of existing tables: it moves no data and produces no new table, so it takes NO target of any kind, needs no analysis, and is ready to run the moment it is created.","enum":["file","tables","compaction"],"type":"string"},"specName": ⟨204 unchanged words⟩