AI agents & MCP
Let your AI assistant work with your business data, on your terms
Claude and other MCP-capable agents connect to your Data Lake with a revocable key, answer questions from all your systems and — if you allow it — operate the platform itself, under the same permissions and audit trail as any other client.
# the agent asks the data plane
read_records entity=account $filter=Region eq 'West'
aggregate entity=orders sum(Total) by Month
# with an admin key, it can operate the platform too
create_table set_entity_exposure restart_dab
# and the same tools from your own shell
$ dlake tool aggregate --entity orders --profile acme
What is MCP, and why does it matter here?
In plain wordsMCP is a standard plug that lets an AI assistant use tools and data. The Data Lake offers that plug, so an agent can work with your data without anyone building a custom integration.
The CLI is a complete peer of the MCP connector — every tool is callable as dlake tool <name> or dlake admin <name>, which is why the same skills serve both. One key decides which of the two planes a caller reaches, and the rules underneath both are enforced in SQL Server rather than by whichever client is asking.
Data plane
Work with rows
Read, write, query, aggregate, export and look at history — for the entities you have exposed, and no others.
dlake tool list shows what your key allows.
Admin control plane
Operate the platform
Define schema, expose entities, mint keys, restart the Data API, manage security and events, drive the sync products.
dlake admin list — admin keys only.
How agents connect and what keeps them safe
Connect with a key, not a login
You mint a key for the agent, hand it to the MCP client, and switch it off whenever you want. The key rides in the request header and carries its own identity into the database, so the audit trail records the agent, not a person.
Admin Control Plane (MCP)Scope down to tables, fields and rows
Scoped keys are enforced server-side and fail closed, down to entity and field level. Row-level security adds per-row rules inside SQL Server that apply whoever is asking.
Row-Level SecurityTeach the agent the happy path
20 skills ship inside the CLI: the right command order, the sharp edges, and the HTTP contract for the Data API, so the agent does not learn by trial and error on your data.
The 20 skills belowStored procedures as agent tools
Wrap a business action in a stored procedure and publish it, and the agent gets one named tool that either commits everything or changes nothing.
Stored Procedures as MCP ToolsThe 20 bundled agent skills
In plain wordsEach skill is a playbook for one job. Install them all with one command; your agent picks the right one from its description.
dlake skills installdlake skills show dlakeSkills ship inside the CLI and update with it, so dlake skills install after every upgrade refreshes the copies on disk (add --skip-existing to keep local edits). Catalogue last changed 19 Sept 2026. Browse the skills folder on GitHub ↗
Build and operate a tenant2 skills
In plain wordsStart here: the everyday skill for an existing Data Lake, and the one that stands up a brand-new integration.
| Skill | What it covers | ERP pages |
|---|---|---|
dlake-integration-setup | Stand up a NEW integration: register a tenant, seed it, then drive the setup wizard — server IP, CRM (connect now or later, OAuth included), and the ERP connector that declares Syspro/QuickBooks/SQL Server/ODBC. Covers the wizard's ordering and guards, credential lifetimes, and how to resume days later. | — |
dlake | Build and operate a tenant end-to-end: schema → expose → restart → scoped key, the sharp edges (the scoped-key restart, exposed-vs-raw entities, IDENTITY-key limits), and the REST/GraphQL + events contract — all in one `SKILL.md`. | — |
Bring data in (sync products)3 skills
In plain wordsWhich ERP tables are cloned, and the agents for sources that are not SQL Server or that are APIs.
| Skill | What it covers | ERP pages |
|---|---|---|
dlake-apisync | Set up **Generic API Sync** — the product for a source that is an API rather than a database. Enable it (schema provision + flag), describe the endpoints the agent calls (the two-mode save trap), read the shared per-ERP template catalogue, and read a hosted customer's real ERP columns. | — |
dlake-normalsync | Choose which ERP tables **Normal Sync** — the on-prem change-tracking agent for SQL Server 2008 R2+ — clones into the gateway database's `dbo` clone tables. The available-tables dropdown, the two-call add, per-table sync toggles and row filters, the shared-catalogue semantics, and the prerequisites this surface cannot set (so finishing it does not mean the customer syncs). Plus **resync** — queue a full or per-table re-pull for the agent's next run — and **clone coverage**, rows actually in each clone against the count recorded at last sync (a green sync run is not evidence rows moved). | — |
dlake-odbcsync | Configure **ODBC Sync** — the agent for a source that is NOT Microsoft SQL Server, which stages data through an S3 bucket into an intermediary database Normal Sync then consumes. The bucket registry, the IAM IP allow-list, the agent's `BridgeClient.exe.config` (and the encrypted-echo trap), and the two verification reads. | — |
Push data to a CRM (CRMPro)8 skills
In plain wordsThe forward sync from your ERP into HubSpot, Salesforce, Shopify, Zoho, Dynamics, MDC or Magento, with one page per source ERP.
| Skill | What it covers | ERP pages |
|---|---|---|
dlake-crmpro-dynamicscrm | The **Dynamics CRM** specifics for a CRMPro forward sync, read from the shipped templates: the objects, the repository key, the view and `TimeStamp_Prefix` conventions, and what to check when a run pushes nothing. Extends `dlake-crmpro/`; carries one `erps/` child page per source ERP. | 19 |
dlake-crmpro-hubspot | The **HubSpot** specifics for a CRMPro forward sync: the configuration values the HubSpot engine dispatches on, the DLO view contract for it — the three view kinds and the `SavedTimeStamp` cursor rule that decides which rows a view returns — the seed/upsert pair for CRM-owned versus ERP-owned fields, the `CRM_FieldList` rows an object needs before it pushes anything, and what to check when a run completes without pushing any records. Extends `dlake-crmpro/`. | 89 |
dlake-crmpro-magento | The **Magento** specifics for a CRMPro forward sync, read from the shipped templates: the objects, the repository key, the view and `TimeStamp_Prefix` conventions, and what to check when a run pushes nothing. Extends `dlake-crmpro/`; carries one `erps/` child page per source ERP. | 7 |
dlake-crmpro-mdc | The **MDC** specifics for a CRMPro forward sync, read from the shipped templates: the objects, the repository key, the view and `TimeStamp_Prefix` conventions, and what to check when a run pushes nothing. Extends `dlake-crmpro/`; carries one `erps/` child page per source ERP. | 11 |
dlake-crmpro-salesforce | The **Salesforce** specifics for a CRMPro forward sync: the configuration values the Salesforce engine dispatches on — standard objects alongside the managed package's custom objects, the namespace prefix/postfix pair, and an external-id field as the match key — the view contract the shipped templates use (a single-colon repository key, the identity column named as the external id, no `SFDCID` output column), the id-chaining ladder that makes `Sync_Order` a dependency order, the reverse-lookup and create/update process pairs, and what to check when a run completes without pushing any records. Extends `dlake-crmpro/`; carries one `erps/` child page per source ERP. | 105 |
dlake-crmpro-shopify | The **Shopify** specifics for a CRMPro forward sync: the upper-case object tokens, the display name that reads as an operation, the insert-only create legs and their `::` repository key, and the two update legs — which are not cursor-driven at all but compare the ERP value against a mirrored Shopify value and push only the difference. Covers why a created product never updates, and what an empty mirror table does to a run. Extends `dlake-crmpro/`; carries one `erps/` child page per source ERP. | 24 |
dlake-crmpro-zohocrm | The **Zoho CRM** specifics for a CRMPro forward sync, read from the shipped templates: the objects those templates push to, the repository key they build, the view and `TimeStamp_Prefix` conventions, and which template groups every source ships versus only some. Extends `dlake-crmpro/`; carries one `erps/` child page per source ERP. | 27 |
dlake-crmpro | Set up **and operate CRMPro** — the source→CRM (forward) sync agent that pushes ERP data into the supported CRM and e-commerce platforms. Flag-driven: CRUD the configuration and run-history/error tables, read and edit the field mapping, and know which of its tables are reachable as lake views and which deliberately are not. | — |
Write changes back (TxDownloaderPro)6 skills
In plain wordsThe return leg: changes made in the CRM travel back to the source system.
| Skill | What it covers | ERP pages |
|---|---|---|
dlake-txdownloaderpro-dynamicscrm | The **Dynamics CRM** specifics for a TxDownloaderPro writeback, from the shipped default templates: the query shape that finds flagged records and the marker columns it reads, the structure of the inbound mapping document and the `$FUN_` token names it carries, which `ResultStructure` parts the templates fill for the write back to Dynamics CRM, and the process row each template becomes on import. Extends `dlake-txdownloaderpro/`. | 18 |
dlake-txdownloaderpro-hubspot | The **HubSpot** specifics for a TxDownloaderPro writeback, from the shipped default templates: the query shape that finds flagged records and the marker columns it reads, the structure of the inbound mapping document and the `$FUN_` token names it carries, which `ResultStructure` parts the templates fill for the write back to HubSpot, and the process row each template becomes on import. Extends `dlake-txdownloaderpro/`. | 67 |
dlake-txdownloaderpro-salesforce | The **Salesforce** specifics for a TxDownloaderPro writeback, from the shipped default templates: the query shape that finds flagged records and the marker columns it reads, the structure of the inbound mapping document and the `$FUN_` token names it carries, which `ResultStructure` parts the templates fill for the write back to Salesforce, and the process row each template becomes on import. Extends `dlake-txdownloaderpro/`. | 69 |
dlake-txdownloaderpro-shopify | The **Shopify** specifics for a TxDownloaderPro writeback, from the shipped default templates: the query shape that finds flagged records and the marker columns it reads, the structure of the inbound mapping document and the `$FUN_` token names it carries, which `ResultStructure` parts the templates fill for the write back to Shopify, and the process row each template becomes on import. Extends `dlake-txdownloaderpro/`. | 22 |
dlake-txdownloaderpro-zohocrm | The **Zoho CRM** specifics for a TxDownloaderPro writeback, from the shipped default templates: the query shape that finds flagged records and the marker columns it reads, the structure of the inbound mapping document and the `$FUN_` token names it carries, which `ResultStructure` parts the templates fill for the write back to Zoho CRM, and the process row each template becomes on import. Extends `dlake-txdownloaderpro/`. | 30 |
dlake-txdownloaderpro | Set up **and operate TxDownloaderPro** — the CRM→source (writeback) sync agent. Expose its gateway objects to the Data API and scope a key to them, then CRUD the configuration and in-flight transaction rows, edit the field mapping in their JSON/XML columns, and use the filter-operator vocabulary that decides which retrieved CRM records reach the source. Covers exposure-vs-key-scope, `keyFields`, and the `SFUpdated` state machine. | — |
On the customer's own server1 skill
In plain wordsThe Windows agent that actually reads the source ERP; the other half of every setup.
| Skill | What it covers | ERP pages |
|---|---|---|
dlake-syncagent | Install and configure the **Commercient Sync Agent** — the on-premises Windows agent on the customer's own ERP server — with `CommercientSyncAgentCLI.exe`, the scriptable peer of the desktop app. The install/configure/test sequence, the per-product configuration fields, the exit codes to branch on, what it writes to the registry and Task Scheduler, and how it self-updates. The ON-PREMISES half of a setup; the other skills cover the platform half. | — |
Where skills are installed4 harnesses
| Harness | Skills directory |
|---|---|
| Claude Code / Cowork | .claude/skills/<skill>/ (per project) or ~/.claude/skills/<skill>/ (global) |
| OpenAI Codex | ~/.codex/skills/<skill>/ or your project's skills directory |
| OpenCode | .opencode/skill/<skill>/ |
| Other harnesses | wherever the harness discovers skills; keep the <skill>/SKILL.md layout intact |
dlake skills install auto-detects these locations. Confirm the exact path against your harness's own documentation.
Questions about AI agents
What is MCP?
MCP (Model Context Protocol) is an open standard that lets an AI assistant such as Claude connect to external tools and data. Commercient Data Lake exposes MCP connectors, so an agent can query your data and, with the right key, operate the platform, using the same permissions and audit trail as any other client.
What can an AI agent actually do with my data lake?
On the data plane it can read and write records, run read-only SQL queries, aggregate, export, ingest files and look at time-travel history for the entities you have exposed. On the admin control plane it can define schema, expose entities, manage keys and drive the sync products. Run dlake tool list and dlake admin list to see exactly which tools your key can use.
What are agent skills?
Skills are small Markdown playbooks that teach a coding agent how to drive dlake correctly: the right command ordering, the non-obvious gotchas and the HTTP contract for the Data API. They ship inside the CLI. dlake skills install writes them where your agent harness looks (Claude Code, Codex, OpenCode and others), and dlake skills show <name> prints one.
Can an agent sign up for a Data Lake on my behalf?
Signing up is deliberately a human step. dlake register start takes a password and three affirmation flags (that you have backed up your CRM and ERP data, and that you consent to phone contact). The CLI help states that agents must ask the human and never pass these on their own initiative. Once the Data Lake is seeded, the rest of the setup wizard can be driven over MCP.
How do I limit what an agent can see?
Mint a scoped API key with dlake admin create_api_key and a scope file listing the entities and actions it may use, then run dlake admin restart_dab --confirm true. Row-level security adds per-row rules on top, and revoking a key takes effect immediately.
