DPF

List my workspaces

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

Create a workspace

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

List data specs or jobs

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. This is NOT a table listing — specs describe configured pipelines (parsing/mapping rules), not the live set of Iceberg tables i

Get spec or job status

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 at the data-load job — poll that separately by jobId for load progress.

Delete a data spec

Permanently delete a data spec and its associated configuration.

Query workspace data

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 introspect the engine itself (e.g. duckdb_functions(), duckdb_tables()) are also rejected as externa

Manage an external data-source connection (SFTP, AWS S3)

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 dpfPrincipalArn — the customer must create (or update) the IAM role at roleArn with that trust policy and a pe

Manage a workspace trigger (SFTP/AWS S3 pull, spec chaining, or schedule)

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 postRules (what to do after upload) are compiled into executable code server-side — never pass raw code.

Onboard a new data source, step 1: create a data spec and get upload URL(s)

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) — upload the file(s) per the returned instructions, then call finish_data_source_onboarding with the returned specId to kick off AI analysis and wait for it to complete. Use sourceType "tables" instead when the request is to derive/aggregate data that is ALREADY loaded into workspace tables — e.g. "

Onboard a new data source, step 2: run analysis after uploading

Call after uploading the file(s) returned by onboard_data_source — kicks off AI analysis and waits until the spec reaches "ready" or "failed". If it returns before that (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.

Update an existing data spec

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 fields you want to change — omitted fields keep their current value.

Update an existing data spec, step 2: run analysis after uploading

Call after uploading the file(s) returned by update_data_spec — kicks off AI analysis and waits until the spec reaches "ready" or "failed". If it returns before that (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.

Run a data processing job, step 1: create job and get upload URL(s)

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/finish_data_spec_update unless loadSampleData was explicitly set to false there — by default those alread

Run a data processing job, step 2: start processing after uploading

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.

Set up a scheduled SFTP or S3 pull into an existing data spec

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, or roleArn (+ s3Bucket, required) for an aws_s3 pull — exactly one of the two is expected. Use thi

Call any DPF API action (fallback for requests with no dedicated tool)

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 have?" -> path "/auth/billing", action "get-balance"; a brand-new action added to the API since thi

Get instructions for DPF account signup, email verification, or password reset

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 the user sets themselves in their own terminal. Hand the command to the user to run — do not run it y

Send a message to the DPF team

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.