DPF
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/listare 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/callforwards to the live endpoint (DPF_MCP_URL, defaults tohttps://api.dpf-it.com/mcp) withAuthorization: Bearer $DPF_TOKEN. WithoutDPF_TOKENset, 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-bridgeor with Docker:
docker build -t dpf-mcp-bridge .
docker run -i -e DPF_TOKEN=<your OAuth access token> dpf-mcp-bridgeObtain 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 toolscall_dpf_apiCall any DPF API action (fallback for requests with no dedicated tool)ADestructive
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 specADestructiveIdempotent
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 uploadingAIdempotent
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 uploadingAIdempotent
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 statusARead-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 jobsARead-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 workspacesARead-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)ADestructive
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)ADestructive
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 dataARead-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 specAIdempotent
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
Scored across 16 tools
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.
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.
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.
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
Related MCP Connectors
AI-powered data integration platform. Onboard users and run DPF data workflows.
Build and manage data pipelines, add custom connectors, and chat with your data.
Run customer onboarding from your AI tool: build plans, deploy agents, find bottlenecks.
AI-Ready Data Platform that fills the missing layer between data management and AI execution.
Related MCP Servers
- AlicenseAqualityCmaintenanceAI workflow orchestration platform with 100+ integrations, knowledge graph, and unified credits. Build, manage, and execute workflows from Claude Code, Cursor, or any MCP client.40276 npm3MIT

@matihlabs/mcpofficial
AlicenseNot gradedqualityCmaintenanceConnects 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 npmApache 2.0- AlicenseNot gradedqualityBmaintenanceTurns 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
- AlicenseNot gradedqualityAmaintenanceEnables AI clients to discover, inspect, and run 2,000+ AI models and APIs through MCP, with free data APIs, OAuth sign-in, and rollback.556,724 npmMIT