New in DataForge 10.3
Build governed data pipelines with the AI agents your team already uses
Claude Code, Codex, and other MCP clients can build and operate complete pipelines while DataForge validates every change before it persists.
The DataForge MCP server runs your agents on your own Databricks or Snowflake compute, through the same 148-tool registry that powers Talos, with the same validation, the same permissions, and the same telemetry as any human edit. An invalid write is rejected at save with the exact next call to make, and there is no bypass path.
Governed agentic data engineering
Let agents build pipelines without letting them invent the architecture
Governed agentic data engineering means AI agents can do real pipeline work while the platform controls how that work is built. In DataForge, agents create the same governed objects as people do. The platform resolves dependencies, enforces processing sequence, applies role-based access, and rejects invalid changes before they persist.
The result is not a separate AI workflow beside your data platform. Ingestion, transformation, orchestration, delivery, and operations stay inside one enforced architecture, with processing on your Databricks or Snowflake compute and no special bypass for an agent.
Watch the demo
Give Claude Code a broken Power BI report. See what happens next.
Watch it use DataForge MCP to rebuild the solution on Databricks, correct mistakes as it works, and leave only the business decisions to the human.
Your compute platform
See how governed MCP fits your data cloud
DataForge keeps pipeline processing in your account. Review the deployment and control model for the platform your team already operates.
Proven on a real ERP integration
A newcomer extended a real enterprise model in ten days
A developer with little SQL and no professional data engineering experience extended a real enterprise model.
The work covered a complex multi-ERP environment at a global manufacturer.
The resulting data reconciled against the client's existing reports, verified by their own quality assurance.
The MCP features on this page were shaped by that project's friction, not by a demo.
Where the agent writes: files, raw SQL, or a validated platform object
Files and raw SQL accept anything an agent writes, and correctness arrives at runtime. Agents hallucinate schema names, assemble large solutions that break when they run, and burn tokens debugging their own output. A declarative platform can reject a wrong write at the moment of save and tell the agent exactly why.
Unconstrained agents
- The agent writes files and raw SQL that accept anything, so errors surface when the pipeline runs.
- Hallucinated schema and column names persist silently until execution fails.
- Each agent works on its own branch, and combining their work means merges and re-testing.
- Recovery means a human reading stack traces and prompting the agent again.
- Safety depends on the prompt, not on the platform.
Agents on DataForge
- Every write is validated at save: schema checks, SQL expression parsing, and permissions on every call.
- Invalid changes never persist. The agent gets the line and column of the problem and the exact next call to make.
- Each rule writes exactly one column, so agents build side by side with no merge conflicts and no integration re-testing to combine their work.
- Sequencing guards answer a too-early request with a structured retry, so agents never build against schemas that do not exist yet.
- The same validation applies to AI and humans. There is no bypass path.
From conversation to validated platform objects
A rejected write comes back as a structured answer the agent can act on: what failed, where, what to call next, and when. A write that passes becomes a governed platform object.
Example of the structured error contract. The invalid write never persists. The agent reads the instructions, fetches the real columns, and corrects itself in seconds.
Every column planned, validated, and saved as a governed platform object with lineage.
What your agent can do
The complete pipeline lifecycle, as concrete operations rather than a promise:
How it works
Six mechanisms, one guarantee
All six are built into the platform itself: the expression parser, the transactional metastore, and the guarded tool surface every agent call goes through. The agent carries no burden of current state, refactoring, dependencies, backfill or orchestration - those are all built into the DataForge platform.
01 Reject at save.
Rule expressions pass three validation layers before anything persists: pre-checks that reject invalid SQL constructs with line and column positions, a database pre-parse, and the product parser at the same parse-and-save API that human edits use. Errors surface at save instead of when the pipeline runs.
02 Errors are an API.
Every error returns as machine-readable JSON: a request identifier, plain instructions, the exact next call to make with its arguments, and when to retry. The design goal is agent self-correction.
03 One writer per column.
Every rule writes exactly one column, validated at save time in one transactional metastore. Multiple agents build side by side in the same project with no branches to manage while building, no merge conflicts to resolve, and no integration re-testing just to combine their work.
04 Sequencing guards.
If an agent asks for source columns before ingestion has completed, the server replies with a structured answer: what is missing, the tool to call, and retry in 60 seconds. The agent gets that retry instruction rather than an empty column list, so it has nothing to author rules against until ingestion completes.
05 No bypass.
Agents get no privileged path and no forgiving one. Every agent write goes through the same expression parser, the same schema constraints, the same database-enforced permissions, and the same confirmation gates on destructive actions as a human edit. No bypass mode, no reduced validation for AI.
06 Embedded metadata context.
The agent has current metadata context for every table in the data source, which is what makes expression validation at save accurate, plus optional, opt-in, guarded read-only data access. Agents on other platforms often have neither and have to impute schemas.
Guardrails your security team can audit
DataForge's MCP server is the only data engineering platform MCP we have found (public vendor documentation, July 2026) that combines all four of these guardrails in one surface: sequencing guards that answer a too-early request with "not ready yet, retry in N seconds" so agents never build against schemas that do not exist; cost guidance that steers agents away from expensive re-ingestion; destructive-action confirmation enforced server-side; and role-based permissions checked in the database on every tool call. Competitors ship pieces. None ships all four, and none ships sequencing guards at all.
Identity and access
- OAuth 2.1 with PKCE and dynamic client registration, with 8-hour access tokens and 30-day refresh tokens.
- Agents act as the signed-in user. Every project-scoped write re-checks the user's role in the database at call time.
- Machine users with short-lived machine-to-machine tokens cover headless automation.
- Destructive operations require explicit confirmation, enforced server-side.
Blast radius and observability
- Read-only access is the default posture, with role gates layered above it.
- SQL access to your data is off by default behind a customer opt-in flag, and metadata queries run on a dedicated read-only connection.
- Telemetry is shape-only and opt-in: every tool call is logged with outcome, latency, and the shape of arguments and results (field names and row counts), never values. Token and secret fields are redacted.
- The product version is stamped on every telemetry record, and the agent's operating manual is served from the deployed release itself, so instructions cannot drift from the version you run.
AI goes through the front door or not at all.
An invalid agent write is rejected at save with the same errors a human would see, plus machine-readable recovery instructions.
Review MCP security and technical controls →Connect an agent in one command
Your API host is your DataForge hostname with api in it, and the documentation gives the exact rule for cloud and self-hosted deployments. Then run /mcp in Claude Code and choose Authenticate: you sign in through your browser with your normal DataForge credentials, and no key or token is ever created or pasted. The server implements OAuth 2.1 with PKCE and dynamic client registration, so Claude Code, Codex, and any compliant MCP client can connect without pre-registered credentials.
At connection the server sends a short bootstrap telling the agent to load its full operating guide before it calls anything else. That guide is served from the release the agent is talking to.
Read the quickstart in the documentation →Three reasons teams connect their agents
For data leaders
Increase team capacity and reduce specialist dependency. Building no longer requires deep platform expertise, so the people who understand your data can extend it.
See the field story →For platform teams
Validated, governed agent operations. Every agent write passes the same validation, permissions, and confirmation gates as a human edit, with full telemetry.
Review the guardrails →For engineers
Connect Claude Code or Codex through OAuth and start building. One command, a browser sign-in, and your agent is working against a real project.
Read the quickstart →Put an agent on a governed platform today
Start a free trial and connect Claude Code to a project, or book a demo and we will walk your team through the guardrails one by one.
Direct answers about the DataForge MCP server
What is the DataForge MCP server?
The DataForge MCP server connects AI agents such as Claude Code and Codex to the DataForge platform. As of July 2026, based on public vendor documentation, DataForge is the only declarative data engineering platform whose MCP server lets an external AI agent directly build and operate the complete pipeline lifecycle: ingestion, transformation, orchestration, and delivery, as governed platform objects running natively on customer-owned Databricks or Snowflake compute, with every write passing the same save-time validation as a human edit.
Can I use the DataForge MCP server today?
Yes. The MCP server is part of the DataForge platform and runs on live customer projects.
Which AI agents and clients work with it?
Claude Code and Codex are the documented clients. The server implements OAuth 2.1 with PKCE and dynamic client registration, so any compliant MCP client can connect.
What happens when an agent makes a mistake?
Every agent write passes save-time validation: schema checks, SQL expression parsing, and role-based permissions on every call. Invalid changes never persist. The agent receives a structured error with the line and column of the problem, the exact next call to make, and when to retry, so it fixes its own mistake in seconds instead of discovering it when the pipeline runs.
Can multiple agents build in parallel?
Yes. In DataForge the unit of change is a single column: every rule writes exactly one column, validated at save time in one transactional metastore. Multiple agents build side by side in the same project with no branches to manage while building, no merge conflicts to resolve, and no integration re-testing just to combine their work.
Do AI agents get a special path into the platform?
No. Agents get no privileged path and no forgiving one. Every agent write goes through the same parse-and-save validation as a human edit: same expression parser, same schema constraints, same database-enforced permissions checked on every call, and same confirmation gates on destructive actions. There is no bypass mode and no reduced validation for AI.
How do agents know how to use the platform?
The server serves the agent's complete operating manual from the deployed release itself: an agent guide, an object taxonomy, a status-code dictionary, and a SQL conversion cookbook. The manual is versioned with every release, so the instructions an agent reads always match the exact version it is operating.
Where do agent-built pipelines run?
On your own compute. Agent-built pipelines are governed DataForge objects running natively in the customer-owned Databricks or Snowflake account, and customer data stays in the client-managed cloud.
Solution guides
Evaluate DataForge by platform goal
Enterprise data platform
Enterprise data platform for governed analytics at scale
DataForge helps CDOs, CFOs, and data platform leaders scale analytics without assembling separate ETL, orchestration, observability, lineage, and cost-control tools.
Data pipeline platform
Data pipeline platform for complex enterprise source systems
Build, extend, orchestrate, and observe enterprise data pipelines through one consistent architecture while processing data in your Databricks or Snowflake account.
Data engineering platform
Data engineering platform with architecture built in
DataForge is a data engineering platform with automatically enforced architecture, replacing separate ETL, orchestration, observability, catalog, and infrastructure tools while processing data in your cloud.
Data orchestration platform
Data orchestration platform without manually assembled DAG sprawl
DataForge orchestrates data pipelines from structured pipeline definitions, dependency metadata, scheduling, and execution history instead of manually maintained DAGs.
Data observability platform
Data observability platform with lineage, quality, audit, and cost context
DataForge observability ties code, orchestration, quality rules, alerts, lineage, audit trails, and cloud cost visibility back to the platform metadata.
Agentic data engineering
Agentic data engineering platform with save-time validation for AI agents
DataForge lets AI coding agents such as Claude Code and Codex build and operate governed data pipelines through an MCP server that validates every write at save.