@dpf-it/mcp-server

@dpf-it/mcp-server

MCP (Model Context Protocol) server for DPF — an AI-driven data integration platform built API-first, with every action available through both the REST API and this MCP server. This server lets AI agents and chat clients discover DPF, register new accounts, connect existing workspaces, and run end-to-end data integration workflows without leaving the conversation.

Quick start

No account or credentials required to begin — just add the server to your MCP client config:

{
  "mcpServers": {
    "dpf": {
      "command": "npx",
      "args": ["-y", "@dpf-it/mcp-server"]
    }
  }
}

Then in a chat session, ask the agent to "get started with DPF." If credentials are already saved from a previous session it will use them and proceed straight to your task; otherwise it will ask whether you have an existing account or workspace credential, or walk you through registration (including the emailed verification code) — and it remembers your connection for future sessions.

Pre-authorizing tools (skip per-tool permission prompts)

Most MCP clients ask for permission before each tool runs. To approve all DPF tools up front:

Claude Code — add the server to the permissions.allow list in your project's .claude/settings.json (or ~/.claude/settings.json for all projects):

{
  "permissions": {
    "allow": ["mcp__dpf"]
  }
}

mcp__dpf approves every tool from this server. To be more selective, list individual tools as mcp__dpf__<tool_name> (e.g. mcp__dpf__submit_query). You can also manage this interactively with the /permissions command.

Claude Desktop / claude.ai — when a tool first asks for permission, choose "Always allow" to stop prompts for that tool in future chats.

Other clients — most have an equivalent auto-approve setting for MCP tools (e.g. Cursor's auto-run mode); check your client's MCP settings.

Note that pre-authorizing lets the agent call any DPF tool without pausing for confirmation — including register_account and delete_data_spec. If that's a concern, allow everything except the tools you want to confirm manually.

How authentication works

DPF workspaces issue OAuth2 client_credentials pairs (clientId / clientSecret) from the workspace settings page (or via the login_and_list_workspaces + setup_workspace / connect_workspace tools below). This server:

• Stores those credentials locally at ~/.dpf/credentials.json (file permissions 0600), keyed by workspace.
• Exchanges them for short-lived bearer JWTs on demand via DPF's OAuth token endpoint, caching tokens in memory for the life of the process.
• Re-reads the credentials file on every startup, so once a workspace is connected, future sessions/chats need no further login.

You can connect multiple workspaces; tools accept an optional workspaceId and default to the first connected one if omitted.

Tools

Bootstrap (no auth required)

• get_started — explains DPF, reports which workspaces are already connected, and guides the agent through the right onboarding path (use saved credentials / connect existing / register new)
• register_account — create a brand-new DPF account (sends a 6-digit email verification code)
• verify_otp — confirm the emailed verification code; required before first login
• resend_otp — resend the verification code if it never arrived
• login_and_list_workspaces — log in and list the account's workspaces with the user's access role on each (the password itself is never stored)
• setup_workspace — connect the workspace the user chose (or create one if the account has none) and persist its credentials
• connect_workspace — connect an existing workspace using a clientId/clientSecret from the DPF portal
• list_workspaces — list locally connected workspaces

Data operations

• list_data — list a workspace's specs or jobs (pass resource: "specs" | "jobs")
• get_status — poll a spec's analysis status or a job's data-load status (pass exactly one of specId or jobId)
• delete_data_spec, submit_query

Skills (multi-step workflows)

• onboard_data_source — create a data spec, upload sample/format files, run AI analysis, and wait for it to complete
• update_data_spec — change an existing spec's config and/or replace its sample/format/target-schema files, then re-run AI analysis and wait for it to complete
• run_data_job — create a job for an existing spec, upload data files, start processing, and wait for completion

Example: a hand-rolled web frontend

examples/auth-and-query.html is a self-contained, dependency-free reference page showing how to talk to the DPF REST API directly from a browser: log in, store the JWT in a cookie, restore/expire that session on reload, run a query, and log out. It's deliberately unstyled — the point is the auth/cookie/query mechanics, not the UI — so copy it as a starting point and swap in your own styling or charting.

Before using it, set the NAMESPACE constant near the top of the script. A namespace is always the last 12 characters of the workspaceId — it's a fixed derivation, not a name you choose. Find yours with:

curl -H "Authorization: Bearer <token>" https://api.dpf-it.com/iceberg/v1/namespaces

Serve it over http(s) — don't open it as a file:// URL. Most browsers won't persist cookies for local files, so login appears to succeed but every subsequent request goes out with no token and fails. From the examples/ directory: npx serve (or python3 -m http.server), then open the printed URL.

Configuration

Env var	Default	Purpose
DPF_API_BASE_URL	https://api.dpf-it.com	DPF REST API base URL
DPF_OAUTH_TOKEN_URL	${DPF_API_BASE_URL}/iceberg/v1/oauth/tokens	OAuth2 client_credentials token endpoint

License

MIT