Dpf It

List every workspace the authenticated user has access to, including their permission on each.

Create a new workspace, owned by the authenticated user. Use this if list_my_workspaces returns none.

List either the data specs (parsing + mapping rule sets, resource: "specs") or the data processing jobs (executions of a spec, resource: "jobs") defined in a workspace. Each spec includes its specId and current status — poll a specific one with get_status. Both resources are paginated (default 25/page, max 100, newest first); pass the returned nextCursor to fetch more. A spec row also carries its

Poll the status of either a data spec's own process (schema inference + code generation, run by start-analysis — pass specId, reaches "ready" or "failed") or a data-load job (pass jobId, reaches "complete" or "failed"). Pass exactly one of specId or jobId. Right after create-spec/update-spec + start-analysis, poll by specId; once that reaches "ready", its response's lastJobId (if present) points a

Permanently delete a data spec and its associated configuration.

Run a SQL query against the Iceberg tables loaded into a workspace. To list the tables that actually exist in the workspace, run `SHOW TABLES` — this is the authoritative source (unlike list_data's specs, which describe pipelines, not live tables). Qualified table references (catalog/schema prefixes, e.g. information_schema.tables) are rejected; reference tables by name only. Table functions that

Create, list, test, or delete a workspace connection to an external data source. Two types are supported: "sftp" and "aws_s3". For sftp, create generates a keypair and returns the public key — it must be installed in the remote server's authorized_keys before test (or a trigger using this connection) will succeed. For aws_s3, create generates an ExternalId and returns a trustPolicy plus dpfPrincip

Create, list, update, delete, or fire a workspace job trigger. Four types: - "sftp"/"aws_s3": pulls files from a connection (sftp: remote server; aws_s3: S3 bucket/prefix) into an already-analyzed data spec on a schedule (hourly/daily/monthly, UTC). Type must match the connection's type; aws_s3 also requires s3Bucket (s3Prefix optional). Natural-language preRules (which files to pick up) and postR

First step of setting up a new data integration: creates a data spec. By default (sourceType "file") this returns presigned upload URL(s) for the sample file (and optional format/target-schema file). Creating the spec does NOT upload anything: you must PUT each file to its URL yourself (or have the user attach it so your platform can), confirm the PUT returned HTTP 200, and only then call finish_d

Call ONLY after 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 returns a fresh upload URL plus the exact curl command — complete the uplo

Change an existing data spec's configuration. If no replacement file names are given, this runs synchronously (no upload needed): saves changes and — by default — re-runs AI analysis, returning the final status directly. If a replacement sample/format/target-schema file name IS given, this instead returns presigned upload URL(s); upload the file(s), then call finish_data_spec_update. Only pass the

Call 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 (timed

First step of processing new data files through an already-configured data spec: creates a job and returns presigned upload URL(s) for each file. Upload the file(s) per the returned instructions, then call finish_data_job with the returned jobId to start processing and wait for it to complete. Do NOT call this right after onboard_data_source/finish_data_source_onboarding or update_data_spec/finis

Call after uploading the file(s) returned by run_data_job — starts processing and waits until the job completes or fails. If it returns before that (timedOut: true), do NOT call this tool again just to keep checking — that re-attempts starting the job. Poll with get_status (jobId) instead until it reaches a terminal status.

End-to-end workflow for "pull files from this SFTP server / S3 bucket on a schedule" requests: reuses a matching connection if one already exists in the workspace (same hostname/username for sftp, same roleArn for aws_s3), otherwise creates one; tests it; then creates a trigger that feeds an already-analyzed data spec (see onboard_data_source) on the given frequency. Pass hostname for an sftp pull

Escape hatch for DPF capabilities that don't have a dedicated tool yet. ALWAYS prefer a dedicated tool when one exists — get_status, list_data, submit_query, delete_data_spec, onboard_data_source, update_data_spec, run_data_job, manage_connection, manage_trigger, setup_scheduled_pull, list_my_workspaces, create_workspace — and reach for this only when none of those fit (e.g. "how many credits do I

Returns instructions for creating a DPF account, verifying its email, resending the verification code, or resetting a forgotten password — it never performs these itself and never asks for a password. A password typed into this chat would sit in the conversation transcript, so every action instead returns the DPF website's own form, or a curl command that reads the password from a shell variable t

Send a message to the DPF team — request a demo, ask about licensing, report an issue, or request a feature. No authentication required. Always ask the user for their email if they have not already given it in this conversation.