Skip to main content
Glama
dynamics365ninja

D365 F&O MCP Server

by dynamics365ninja
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_knowledge

Read-only

Query X++ rulebook and best practices, diagnose D365FO errors with root cause and fix, get operation specs, and validate BP monikers before writing code.

Instructions

X++ knowledge lookup. Choose a kind: • knowledge → queryable X++ rulebook: verified patterns, BP rules, AX2012→D365FO migration. Use BEFORE generating code. Topics incl.: select-statement, coc-authoring, bp-rules, sysoperation, event-handlers, workflow, number-sequences, security, sysda, form patterns. • error → diagnose a D365FO/X++ compiler or runtime error: structured root cause + step-by-step fix + corrected X++ example (TTS mismatch, UpdateConflict, CSUV1, SYS10028 missing next, overlayering, BP errors, …). Call this instead of guessing — X++ error semantics differ from C#/.NET. • op-spec → the parameter contract for ONE d365fo_file operation/objectType or ONE generate_object mode (topic = "add-index", "table", "scaffold:form", …). Those two tools deliberately do not ship their parameters inline; call this after picking the operation, before the call. Omit topic for the index of available topics. • bp-moniker → validate an exact BP-check moniker, search by scenario when you have no moniker yet, or render a _BPSuppressions.xml block. Backed by names/text extracted from a real D365FO install — never invents a moniker.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo
pathNo[bp-moniker suppress] REQUIRED. dynamics:// path, verbatim from the finding.
topicNo[knowledge] REQUIRED. Topic to query — e.g. "ttsbegin", "RunBase vs SysOperation". [op-spec] The operation / objectType / mode to look up.
actionNo[bp-moniker] REQUIRED. validate = confirm an exact moniker is real; search = free-text scenario query; suppress = render a <Diagnostic> block.
formatNo[knowledge] concise = quick reference (default), detailed = full explanation with code examplesconcise
topicsNo[knowledge|op-spec] Look up SEVERAL topics in one call instead of one call each. Replaces topic.
monikerNo[bp-moniker validate/suppress] REQUIRED. Exact moniker, e.g. "BPErrorPrivilegeNotCoveredByDuty".
errorCodeNo[error] Optional error code (e.g. SYS10028, CSUV1, BPUpgradeCodeToday)
errorTextNo[error] REQUIRED. Full error message text as displayed in the X++ compiler or event log
justificationNo[bp-moniker suppress] REQUIRED. Why the warning is ignored; 95% of real entries carry one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.16.2
    • removedInput schema / properties / kind / description
      Removed value: -"knowledge = look up an X++ topic/rule; error = diagnose an error message; op-spec = parameter contract for a d365fo_file operation/objectType or generate_object mode; bp-moniker = validate/search a BP-check moniker or render a suppression."
    • changedInput schema / properties / topic / description
      Previous value: -"[knowledge] REQUIRED. Topic to query — e.g. \"batch job\", \"ttsbegin\", \"RunBase vs SysOperation\", \"set-based operations\", \"CoC\", \"data entities\", \"number sequences\", \"security\", \"temp tables\", \"today() deprecated\", \"query patterns\", \"form patterns\". [op-spec] The operation / objectType / mode to look up."New value: +"[knowledge] REQUIRED. Topic to query — e.g. \"ttsbegin\", \"RunBase vs SysOperation\". [op-spec] The operation / objectType / mode to look up."
  2. Changed1 schema field changedv1.14.0
    • addedInput schema / properties / topics
      Added value: +{
+  "description": "[knowledge|op-spec] Look up SEVERAL topics in one call instead of one call each. Replaces topic.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}
  3. Changed6 schema fields changedv1.12.0
    • addedInput schema / properties / action
      Added value: +{
+  "description": "[bp-moniker] REQUIRED. validate = confirm an exact moniker is real; search = free-text scenario query; suppress = render a <Diagnostic> block.",
+  "enum": [
+    "validate",
+    "search",
+    "suppress"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / justification
      Added value: +{
+  "description": "[bp-moniker suppress] REQUIRED. Why the warning is ignored; 95% of real entries carry one.",
+  "type": "string"
+}
    • changedInput schema / properties / kind / description
      Previous value: -"knowledge = look up an X++ topic/rule; error = diagnose an error message; op-spec = parameter contract for a d365fo_file operation/objectType or generate_object mode."New value: +"knowledge = look up an X++ topic/rule; error = diagnose an error message; op-spec = parameter contract for a d365fo_file operation/objectType or generate_object mode; bp-moniker = validate/search a BP-check moniker or render a suppression."
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "knowledge",
-  "error",
-  "op-spec"
-]New value: +[
+  "knowledge",
+  "error",
+  "op-spec",
+  "bp-moniker"
+]
    • addedInput schema / properties / moniker
      Added value: +{
+  "description": "[bp-moniker validate/suppress] REQUIRED. Exact moniker, e.g. \"BPErrorPrivilegeNotCoveredByDuty\".",
+  "type": "string"
+}
    • addedInput schema / properties / path
      Added value: +{
+  "description": "[bp-moniker suppress] REQUIRED. dynamics:// path, verbatim from the finding.",
+  "type": "string"
+}
  4. Changed3 schema fields changedv1.9.0
    • changedInput schema / properties / kind / description
      Previous value: -"knowledge = look up an X++ topic/rule; error = diagnose an error message."New value: +"knowledge = look up an X++ topic/rule; error = diagnose an error message; op-spec = parameter contract for a d365fo_file operation/objectType or generate_object mode."
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "knowledge",
-  "error"
-]New value: +[
+  "knowledge",
+  "error",
+  "op-spec"
+]
    • changedInput schema / properties / topic / description
      Previous value: -"[knowledge] REQUIRED. Topic to query — e.g. \"batch job\", \"ttsbegin\", \"RunBase vs SysOperation\", \"set-based operations\", \"CoC\", \"data entities\", \"number sequences\", \"security\", \"temp tables\", \"today() deprecated\", \"query patterns\", \"form patterns\""New value: +"[knowledge] REQUIRED. Topic to query — e.g. \"batch job\", \"ttsbegin\", \"RunBase vs SysOperation\", \"set-based operations\", \"CoC\", \"data entities\", \"number sequences\", \"security\", \"temp tables\", \"today() deprecated\", \"query patterns\", \"form patterns\". [op-spec] The operation / objectType / mode to look up."
  5. First observedv1.8.0

TDQS

A4.9/5.0
Behavior5/5

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

The annotations cover read-only safety, and the description adds behavioral guarantees beyond that: knowledge is a 'queryable rulebook', error mode promises 'structured root cause + step-by-step fix + corrected X++ example', and bp-moniker is 'backed by names/text extracted from a real D365FO install — never invents a moniker'. No contradiction with readOnlyHint or openWorldHint.

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 bulleted and front-loaded with the core instruction ('Choose a kind'), then each mode gets a compact, purposeful sentence with no filler. The length is justified by the four distinct behaviors and the need to route callers correctly.

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

Completeness5/5

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

For a 10-parameter tool with no output schema, the description covers the input space thoroughly: all four kind values, their intended use, the output shape for error mode, the index behavior for op-spec, and the rendered Diagnostic block for bp-moniker. The remaining details are already captured by the high-coverage input schema.

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 already high (90%) and each parameter has a mode-tagged description, so the baseline is 3. The description earns an extra point by explaining why op-spec exists, by defining what each kind means for parameter selection, and by adding the 'omit topic for index' rule that clarifies an otherwise underspecified optional parameter.

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 states a specific action ('knowledge lookup') plus four clearly delineated resource kinds, each with its own purpose: rulebook, error diagnostics, op-spec contract, and bp-moniker validation. It explicitly references the sibling tools d365fo_file and generate_object, making it easy for an agent to distinguish this from nearby operations.

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

Usage Guidelines5/5

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

Each bullet gives an explicit when-to-use rule: knowledge before generating code, error instead of guessing, op-spec after picking the operation and before the call, bp-moniker for validate/search/suppress. It even explains that d365fo_file and generate_object deliberately omit inline parameters, making this lookup a required prerequisite rather than an optional convenience.

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