com.dpf-it/mcp-server

Est-ce que com.dpf-it/mcp-server est sûr ?

Au dernier audit MCP Hub, le serveur MCP « com.dpf-it/mcp-server » est classé « Non encore testé ». Référencé dans l'annuaire. Seul le pentest comportemental fait foi, et il n'a pas encore été exécuté sur ce serveur. Le verdict est réévalué en continu ; consultez la fiche pour l'état à jour.

Méthode : MCP Hub analyse la description de chaque outil (couche 1) et, pour le verdict fort, exécute le serveur dans une micro-VM isolée avec leurres et réseau bloqué (couche 2). On publie des noms et des compteurs, jamais le contenu brut renvoyé par un outil.

Les 18 outils

• call_dpf_api≈ 805 tokens

  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 this server's tools were last updated). Every DPF endpoint is POST <path> with a JSON body of { action, ...fields }, authenticated with your OAuth session automatically. Pass workspaceId explicitly for workspace-scoped actions (data-specs, connections, job-triggers, and under "/workspaces": get-workspace, list-queries, list-bytes-accessed, list-storage, list-processed-files, list-trigger-runs) — omit it entirely for account-level actions that reject one (under "/workspaces": create, get-workspaces, grant-permission, revoke-permission, update/delete-workspace; under "/auth/billing": get-balance only — billing mutations such as purchase-credits, modify-subscription, manage-payment, and create-customer are NOT available via MCP; direct the user to https://dpf-it.com/workspace.html#credits for all credit and subscription management). If unsure of an action's exact fields, read the "dpf-openapi-spec" resource (dpf://openapi/spec.yaml) rather than guessing. Exception: the raw Iceberg REST proxy under "/iceberg/v1/..." (e.g. to read or set a table's "dpf.primary-keys" property via a commit-table request) does not use the action convention at all — give action any placeholder string (it's ignored) and put the real Iceberg REST commit body, e.g. {"requirements":[],"updates":[{"action":"set-properties","updates":{"dpf.primary-keys":"col_a,col_b"}}]}, in params. This tool only issues POST, so Iceberg's GET-based reads (loadTable, listTables) aren't reachable this way. Returns the raw response data (or, for endpoints like the Iceberg proxy with no {success, data} envelope, the whole response body).

  Paramètres, retour & exemple (4)

  Paramètres

  • path · string · requis
    API path, e.g. "/auth/billing" (leading slash, no query string).
  • action · string · requis
    The "action" field this endpoint routes on, e.g. "get-balance".
  • params · object · optionnel
    Additional action-specific fields to merge into the request body alongside action/workspaceId.
  • workspaceId · string · optionnel
    Include for workspace-scoped actions. Omit entirely for account-level actions.

  Exemple d'appel

  {"name": "call_dpf_api", "arguments": {"path": "texte", "action": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• contact≈ 233 tokens

  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.

  Paramètres, retour & exemple (4)

  Paramètres

  • name · string · optionnel
  • email · string · requis
    The sender's email address, so DPF can reply.
  • reason · string · requis · request-a-demo | understand-licensing | report-an-issue | request-a-feature
  • message · string · requis

  Exemple d'appel

  {"name": "contact", "arguments": {"email": "texte", "reason": "request-a-demo", "message": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• create_workspace≈ 349 tokens

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

  Paramètres, retour & exemple (2)

  Paramètres

  • name · string · requis
    Workspace name
  • description · string · optionnel
    Optional workspace description.

  Exemple d'appel

  {"name": "create_workspace", "arguments": {"name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"name": "texte", "createdAt": "texte", "createdBy": "texte", "permission": "texte", "description": "texte", "permissions": [], "workspaceId": "texte", "userPermission": "texte"}}

• delete_data_spec≈ 337 tokens

  Permanently delete a data spec and its associated configuration.

  Paramètres, retour & exemple (2)

  Paramètres

  • specName · string · requis
    Name of the data spec to delete.
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.

  Exemple d'appel

  {"name": "delete_data_spec", "arguments": {"specName": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"errors": [], "specId": "texte", "message": "texte", "specName": "texte", "retainedJobs": 1, "deletedS3Data": 1, "alreadyDeleted": true, "deletedS3Specs": 1, "deletedTargetTables": 1}}

• finish_data_job≈ 471 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

  • jobId · string · requis
    jobId returned by run_data_job.
  • specName · string · requis
    Name of the data spec this job belongs to.
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.

  Exemple d'appel

  {"name": "finish_data_job", "arguments": {"jobId": "texte", "specName": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"error": "texte", "jobId": "texte", "specId": "texte", "status": "texte", "endTime": "texte", "jobSize": "texte", "message": "texte", "metrics": {}, "progress": 1, "timedOut": true, "startTime": "texte", "durationMs": 1}}

• finish_data_source_onboarding≈ 621 tokens

  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 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 tool again just to keep checking — that re-attempts starting analysis. Poll with get_status (specId) instead until it reaches a terminal status.

  Paramètres, retour & exemple (4)

  Paramètres

  • specId · string · requis
    specId returned by onboard_data_source.
  • specName · string · requis
    Name of the data spec being onboarded.
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.
  • loadSampleData · boolean · optionnel
    Whether to load the sample file and trigger the data-load job once analysis finishes (default true).

  Exemple d'appel

  {"name": "finish_data_source_onboarding", "arguments": {"specId": "texte", "specName": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"error": "texte", "specId": "texte", "status": "texte", "message": "texte", "progress": 1, "timedOut": true, "lastJobId": "texte", "workspaceId": "texte", "errorDetails": "texte", "statusMessage": "texte", "analysisEndTime": "texte", "analysisStartTime": "texte"}}

• finish_data_spec_update≈ 676 tokens

  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 (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.

  Paramètres, retour & exemple (5)

  Paramètres

  • specId · string · requis
    specId returned by update_data_spec.
  • specName · string · requis
    Name of the data spec being updated.
  • runAnalysis · boolean · optionnel
    Default true — set false to skip analysis and just confirm the upload.
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.
  • loadSampleData · boolean · optionnel
    Whether analysis should also trigger the data-load job (default true).

  Exemple d'appel

  {"name": "finish_data_spec_update", "arguments": {"specId": "texte", "specName": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"error": "texte", "specId": "texte", "status": "texte", "message": "texte", "progress": 1, "timedOut": true, "lastJobId": "texte", "workspaceId": "texte", "errorDetails": "texte", "statusMessage": "texte", "analysisEndTime": "texte", "analysisStartTime": "texte"}}

• get_status≈ 612 tokens

  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.

  Paramètres, retour & exemple (3)

  Paramètres

  • jobId · string · optionnel
    Poll a data-load job's status. Pass exactly one of specId or jobId.
  • specId · string · optionnel
    Poll a data spec's analysis status. Pass exactly one of specId or jobId.
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.

  Exemple d'appel

  {"name": "get_status", "arguments": {"jobId": "texte", "specId": "texte", "workspaceId": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"error": "texte", "jobId": "texte", "specId": "texte", "status": "texte", "endTime": "texte", "jobSize": "texte", "metrics": {}, "progress": 1, "lastJobId": "texte", "startTime": "texte", "durationMs": 1, "logLocation": "texte"}}

• list_data≈ 1221 tokens

  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 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 describe configured pipelines (parsing/mapping rules), not the live set of Iceberg tables in the workspace. Multiple specs can target the same table (e.g. one spec creates it, another merges more data into it), and specs can be deleted or fail without the underlying table being dropped. For "what tables exist in my workspace" or any question about actual current data, use submit_query with `SHOW TABLES` instead of inferring an answer from specs.

  Paramètres, retour & exemple (4)

  Paramètres

  • cursor · string · optionnel
    Opaque `nextCursor` from a prior page (omit for the first page).
  • pageSize · integer · optionnel
    Records per page (default 25).
  • resource · string · requis · specs | jobs
    Which kind of resource to list
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.

  Exemple d'appel

  {"name": "list_data", "arguments": {"resource": "specs"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"jobs": [], "count": 1, "specs": [], "pageSize": 1, "nextCursor": "texte"}}

• list_my_workspaces≈ 330 tokens

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

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "list_my_workspaces", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"count": 1, "workspaces": []}}

• manage_account≈ 522 tokens

  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 yourself even if you have shell access, since composing the export line would require seeing the password. action "register": requires email, firstName, lastName, and termsAccepted: true (only after the user has explicitly agreed to the DPF Terms of Service and Privacy Policy in this conversation). action "verify": confirm the 6-digit code DPF emailed after registration (requires otp). action "resend": re-send that code if it never arrived. action "forgot-password": request a password-reset code (requires email). action "reset-password": submit that code and set a new password (requires otp).

  Paramètres, retour & exemple (6)

  Paramètres

  • otp · string · optionnel
    action "verify" and "reset-password" only. The 6-digit code from the email DPF sent.
  • email · string · requis
  • action · string · requis · register | verify | resend | forgot-password | reset-password
  • lastName · string · optionnel
    action "register" only
  • firstName · string · optionnel
    action "register" only
  • termsAccepted · boolean · optionnel
    action "register" only. Must be true.

  Exemple d'appel

  {"name": "manage_account", "arguments": {"email": "texte", "action": "register"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• manage_connection≈ 862 tokens

  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 permissions policy granting the S3 access DPF needs, before test will succeed. Either type must pass test before it can be used in a trigger. For a first-time "pull files from this server/bucket on a schedule" request, prefer setup_scheduled_pull, which chains create + test + create-trigger for you.

  Paramètres, retour & exemple (7)

  Paramètres

  • type · string · optionnel · sftp | aws_s3
    Connection type. Required for create; defaults to "sftp".
  • action · string · requis · create | list | test | delete
    Which operation to perform.
  • roleArn · string · optionnel
    aws_s3 only. The IAM role the customer will create/update. Required for create.
  • hostname · string · optionnel
    sftp only. Remote server hostname. Required for create.
  • username · string · optionnel
    sftp only. Remote username. Optional for create; defaults to "sftpuser".
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.
  • connectionId · string · optionnel
    Existing connection to test or delete. Required for test/delete.

  Exemple d'appel

  {"name": "manage_connection", "arguments": {"action": "create"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"type": "sftp", "count": 1, "account": "texte", "message": "texte", "roleArn": "texte", "success": true, "hostname": "texte", "username": "texte", "createdAt": 1, "createdBy": "texte", "fileCount": 1, "publicKey": "texte"}}

• manage_trigger≈ 2279 tokens

  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. The connection must already exist and have passed test (see manage_connection). For a first-time "set up a daily/scheduled pull" request, prefer setup_scheduled_pull, which sets up the connection and trigger together. - "spec_success": fires a spec automatically whenever a DIFFERENT spec's job completes successfully (set upstreamSpecName to that spec). No connection/frequency. Use this when the request ties the run to another job finishing (e.g. "run this after the customers load finishes"). - "schedule": fires a spec directly on a plain frequency (hourly/daily/monthly, UTC), no connection and no upstream spec. Use this when the request is time-based with no dependency (e.g. "run this every morning"). IMPORTANT: "spec_success" and "schedule" triggers can only 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 to re-run or a set of tables to compact. If asked to set up a scheduled/recurring job that reads from an already-loaded table (e.g. "keep a daily summary of the orders table up to date"), create that as an onboard_data_source sourceType "tables" spec first, THEN create the trigger here. Same for a recurring compaction — create the sourceType "compaction" spec first. Prefer "spec_success" when the user's phrasing implies "after X loads/finishes"; prefer "schedule" when they just want a cadence with no stated dependency; ask if genuinely ambiguous. For sftp/aws_s3, the referenced spec must already have been analyzed once (see onboard_data_source). After firing a trigger (action "run-now") — or any one-off manual run — use action "run-history" to monitor its outcome: it starts as `status: running` and settles to `success`, `failed`, or `no-files`, with `filesPulled` and a `message`.

  Paramètres, retour & exemple (19)

  Paramètres

  • type · string · optionnel · sftp | aws_s3 | spec_success | schedule
    Trigger type. Optional for create (defaults to "sftp"). For sftp/aws_s3 must match the connection's type.
  • action · string · requis · create | list | update | delete | run-now | clear-processed-files | run-history
    Which operation to perform.
  • cursor · string · optionnel
    run-history: opaque `nextCursor` from a prior page (omit for the first page).
  • dedupe · boolean · optionnel
    sftp/aws_s3 only. Required for create — ask the user rather than assuming a value; do not default it silently. Whether repeat pulls should skip files already loaded into this spec, matched by file name. Has real consequences: with dedupe true, a file that reappears under the same name (e.g. re-uploaded with corrected data) will be silently skipped; with dedupe false, an unchanged file left on the server will be reloaded every run. Omit only for update, where omitting leaves the trigger's existing setting unchanged.
  • specId · string · optionnel
    run-history: filter to runs of triggers feeding this spec.
  • enabled · boolean · optionnel
    Whether the trigger is active. Defaults to true on create.
  • endTime · string · optionnel
    run-history: ISO 8601 upper bound (inclusive) on when the run started.
  • pageSize · integer · optionnel
    run-history: records per page (default 25).
  • preRules · string · optionnel
    sftp/aws_s3 only. Natural language: which files to pick up (e.g. "only *.csv under /outbound").
  • s3Bucket · string · optionnel
    aws_s3 only. Bucket to poll. Required for create when type is "aws_s3", or to change it on update. Each run lists at most 5000 objects from the bucket/prefix (oldest key first) — past that, new files can be missed. On create, a successful response includes a `warnings` array with this note; relay it to the user and suggest an S3 lifecycle rule to expire/transition old objects.
  • s3Prefix · string · optionnel
    aws_s3 only. Optional key prefix; defaults to the whole bucket.
  • specName · string · optionnel
    The spec this trigger fires. Required for create.
  • frequency · object · optionnel
    Required for create when type is "sftp", "aws_s3", or "schedule"; optional on update to change the schedule. Not applicable to spec_success.
  • postRules · string · optionnel
    sftp/aws_s3 only. Natural language: what to do after a file loads (e.g. "rename with .done suffix").
  • startTime · string · optionnel
    run-history: ISO 8601 lower bound (inclusive) on when the run started.
  • triggerId · string · optionnel
    Existing trigger. Required for update/delete/run-now/clear-processed-files.
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.
  • connectionId · string · optionnel
    sftp/aws_s3 only. Connection to pull from. Required for create when type is "sftp"/"aws_s3". Also usable as a run-history filter.
  • upstreamSpecName · string · optionnel
    spec_success only. The spec whose successful job completion fires this trigger. Required for create when type is "spec_success".

  Exemple d'appel

  {"name": "manage_trigger", "arguments": {"action": "create"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"runs": [], "type": "sftp", "count": 1, "dedupe": true, "specId": "texte", "deleted": 1, "enabled": true, "message": "texte", "pageSize": 1, "preRules": "texte", "s3Bucket": "texte", "s3Prefix": "texte"}}

• onboard_data_source≈ 2385 tokens

  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_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 is to derive/aggregate data that is ALREADY loaded into workspace tables — e.g. "build me a daily summary of the customers table", or "set up a job that reads from the orders table and maintains a running total" — rather than loading a new file. It generates a SQL query (INSERT or MERGE, per `merge`) via AI instead of a Python parser, run through the query engine instead of a Glue job. There are never sample/format files, but targetOption still works the same three ways as sourceType "file" (see targetOption below) — so this call returns files: [] and you can call finish_data_source_onboarding immediately UNLESS targetOption is "target-schema-file", in which case it returns one upload URL for that file, same as the file-source path. The generated SQL automatically windows itself to rows added since the spec's last successful run. sourceType "tables" ALSO requires autoRefresh — how this spec stays up to date is not optional to decide, and must not be inferred from other jobs/triggers that happen to already exist in the workspace: ask the user whether it should re-run automatically whenever a specific upstream spec finishes loading ("spec_success" — the natural choice when the request is "run this after X finishes/loads"), on a plain cron-like cadence ("schedule" — the natural choice when the request is "run this every day/hour" with no mention of depending on another job), or stay manual-only ("none" — re-run later with run_data_job). If the request already states the timing unambiguously, that answers it; otherwise ask before calling this tool. Getting this wrong either way has a real cost: "none" means the summary silently goes stale until someone remembers to re-run it by hand, while an unwanted trigger keeps re-running (and charging credits for) a spec the user only wanted once. See autoRefresh below.

  Paramètres, retour & exemple (16)

  Paramètres

  • merge · boolean · optionnel
    Upsert instead of plain append when true (default false). For sourceType "tables": generates a MERGE statement instead of an INSERT — use true for a running aggregate/summary that updates existing rows. For sourceType "file" with targetOption "existing-tables": upserts loaded rows by the target table's inferred key instead of always inserting — use true whenever the request implies re-loading the same rows shouldn't create duplicates (e.g. "upsert on id", syncing/backfilling into a table that already has overlapping rows). Already automatic, no need to request it via additionalPrompt: target columns with no corresponding source column are null on newly inserted rows, and on a match keep their existing value rather than being nulled out.
  • specName · string · requis
    Name for the new data spec.
  • sourceType · string · optionnel · file | tables | compaction
    Defaults to "file" (upload a sample file). Use "tables" to query existing workspace table(s) — see 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.
  • autoRefresh · string · optionnel · spec_success | schedule | none
    sourceType "tables" only. Required for it — ask the user rather than assuming, and do not infer this from other jobs/triggers already in the workspace (a similar existing pipeline is not the user's answer for this one). "spec_success" re-runs this spec whenever autoRefreshUpstreamSpecName finishes loading; "schedule" re-runs it on autoRefreshFrequency; "none" leaves it manual-only (re-run later with run_data_job).
  • description · string · optionnel
    Optional description of the data spec.
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.
  • sourceTables · array · optionnel
    Names of existing workspace tables. Required for sourceType "tables" (the tables the generated query reads from) and for sourceType "compaction" (the tables to compact).
  • targetOption · string · optionnel · auto-infer | existing-tables | target-schema-file
    Where transformed data should land — works the same for both sourceType values: "auto-infer" (default) lets the AI design the target table (for sourceType "tables", it designs the schema and the query together in one pass), "existing-tables" uses a table already in the workspace (requires targetTables), "target-schema-file" creates the table from a provided schema file (requires targetSchemaFileName).
  • targetTables · array · optionnel
    Names of existing workspace tables to target — exactly one entry for sourceType "tables" (the generated query has a single target), one or more for sourceType "file". Required when targetOption is "existing-tables". Optional otherwise: for "target-schema-file"/"auto-infer" the target table (and its name) is derived automatically — from the schema file, or AI-designed — unless you want to pin the name yourself, in which case pass exactly one entry.
  • formatFileName · string · optionnel
    sourceType "file" only. File name of an optional format spec file.
  • sampleFileName · string · optionnel
    sourceType "file" only (and required for it). File name of the sample data file (e.g. "customers.csv") — used to derive content-type, not read from disk.
  • additionalPrompt · string · optionnel
    Instructions for the AI. For sourceType "tables", describe what the query should compute from the source table(s) (e.g. "count signups per day per region"). This is stored on the spec verbatim and reused on every future re-analysis, so keep it to instructions that actually change behavior — do not restate default platform behavior (e.g. that unmapped target columns are null/preserved, see merge above) just to document it, since a note that's only true for one case (like new rows) can read as a standing instruction later and cause confusion on updates.
  • autoRefreshFrequency · object · optionnel
    Required when autoRefresh is "schedule".
  • expirePriorSnapshots · boolean · optionnel
    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.
  • targetSchemaFileName · string · optionnel
    File name of a target schema file. Required when targetOption is "target-schema-file", for either sourceType.
  • autoRefreshUpstreamSpecName · string · optionnel
    Required when autoRefresh is "spec_success". The spec whose successful job completion should re-run this one.

  Exemple d'appel

  {"name": "onboard_data_source", "arguments": {"specName": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"files": [], "specId": "texte", "message": "texte", "nextStep": "texte", "specName": "texte", "triggerId": "texte"}}

• run_data_job≈ 561 tokens

  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 already load and process the sample file as their own job (see the returned lastJobId), so calling run_data_job again for that same file creates a redundant second job. Only use this for files beyond the initial sample (new batches, additional files to process later).

  Paramètres, retour & exemple (3)

  Paramètres

  • specName · string · requis
    Name of the already-configured data spec to process files through.
  • fileNames · array · requis
    File names of the data files to process (e.g. ["jan.csv", "feb.csv"])
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.

  Exemple d'appel

  {"name": "run_data_job", "arguments": {"specName": "texte", "fileNames": []}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"files": [], "jobId": "texte", "message": "texte", "nextStep": "texte", "specName": "texte"}}

• setup_scheduled_pull≈ 1136 tokens

  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 this instead of calling manage_connection + manage_trigger yourself for first-time setup. If the connection test fails (e.g. the sftp public key or the aws_s3 IAM role isn't set up yet on the customer's side), no trigger is created — ask the user to finish that setup and re-run this tool, which will reuse the same connection and pick up where it left off. This is for pulling a NEW file from an external source — for "run this on a schedule/after another job" where the spec queries tables already in the workspace (sourceType "tables"), use manage_trigger with type "schedule" or "spec_success" instead; there is no connection involved.

  Paramètres, retour & exemple (11)

  Paramètres

  • dedupe · boolean · optionnel
    Required — ask the user rather than assuming a value; omitting it fails the call. Whether repeat pulls should skip files already loaded into this spec, matched by file name. Has real consequences: with dedupe true, a file that reappears under the same name (e.g. re-uploaded with corrected data) will be silently skipped; with dedupe false, an unchanged file left on the server will be reloaded every run.
  • roleArn · string · optionnel
    aws_s3: the IAM role the customer will create/update.
  • hostname · string · optionnel
    sftp: SFTP server hostname to pull from.
  • preRules · string · optionnel
    Natural language: which files to pick up (e.g. "only *.csv under /outbound")
  • s3Bucket · string · optionnel
    aws_s3: bucket to poll. Required when roleArn is given.
  • s3Prefix · string · optionnel
    aws_s3 only. Optional key prefix; defaults to the whole bucket.
  • specName · string · requis
    Already-analyzed data spec to load files into (see onboard_data_source)
  • username · string · optionnel
    sftp only. Defaults to "sftpuser".
  • frequency · object · requis
    Pull schedule.
  • postRules · string · optionnel
    Natural language: what to do after a file loads (e.g. "rename with .done suffix")
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.

  Exemple d'appel

  {"name": "setup_scheduled_pull", "arguments": {"specName": "texte", "frequency": {}}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"dedupe": true, "specId": "texte", "enabled": true, "message": "texte", "s3Bucket": "texte", "s3Prefix": "texte", "specName": "texte", "warnings": [], "frequency": {}, "triggerId": "texte", "connectionId": "texte", "testSucceeded": true}}

• submit_query≈ 666 tokens

  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 external-data-source access — don't try to discover available SQL functions this way. A BLOB column is very likely an HLL sketch (produced by a merge-mode table-source spec's approximate-distinct aggregate — see onboard_data_source's merge option): decode it with datasketch_hll_estimate(col), or datasketch_hll_estimate(datasketch_hll_union(12, col)) to union several rows to a coarser grain first. If the user's goal is an HTML page/dashboard built from these results (not just seeing the data here), do NOT default to embedding this result set as a static snapshot. Ask the user first: (a) a one-time static page with these results baked in, which goes stale and never changes again, or (b) a live page that logs in and queries DPF itself whenever it's opened, so it always reflects current data. If they want live/dynamic (or don't say and the data looks like it changes over time), read the dpf://examples/auth-and-query.html resource and adapt that pattern (login form, JWT cookie, fetch-based query call) instead of hand-rolling auth.

  Paramètres, retour & exemple (2)

  Paramètres

  • sql · string · requis
    SQL query, e.g. SELECT * FROM customers LIMIT 10
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.

  Exemple d'appel

  {"name": "submit_query", "arguments": {"sql": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"rows": [], "schema": [], "rowCount": 1, "executionTimeMs": 1}}

• update_data_spec≈ 1772 tokens

  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. 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.

  Paramètres, retour & exemple (15)

  Paramètres

  • merge · boolean · optionnel
    Whether new data should merge/upsert into existing rows rather than append. For sourceType "tables" also changes the generated SQL between MERGE and INSERT.
  • specName · string · requis
    Name of the existing data spec to update
  • computeSize · string · optionnel · small | large
    Compute size for analysis/processing. Omit to keep the current setting.
  • description · string · optionnel
    New description for the spec. Omit to keep the current value.
  • runAnalysis · boolean · optionnel
    Whether to run analysis and wait for it after saving the changes (default true). Only applies to the synchronous (no-file-change) path.
  • workspaceId · string · optionnel
    Workspace to act on. Defaults to your only workspace if you have exactly one.
  • sourceTables · array · optionnel
    sourceType "tables" specs only: replacement list of source tables the generated query reads from.
  • targetOption · string · optionnel · auto-infer | existing-tables | target-schema-file
    Change where transformed data lands. Omit to keep the current setting.
  • targetTables · array · optionnel
    sourceType "file" specs: new list of existing workspace tables to load into. Required when setting targetOption to "existing-tables". sourceType "tables" specs: the query's single target table name — pass a one-element array to rename the target (its schema is re-resolved per the spec's targetOption).
  • formatFileName · string · optionnel
    sourceType "file" specs only. File name of a replacement format spec file. The format spec outranks the sample when deriving field boundaries, so re-send it alongside a replacement sample rather than letting a new sample be parsed by an old spec.
  • loadSampleData · boolean · optionnel
    Whether re-analysis should also trigger the data-load job (default true). Only used when runAnalysis is true.
  • sampleFileName · string · optionnel
    sourceType "file" specs only. File name of a replacement sample data file. Send this whenever the source data the user is describing differs in any way from the stored sample — the regenerated parser and mapping are built from this file, so a stale one silently mis-maps the new target.
  • additionalPrompt · string · optionnel
    Extra natural-language guidance for the AI schema inference/mapping. Replaces the previously stored value when given (omit to keep it as-is), and is reused on every future re-analysis — keep it to instructions that actually change behavior. Don't restate default platform behavior (e.g. that unmapped target columns are null on insert and preserved on merge match) just to document it; a note only true for one case (like new rows) can read as a standing instruction later and confuse updates.
  • targetSchemaFileName · string · optionnel
    File name of a replacement target schema file. Required when setting targetOption to "target-schema-file". Replacing this re-derives the whole mapping against the stored sample/format files — re-send those here too unless you have confirmed they still represent the source data.
  • confirmedCurrentInputs · boolean · optionnel
    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.

  Exemple d'appel

  {"name": "update_data_spec", "arguments": {"specName": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"error": "texte", "files": [], "specId": "texte", "status": "texte", "message": "texte", "nextStep": "texte", "progress": 1, "specName": "texte", "timedOut": true, "lastJobId": "texte", "errorDetails": "texte", "statusMessage": "texte"}}

C'est votre serveur ?

Revendiquez-le sur l'espace créateur (preuve GitHub, domaine ou npm) pour afficher le badge « propriétaire vérifié » et lancer un pentest comportemental à la demande afin d'obtenir le badge « Vérifié ».

Créer un compte / revendiquer →

Source

https://api.dpf-it.com/mcp