AI-powered data integration platform. Onboard users and run DPF data workflows.
| Endpoint | https://api.dpf-it.com/mcp (streamable-http) |
|---|---|
| Registry version | 1.0.0 |
| Now | 18 tools · grade F (37) · pin ts_3b434e1bc3a598ebf69074aa134dd824 · protocol 2025-06-18 |
| First / last listed | 2026-10-27 06:41 UTC / 2026-10-27 06:41 UTC |
| Grade over time | 2026-10-27: F (37), 18 tools |
Is this your server? Own a server? ToolFit hosted watch re-checks it every 24 h ($0.25 per 30 days) or 6 h ($0.60) and sends you an HMAC-signed webhook when its tools or grade change: POST https://api.youraitools.co/toolfit/v1/watch. To opt out, see About & opt-out.
Tools: list_my_workspaces create_workspace list_data get_status delete_data_spec submit_query manage_connection manage_trigger onboard_data_source finish_data_source_onboarding update_data_spec finish_data_spec_update run_data_job finish_data_job setup_scheduled_pull call_dpf_api manage_account contact
list_my_workspaces | List every workspace the authenticated user has access to, including their permission on each. params: none |
create_workspace | Create a new workspace, owned by the authenticated user. Use this if list_my_workspaces returns none. params: name*, description |
list_data | 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 params: workspaceId, resource*, pageSize, cursor |
get_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 a params: workspaceId, specId, jobId |
delete_data_spec | Permanently delete a data spec and its associated configuration. params: workspaceId, specName* |
submit_query | 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 params: workspaceId, sql* |
manage_connection | 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 params: workspaceId, action*, type, hostname, username, roleArn, connectionId |
manage_trigger | 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 params: workspaceId, action*, triggerId, specName, connectionId, type, s3Bucket, s3Prefix, frequency, upstreamSpecName, preRules, postRules, dedupe, enabled, specId, pageSize, cursor, startTime, endTime |
onboard_data_source | 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 params: workspaceId, specName*, description, sourceType, sourceTables, expirePriorSnapshots, targetOption, targetTables, targetSchemaFileName, sampleFileName, formatFileName, merge, additionalPrompt, autoRefresh, autoRefreshUpstreamSpecName, autoRefreshFrequency |
finish_data_source_onboarding | 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 params: workspaceId, specId*, specName*, loadSampleData |
update_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 params: workspaceId, specName*, description, targetOption, targetTables, targetSchemaFileName, sampleFileName, formatFileName, sourceTables, merge, computeSize, additionalPrompt, loadSampleData, runAnalysis, confirmedCurrentInputs |
finish_data_spec_update | 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 params: workspaceId, specId*, specName*, runAnalysis, loadSampleData |
run_data_job | 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 params: workspaceId, specName*, fileNames* |
finish_data_job | 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. params: workspaceId, jobId*, specName* |
setup_scheduled_pull | 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 params: workspaceId, hostname, username, roleArn, s3Bucket, s3Prefix, specName*, frequency*, preRules, postRules, dedupe |
call_dpf_api | 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 params: path*, action*, workspaceId, params |
manage_account | 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 params: action*, email*, firstName, lastName, termsAccepted, otp |
contact | 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. params: reason*, message*, email*, name |
Entries describe changes in tool definitions. They are not statements about a server, its quality or its author. The grade measures how the tool definitions fit model providers (token cost, schema compatibility, confusable names) as scored by the ToolFit engine at the time of the listing. JSON: append .json. Opt-out: how or hello@youraitools.co.