Skip to main content
Glama
dynamics365ninja

D365 F&O MCP Server

by dynamics365ninja
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

object_patterns

Read-only

Get pattern guidance for D365 F&O objects: analyze form patterns, validate AxForm XML, and retrieve structure specs for tables, reports, and mobile apps.

Instructions

Pattern toolkit. Choose a domain: • table → field/index/relation patterns for D365FO tables. Filter by tableGroup or similarTo a given table. • form → form-pattern toolkit; pick an action:

  • analyze → pattern advisor + usage analysis. For a NEW form pass recommend (preferred): the Microsoft decision tree picks the pattern and names reference forms to clone. Or filter by formPattern / dataSource / similarTo.

  • spec → structure spec of a pattern/sub-pattern: hierarchy, ordering, allowed children, reference forms, lifecycle.

  • validate → AxForm XML validator (hierarchy/order, sub-patterns, PatternVersion) → FP001-FP010. Call before d365fo_file action=create. • report → SSRS implementation recipes: object roster, scaffold call, checks. Optional pattern=. • mobile-app → warehouse-app screen recipes, led by the choice between the two frameworks that build them (ProcessGuide vs WHSWorkExecuteDisplay): create a flow, add or replace one screen, step icon/title, GS1 scan input. Optional pattern=.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xmlNo[validate] Complete AxForm XML to validate. Provide this OR formName/filePath.
limitNo[analyze] Max pattern examples.
actionNo[form] Which form-pattern operation to run. repair = auto-fill missing required controls.
domainNoOptional — inferred from the other params (action/pattern/xml/formName → form; tableGroup → table). A concept like "number-sequence" is not a domain: that is get_knowledge.
patternNo[spec|report|mobile-app] Pattern name (id, xmlName or alias) — e.g. "SimpleList", "FieldsFieldGroups", "PrintMgmtFormLetter", "processguide-flow".
filePathNo[form/validate] Path to an AxForm XML file not yet indexed.
formNameNo[validate] Name of an indexed form — XML is loaded from the metadata store.
recommendNo[analyze] Pattern advisor: describe requirements, get a recommended pattern + reference forms to clone.
similarToNo[table] table / [form-analyze] form name to find similar patterns.
dataSourceNo[form/analyze] Table name - find forms using this table
tableGroupNo[table] Table group type to analyze (choose one).
formPatternNo[analyze] D365FO form pattern to analyze

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.16.2
    • changedInput schema / properties / domain / description
      Previous value: -"table = table field/index/relation patterns; form = form-pattern toolkit (set action). Optional — inferred from the other params (action/pattern/xml/formName → form; tableGroup → table). ⚠️ This is NOT a free-form \"pattern type\": a concept like \"number-sequence\"/\"SysOperation\" belongs to get_knowledge, not here."New value: +"Optional — inferred from the other params (action/pattern/xml/formName → form; tableGroup → table). A concept like \"number-sequence\" is not a domain: that is get_knowledge."
    • changedInput schema / properties / domain / enum
      Previous value: -[
-  "table",
-  "form"
-]New value: +[
+  "table",
+  "form",
+  "report",
+  "mobile-app"
+]
    • changedInput schema / properties / filePath / description
      Previous value: -"[form/validate] Explicit path to an AxForm XML file (e.g. a freshly created form not yet indexed)."New value: +"[form/validate] Path to an AxForm XML file not yet indexed."
    • changedInput schema / properties / limit / description
      Previous value: -"[analyze] Maximum number of pattern examples (default: 10)"New value: +"[analyze] Max pattern examples."
    • changedInput schema / properties / pattern / description
      Previous value: -"[spec] REQUIRED. Pattern name (id, xmlName, or alias) — e.g. \"SimpleList\", \"DetailsMaster\", or a sub-pattern like \"FieldsFieldGroups\"."New value: +"[spec|report|mobile-app] Pattern name (id, xmlName or alias) — e.g. \"SimpleList\", \"FieldsFieldGroups\", \"PrintMgmtFormLetter\", \"processguide-flow\"."
    • changedInput schema / properties / similarTo / description
      Previous value: -"[table] table name to find similar table patterns; [form/analyze] form name to find similar form patterns."New value: +"[table] table / [form-analyze] form name to find similar patterns."
  2. Changed3 schema fields changedv1.14.0
    • changedInput schema / properties / recommend / properties / entityKind / description
      Previous value: -"Kind of entity: master (customers), transaction (orders+lines), setup (group tables), parameters, inquiry (read-only), lookup, workspace, dialogTask"New value: +"Kind of entity being modelled."
    • changedInput schema / properties / recommend / properties / fieldCount / description
      Previous value: -"Approximate fields users see/edit per record (<10 → SimpleList, ≥10 → SimpleListDetails)"New value: +"Approximate fields users see/edit per record."
    • changedInput schema / properties / recommend / properties / tableName / description
      Previous value: -"Main table — pulls field count and existing-form evidence from the index"New value: +"Main table — pulls field count and existing-form evidence from the index."
  3. First observedv1.8.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already covers the non-destructive nature. The description adds useful behavioral context: validation returns FP001-FP010 checks, analyze uses the Microsoft decision tree and names reference forms, and validate is meant to precede d365fo_file creation. It would be stronger if it explained the repair action's in-memory behavior explicitly, but there is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured with domain bullets and action sub-bullets. It front-loads the domain decision and avoids repeating parameter-level detail already in the schema. For a 12-parameter, multi-domain tool, this is appropriately sized and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Considering the complexity and the read-only annotation, the description is nearly complete: it covers all major domains, the main actions, output-like evidence (reference forms, FP codes), and a cross-tool dependency. The one clear gap is the undocumented 'repair' action, which prevents a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by showing how parameters combine by domain and action, e.g. recommend for new forms, tableGroup/similarTo for table patterns, and pattern=<id> for report/mobile-app. It does not discuss repair or limit, but the schema documents those clearly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a detailed pattern toolkit manual: each domain (table, form, report, mobile-app) is tied to concrete operations such as analyze, spec, validate, and recipe generation. It clearly scopes the tool to D365FO pattern concerns and even names the related d365fo_file create action for the validation flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives strong usage guidance inside the tool: 'For a NEW form pass recommend (preferred)', 'Call before d365fo_file action=create', and it explains when to filter by formPattern/dataSource/similarTo. However, the schema's action enum also lists 'repair' yet the description completely omits that action, so guidance for one alternative is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools