Skip to main content
Glama

dpf-mcp-bridge

A stdio MCP server that mirrors DPF's tool surface for clients that can't speak Streamable HTTP or do an OAuth redirect — most notably registry crawlers (e.g. Glama) that need to see tools/list without an interactive login.

Most users don't need this. Claude, Cursor, VS Code, and other OAuth-aware MCP clients should connect directly to the real server at https://api.dpf-it.com/mcp — see the integration guide or the dpf plugin in this repo. This bridge exists for stdio-only clients and for directory listings.

How it works

  • initialize / tools/list are answered locally from schemas declared in server.js — no network call, no credentials required. That's what lets an automated sandbox introspect this server.

  • tools/call forwards to the live endpoint (DPF_MCP_URL, defaults to https://api.dpf-it.com/mcp) with Authorization: Bearer $DPF_TOKEN. Without DPF_TOKEN set, calls return an explanatory error instead of failing silently.

Related MCP server: @matihlabs/mcp

Run it

DPF_TOKEN=<your OAuth access token> npx dpf-mcp-bridge

or with Docker:

docker build -t dpf-mcp-bridge .
docker run -i -e DPF_TOKEN=<your OAuth access token> dpf-mcp-bridge

Obtain a token via the OAuth flow described in the integration guide, or self-serve a client_id/client_secret pair (POST /oauth/clients) and exchange it for an access token via the standard OAuth token endpoint.

Available Tools

16 tools
call_dpf_apiCall any DPF API action (fallback for requests with no dedicated tool)A
Destructive

Escape hatch for DPF capabilities with no dedicated tool. Every DPF endpoint is POST with a JSON body of { action, ...fields }, authenticated with your OAuth session. Billing mutations (purchase-credits, modify-subscription, manage-payment, create-customer) are not available via MCP — use the DPF web UI.

Inputs: path (required), action (required), params, workspaceId.

create_workspaceCreate a workspaceA

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

Inputs: name (required), description.

delete_data_specDelete a data specA
DestructiveIdempotent

Permanently delete a data spec and its associated configuration.

Inputs: specName (required), workspaceId.

finish_data_jobRun a data processing job, step 2: start processing after uploadingA
Idempotent

Call after uploading the file(s) returned by run_data_job — starts processing and waits until the job completes or fails. Poll with get_status instead of re-calling this if it times out.

Inputs: jobId (required), specName (required), workspaceId.

finish_data_source_onboardingOnboard a new data source, step 2: run analysis after uploadingA
Idempotent

Call after uploading the file(s) returned by onboard_data_source — kicks off AI analysis and waits until the spec reaches "ready" or "failed". Poll with get_status instead of re-calling this if it times out.

Inputs: specId (required), specName (required), workspaceId, loadSampleData.

finish_data_spec_updateUpdate an existing data spec, step 2: run analysis after uploadingA

Call after uploading the file(s) returned by update_data_spec — kicks off AI analysis and waits until the spec reaches "ready" or "failed". Poll with get_status instead of re-calling this if it times out.

Inputs: specId (required), specName (required), runAnalysis, workspaceId, +1 more.

get_statusGet spec or job statusA
Read-onlyIdempotent

Poll the status of either a data spec's analysis (pass specId, reaches "ready"/"failed") or a data-load job (pass jobId, reaches "complete"/"failed"). Pass exactly one of specId or jobId.

Inputs: jobId, specId, workspaceId.

list_dataList data specs or jobsA
Read-onlyIdempotent

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. Paginated (default 25/page, max 100, newest first); pass the returned nextCursor to fetch more. Not a table listing — for the live set of Iceberg tables in a workspace, use submit_query with SHOW TABLES instead.

Inputs: resource (required), cursor, pageSize, workspaceId.

list_my_workspacesList my workspacesA
Read-onlyIdempotent

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

Inputs: no named parameters.

manage_connectionManage an external data-source connection (SFTP, AWS S3)A
Destructive

Create, list, test, or delete a workspace connection to an external data source. For sftp, create generates a keypair and returns the public key to install in the remote server's authorized_keys. For aws_s3, create generates an ExternalId and trust policy for an IAM role the customer must create. A connection must pass test before it can be used in a trigger.

Inputs: action (required), type, roleArn, hostname, +3 more.

manage_triggerManage a workspace trigger (SFTP/AWS S3 pull, spec chaining, or schedule)A
Destructive

Create, list, update, delete, or fire a workspace job trigger. Types: "sftp"/"aws_s3" (pulls files from a connection into a spec on a schedule), "spec_success" (fires a spec when a different spec's job completes), "schedule" (fires a spec on a plain cadence, UTC). Use action "run-history" to monitor a fired trigger's outcome.

Inputs: action (required), type, cursor, dedupe, +15 more.

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

First step of setting up a new data integration: creates a data spec. sourceType "file" (default) returns presigned upload URL(s) for a sample file; upload, then call finish_data_source_onboarding. sourceType "tables" derives/aggregates data already loaded into workspace tables via an AI-generated SQL query instead, and requires autoRefresh (how the spec stays up to date: spec_success, schedule, or none).

Inputs: specName (required), merge, sourceType, autoRefresh, +11 more.

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

First step of processing new data files through an already-configured data spec: creates a job and returns upload URL(s). Upload, then call finish_data_job. Only for files beyond the initial sample.

Inputs: specName (required), fileNames (required), workspaceId.

setup_scheduled_pullSet up a scheduled SFTP or S3 pull into an existing data specA

End-to-end setup for "pull files from this SFTP server / S3 bucket on a schedule": reuses a matching connection if one exists, otherwise creates one; tests it; then creates a trigger feeding an already-analyzed spec on the given frequency. Pass hostname for sftp, or roleArn (+ s3Bucket) for aws_s3.

Inputs: specName (required), frequency (required), dedupe, roleArn, +7 more.

submit_queryQuery workspace dataA
Read-onlyIdempotent

Run a SQL query against the Iceberg tables loaded into a workspace. Run SHOW TABLES to list the tables that actually exist. Reference tables by name only (no catalog/schema-qualified references).

Inputs: sql (required), workspaceId.

update_data_specUpdate an existing data specA
Idempotent

Change an existing data spec's configuration. Runs synchronously when no replacement files are given (saves changes, re-runs analysis by default). If a replacement file name is given, returns upload URL(s) instead; upload, then call finish_data_spec_update. Only pass fields you want to change.

Inputs: specName (required), merge, computeSize, description, +10 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.1/5.0

    Scored across 16 tools

    Disambiguation4/5

    Each tool maps to a distinct workflow step or resource (query, workspace, spec, job, trigger, connection), and the finish_* helpers are clearly paired with their initiating tools. The main ambiguity is between list_data and submit_query, though the descriptions explicitly disambiguate them.

    Naming Consistency4/5

    Tool names are consistently snake_case and mostly verb-first, with clear patterns like finish_* pairing with onboard/update/run. The generic manage_ prefix on manage_connection and manage_trigger is a minor deviation from the more action-specific verbs used elsewhere.

    Tool Count4/5

    At 16 tools, the set is slightly above the typical 3-15 range, but the tools cover multiple distinct workflows including workspaces, specs, jobs, triggers, and connections. The finish_* helpers add count but serve necessary asynchronous continuation steps.

    Completeness4/5

    The tool surface covers the core data integration lifecycle end-to-end: workspace creation, spec onboarding/update/delete, job processing, triggers, scheduled pulls, status polling, and SQL querying. Minor gaps like workspace deletion or job cancellation are not exposed, but call_dpf_api partially offsets this and billing is intentionally left to the web UI.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      C
      maintenance
      Connects AI clients to the Matih data platform, enabling SQL queries, table profiling, analytics, chart creation, and file uploads through MCP tools with OAuth/PKCE authentication.
      87 npm
      Apache 2.0
    • A
      license
      Not graded
      quality
      B
      maintenance
      Turns Google Sheets, CSV, Excel, and Parquet files into durable, queryable data for AI agents. Lets clients securely discover datasets, inspect semantic models, run bounded analytics, and manage approved semantic overlays.
      Apache 2.0