Operate Dynamics 365 F&O Data Management Framework (DMF) imports, exports, and metadata discovery as the signed-in Azure CLI user.
Import one or more CSV/XLSX files into a legal entity through a DMF data project; auto-create the project, follow D365 dependency order, and optionally wait or dry-run.
Export an existing DMF export project's files to a local directory.
Create empty import data projects and list/filter existing Import/Export projects.
List a project's entities with format and execution order.
Check execution status with per-entity results and errors.
Search the DMF entity catalogue and retrieve entity staging fields, types, lengths, and required flags.
Supports common CSV/Excel-based source formats; composite and XML-based entities are not supported.
Note: the schema does not expose the README's configure_project_entity tool.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@d365-dmf-mcp Import customers.csv into Customer groups for company USMF"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that imports CSV files into Dynamics 365 F&O via Data Management (DMF). It runs locally and authenticates as the user signed in to the Azure CLI.
winget install astral-sh.uv Microsoft.AzureCLISign in with the account that has access to D365 (if there is no az session, the server falls back to an interactive browser login):
az login --tenant <entra-tenant-id>Register the server with Claude Code (runs the published package via uvx; see .mcp.json.example):
claude mcp add d365-dmf `
-e DMF_AZURE_TENANT_ID=<entra-tenant-id> `
-e DMF_BASE_URL=https://<env>.sandbox.operations.eu.dynamics.com `
-- uvx d365-dmf-mcpOther MCP clients: copy the block from .mcp.json.example into the client's MCP config. To run from a local checkout instead, use uvx --from C:\path\to\d365-dmf-mcp d365-dmf-mcp.
Related MCP server: D365 Finance & Operations MCP Server
Only the tenant and environment URL are config. Everything else is passed per call.
import_data(definition_group, company, files, format="CSV"): import one or more files into a data project and wait for the result. files is a list of {entity, file_path}; entity is the DMF entity name as shown in D365 (e.g. Customer groups) and the file (.csv or .xlsx) has the entity's field names (e.g. CUSTOMERGROUPID) in its first row. The server generates the package manifest, looks up each entity's target and the dependency order from D365, and creates the data project if it doesn't exist. format is free text (CSV, EXCEL, or any CSV/Excel-based D365 source format on the environment, e.g. CSV-Unicode).
export_data(output_dir, definition_group, company): run an existing export data project and save its files.
create_data_project(name, description=""): create an empty import data project (optional; import_data does this itself).
list_data_projects(name_filter="", operation_type=""): browse existing data projects.
list_project_entities(definition_group): the entities in a project, with format, execution order and any non-default processing settings.
configure_project_entity(definition_group, entity, ...): show/change per-entity settings (business validation, field validation, business logic, skip staging, fail-on-error). Defaults are right for almost all imports; only relax validation for large, already-tested migration loads.
search_entities(query, limit=50): search the DMF entity catalogue by name, target entity or module.
get_entity_fields(entity): the column names (data file header), types, lengths and required flags for an entity.
get_execution_status(execution_id): check the status of an execution, with errors if it failed.
Import threshold record count, import task count (parallelism), set-based processing and change tracking have no API; set them in D365 (Data management > Framework parameters > Entity settings > Configure entity execution parameters) for large loads.
Composite and XML-based entities are not supported.
Optional env vars: DMF_POLL_INTERVAL_SECONDS (default 5), DMF_POLL_TIMEOUT_SECONDS (default 300).
Create an empty DMF import data project. Optional: import_data creates the project itself if it doesn't exist, and the first import defines its entities.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does disclose one meaningful trait: the project starts empty and its entities are defined by the first import. It does not state behavior when a project with the same name already exists (error vs. reuse), idempotency, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded and no padding. The second sentence's meaning is somewhat compressed, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. However, with no annotations and zero parameter coverage, the definition leaves the duplicate-name case, required-vs-optional fields, and permissions undocumented, which is thin for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters, so the description must compensate and does not. It never explains that `name` is required or what `description` does, nor does it mention defaults or naming constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb and resource: "Create an empty DMF import data project." It also distinguishes this tool from import_data by noting import_data can create projects itself, though the "DMF" acronym is left unexplained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The "Optional:" note tells the agent this call is unnecessary when a subsequent import_data would create the project implicitly, and that the first import defines its entities. There are no explicit exclusions or prerequisites, and the framing is slightly ambiguous about when creating an empty project is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an existing DMF export data project and save its data files to output_dir.
The files are saved in the project's own source format (CSV, Excel, ...). Returns the saved paths.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | ||
| output_dir | Yes | ||
| definition_group | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does disclose two useful traits: files land in the project's native source format (CSV, Excel...) and the return value is the saved paths. It omits permissions, overwrite behavior for an existing output_dir, and duration/error characteristics of a write-heavy job.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and followed by the output location and format. Nothing is padded, though a sentence on parameter meaning would be better use of the space than none.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be restated, and the description covers the action and file format. However, with three required opaque parameters, no annotations, and 0% schema coverage, the definition leaves an agent guessing at the two project-identifier arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the schema gives only bare titles. The description clarifies output_dir as the destination for saved files, but leaves company and definition_group entirely unexplained even though both are required and identify which project runs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('Run an existing DMF export data project') and states the visible effect (data files saved to output_dir). It is clear enough to contrast with import_data and create_data_project, though it never names those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'existing' implies the project must already exist, but the description never says to use list_data_projects/create_data_project first, nor when to prefer this over import_data. No when-not-to-use conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the importable columns of a DMF entity: the staging column names to use as the header row of the data file, with data type, max length and whether D365 flags the field as required. System-managed fields are omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the burden, and it does add real behavioral content beyond the schema: what each row contains (name, data type, max length, required flag) and, importantly, that system-managed fields are filtered out of the result. 'List' plus the output schema adequately signals a read-only, non-mutating call; error behavior for an invalid entity name is the notable omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resource and immediately followed by the practical detail and the omission rule. No filler and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values are covered by the existing output schema, and the description adds the key filtering behavior, so it is close to complete. However, for a one-parameter tool with zero schema description coverage and no annotations, leaving the entity identifier format unspecified is a real gap an agent must guess around.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required 'entity' parameter, so the description must compensate and largely does not. It implies an entity is needed but never says what form the identifier takes (logical name, GUID, or a value from search_entities), which is the one thing an agent could get wrong here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('List') plus a precisely scoped resource ('importable columns of a DMF entity') with an explicit semantic gloss: the staging column names used as the header row of the data file. It also states the scope boundary ('System-managed fields are omitted'), which makes it unmistakable versus siblings like search_entities or list_project_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'the staging column names to use as the header row of the data file' clearly places the tool in the pre-import workflow, so an agent knows to call it before import_data. It stops short of explicitly naming import_data or stating exclusions, so it is strong context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of a DMF execution (NotRun, Executing, Succeeded, PartiallySucceeded, Failed, Canceled), with per-entity status and error messages if it failed.
| Name | Required | Description | Default |
|---|---|---|---|
| execution_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden; it does disclose the return surface (overall status enum, per-entity status, error messages on failure), which a 'Get' verb alone would not convey. However, it says nothing about whether it requires permissions, whether results are immediate or eventually consistent, or whether polling is expected — meaningful gaps for a status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the verb-object first and the status enumeration and failure detail as a trailing qualifier; every clause adds information. The parenthetical status list is slightly long but useful and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be documented in prose, and the description still previews the key response signals (status values, per-entity status, errors). What's missing is the operational context — preconditions and whether polling is required — for a one-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it says nothing about execution_id — where it comes from, its format, or whether it must be a value previously returned by another call. The single parameter is self-describing by name, which keeps this from being worse than 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Get') and resource ('status of a DMF execution') and enumerates the possible status values, so the agent knows exactly what is returned. It loses a point only because 'DMF' is an undefined acronym and there is no explicit differentiation from the sibling tools (though none of them overlap).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to call this tool, when not to, or what the prerequisite is (e.g., that an execution must have been started elsewhere and an execution_id obtained). The name and sibling list imply a post-import status-polling role, but that is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import one or more data files into D365 through a DMF data project, as the signed-in user.
definition_group is the data project name (created automatically if it doesn't exist),
company the legal entity id (e.g. USMF). files lists {entity, file_path} pairs: entity
is the DMF entity name as shown in D365 (e.g. "Customer groups"; find it with search_entities),
file_path a .csv or .xlsx
whose first row holds the entity's field names (staging column names, e.g. CUSTOMERGROUPID;
list them with get_entity_fields).
Several entities can be imported in one call; D365 decides the order from their dependencies.
format is the file format in the package, free text and case-insensitive: "CSV" (default) and
"EXCEL" are the common ones; other CSV/Excel-based source formats on the environment
(e.g. "CSV-Unicode") also work. An unknown value returns the available ones.
Composite and XML-based entities are not supported.
With wait=True, polls until the import finishes (or the timeout); otherwise returns the
execution id to check with get_execution_status. dry_run only validates and builds the package.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | ||
| files | Yes | ||
| format | No | CSV | |
| company | Yes | ||
| dry_run | No | ||
| definition_group | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does well: it discloses that the data project is created automatically if absent, that D365 determines import order from dependencies, that an unknown format value returns the available ones, and that dry_run only validates and builds the package. It stops short of failure semantics (partial-import behavior, rollback, idempotency on re-run), which matters for a bulk write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then parameter-by-parameter, then the wait/dry_run execution modes — a logical order with no filler sentences. The format paragraph is somewhat long-winded for a single optional string parameter, but every clause still conveys usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter bulk-write tool with no annotations, the description covers prerequisites, file shape, entity lookup, supported formats, unsupported entity types, and both sync and async execution paths. Return values need not be explained since an output schema exists, and the description still points at the execution-id follow-up correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate and does: definition_group, company (with a USMF example), files (both entity and file_path, including that the first row holds staging column names and must be .csv/.xlsx), format (free text, case-insensitive, CSV default, EXCEL, CSV-Unicode), wait, and dry_run are all explained. This is meaningfully richer than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: importing data files into D365 via a DMF data project. It is immediately distinguishable from siblings like export_data and create_data_project, and it names the mechanism (data project) that would otherwise be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly covers when to use wait=True (poll to completion) vs. the async path (returns an execution id to check with get_execution_status), and what dry_run does. It also routes the agent to search_entities and get_entity_fields for the lookups needed before calling, and states the exclusion that composite and XML-based entities are not supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List existing DMF data projects (name, Import/Export, description).
name_filter is a case-insensitive substring of the name or description; operation_type
optionally restricts to "Import" or "Export". Use the names with import_data / export_data.
| Name | Required | Description | Default |
|---|---|---|---|
| name_filter | No | ||
| operation_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; it does convey that this is a read-only listing and explains the filter matching rules (case-insensitive substring over name or description). It omits ordering, result limits/pagination, and what happens with no matches, which matter for an unpaginated-looking list call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short blocks, front-loaded with the purpose followed by filter semantics, with zero filler. Every clause either identifies the resource or constrains a parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-shape detail is unnecessary, and the tool has only two optional params that are well covered. The main residual gap is list behavior at scale (ordering, caps, empty results), which is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description has to compensate, and it largely does: it defines name_filter's matching semantics (case-insensitive substring across name or description) and pins operation_type to "Import" or "Export". It does not say whether operation_type is case-sensitive or what an empty default yields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List existing DMF data projects") and enumerates what each entry contains (name, Import/Export, description). That is enough for an agent to distinguish it from siblings such as create_data_project or list_project_entities without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use the names with import_data / export_data" gives an explicit downstream workflow that positions this as a prerequisite discovery call. It does not name a when-not case or an alternative listing tool, which keeps it out of 5 territory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the entities defined in a DMF data project, with source format and execution order (unit/level/sequence).
| Name | Required | Description | Default |
|---|---|---|---|
| definition_group | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. "List" implies a read-only, non-destructive operation and the description usefully notes the ordering/format fields returned, but it says nothing about prerequisites (does the project need to exist / be accessible), pagination, or behavior on an empty or unknown group.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, with the returned detail parenthesized rather than sprawling. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, and the description does gesture at the ordering fields. However, with zero schema coverage on the one required parameter and no sibling differentiation, the definition is not complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the sole required parameter, definition_group, is never explained in the description. The agent must supply a required argument whose meaning, format, and source of valid values are entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List the entities defined in a DMF data project") and adds what is returned (source format, execution order unit/level/sequence). It does not distinguish itself from the sibling search_entities, so an agent cannot tell purely from the description which one to reach for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives, even though search_entities and list_data_projects are obvious overlapping siblings. The only usage signal is the implied scoping to a single project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the DMF entity catalogue by case-insensitive substring of the entity name, target entity or module (e.g. "customer", "AccountsReceivable"). Returns entity names to use with import_data, plus category and module. Composite entities (X composite) are not importable here.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden: it discloses matching semantics (case-insensitive substring across three fields), what the response contains (name, category, module), and the composite-entity exclusion. It says nothing about result caps or how the limit parameter affects output, and does not explicitly confirm the operation is read-only, leaving meaningful gaps for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the matching behaviour and immediately followed by the downstream consumer and the key exclusion. The examples ('customer', 'AccountsReceivable') clarify the query format without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained in depth, and the description still summarizes them. The one real omission is limit behaviour/pagination, which matters for an agent deciding how many results it will get.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does this well for query, spelling out the substring matching fields and giving example terms, but the limit parameter is never mentioned, leaving one of two parameters entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (DMF entity catalogue) plus exactly which fields are matched (entity name, target entity, module) and how (case-insensitive substring). This clearly separates it from siblings like get_entity_fields and list_project_entities, which are about fields and project scope rather than catalogue lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the result as input for import_data and warns that composite entities ('X composite') are not importable here, which is real when-to-use guidance. It does not name an alternative tool for cases where the entity already lives in a project (e.g. list_project_entities), so the routing is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0create_data_projectexport_dataget_entity_fieldsget_execution_statusimport_datalist_data_projectslist_project_entitiessearch_entitiesScored across 8 tools
Each tool targets a distinct DMF operation: entity catalogue search, field metadata, import, export, project listing/creation, project entity listing, and execution status. The only redundancy is that import_data can auto-create a data project, but create_data_project remains clearly scoped as an optional explicit step.
All tool names follow a consistent verb_noun snake_case convention (get_execution_status, search_entities, import_data, etc.). There are no mixed styles or vague names.
Eight tools are well-scoped for a DMF import/export server. Each tool has a clear role, and the surface is neither too thin nor bloated.
The core import workflow is complete end-to-end: search entities, inspect fields, import data, and check execution status. Minor gaps remain: no tool to create/configure export projects, cancel running executions, or delete/update data projects, though some can be worked around via existing projects or wait/timeout behavior.
Create, deploy and inspect Eurobase projects and Functions in the European cloud.
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
Public tools to understand Dynamik, discover datasets, and connect account-scoped capabilities.
