DPF
# dpf-mcp-bridge
A stdio MCP server that mirrors [DPF](https://dpf-it.com)'s tool surface for clients that can't speak
Streamable HTTP or do an OAuth redirect — most notably registry crawlers (e.g. [Glama](https://glama.ai/mcp/servers))
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](https://dpf-it.com/integration-guide.html) 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](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.
## 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](https://dpf-it.com/integration-guide.html), 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.
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.