Skip to main content
Glama
dynamics365ninja

D365 F&O MCP Server

by dynamics365ninja
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_symbol_index

Idempotent

Rebuild the code index for D365 F&O XML files changed outside the MCP server. Use after manual edits, Visual Studio changes, or git checkouts; omit the file path to refresh only the cache.

Instructions

Index D365FO XML file(s) changed OUTSIDE this server (hand edit, Visual Studio, git checkout). Do NOT call after d365fo_file create/modify — those refresh the index themselves, so it is a wasted round trip. Omit filePath for a bridge/cache refresh only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filePathNoAbsolute path to the changed XML file, or an ARRAY — batch them, each call costs a bridge refresh.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.9.0
    • changedInput schema / properties / filePath / description
      Previous value: -"Absolute path to the modified or created XML file (e.g. K:\\\\AosService\\\\PackagesLocalDirectory\\\\MyModel\\\\MyModel\\\\AxClass\\\\MyClass.xml), or an ARRAY — batch them, each call costs a bridge refresh."New value: +"Absolute path to the changed XML file, or an ARRAY — batch them, each call costs a bridge refresh."
  2. Changed3 schema fields changedv1.8.5
    • changedInput schema / properties / filePath / description
      Previous value: -"Absolute path to the modified or created XML file (e.g. K:\\\\AosService\\\\PackagesLocalDirectory\\\\MyModel\\\\MyModel\\\\AxClass\\\\MyClass.xml). Omit to run a lightweight bridge/workspace refresh instead of indexing a specific file."New value: +"Absolute path to the modified or created XML file (e.g. K:\\\\AosService\\\\PackagesLocalDirectory\\\\MyModel\\\\MyModel\\\\AxClass\\\\MyClass.xml), or an ARRAY — batch them, each call costs a bridge refresh."
    • addedInput schema / properties / filePath / items
      Added value: +{
+  "type": "string"
+}
    • changedInput schema / properties / filePath / type
      Previous value: -"string"New value: +[
+  "string",
+  "array"
+]
  3. First observedv1.8.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds useful behavioral context beyond those: the tool is only needed for externally changed files, internal operations already maintain the index, and omitting filePath performs a bridge/cache refresh only. This goes beyond what annotations convey, though it could be even more explicit about side effects or return behavior.

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?

Three sentences, all high-signal. The purpose is front-loaded, the critical warning is placed second, and the optional-parameter nuance is last. No wasted words or redundant restatements.

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?

The tool is simple: one optional parameter, no output schema, and annotations cover safety and idempotency. The description covers when to use it, when not to, how to batch, and how to handle the no-path case. Nothing essential is missing for correct invocation.

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 meaning beyond the schema by explaining that omitting filePath triggers a bridge/cache refresh only, not an indexing operation. This clarifies the optional parameter's special behavior, which the schema alone does not fully express.

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 verb and resource: 'Index D365FO XML file(s) changed OUTSIDE this server'. It clearly differentiates from d365fo_file create/modify, which already refresh the index, so an agent can distinguish it from the sibling tools without inspecting schemas.

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?

It explicitly states when to call this tool (files changed externally: hand edit, Visual Studio, git checkout) and when not to call it ('Do NOT call after d365fo_file create/modify'). It also gives a conditional usage instruction for omitting filePath, making the intended invocation context fully clear.

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