ALM X++ MCP Server

WHEN: generating a visual diagram of D365 table relationships or security chains. Triggers: 'generate diagram', 'diagramme', 'visualize', 'schéma', 'ER diagram', 'entity-relationship', 'relation diagram', 'security diagram', 'show connections'. Generate visual Mermaid diagrams from D365 F&O knowledge base data. Diagrams render directly in Copilot Chat, Cursor, Claude, and markdown viewers. Types: 'er' (entity-relationship diagram for a table and its relations), 'security' (security chain: Role->Duty->Privilege->EntryPoints -- use when you need a VISUAL Mermaid diagram; for the structured text chain with tables of duties/privileges/entry-points use `trace_security_chain` instead). Note: 'flow' (execution flowchart) is disabled -- static call trees are misleading in D365 due to CoC and event handlers.

WHEN: user asks to write or generate a Functional Design Document, FDD, functional spec, CdC, or cahier des charges. NOT for developer technical docs -- use `get_object_details` for that. FUNCTIONAL DESIGN DOCUMENT GENERATOR -- Produces a structured FDD ready for review and sign-off. Sections generated: Purpose, Business Context, Data Fields (with resolved labels), Business Rules, Related Objects, Security, and Open Questions. Triggers: 'write FDD for', 'generate FDD', 'functional spec for', 'document this process', 'write functional design', 'rédiger le cahier des charges', 'CdC pour', 'fiche de conception'.

WHEN: developer needs correct X++ select or T-SQL for D365 tables with proper joins. Triggers: 'X++ select', 'generate a query', 'SQL for', 'join with', 'how to query', 'générer une requête', 'write a select statement', 'select from', 'X++ query for', 'requête X++', 'écrire une select'. Generate both X++ select statements and equivalent T-SQL queries for D365 F&O tables. Uses real field names, relations, and indexes from the knowledge base to produce correct joins. Supports: field selection, multi-table joins (auto-detects relations), WHERE filters, ORDER BY, TOP/firstonly, cross-company. Also accepts natural language descriptions like 'find all open sales orders for customer 1001 with CustTable join'. [!] For multi-table joins, call find_related_objects (or get_relation_graph if the relation index is loaded) FIRST to get the correct FK relations -- this tool will then produce accurate join conditions. [!] The generated X++ is a template -- adapt it to your custom code context before using in production. Returns side-by-side X++ and SQL with explanations.

WHEN: you have already called prepare_release_note_context and analyzed its 'objects' array yourself, producing a findings JSON array per the 'instructions' field it returned. This tool renders that findings array into a downloadable Word (.docx, detailed appendix) and PowerPoint (.pptx, executive summary) release note and returns their download URLs. Does NOT call any LLM itself -- the reasoning must already be done by you.

Generate a security & licensing governance report for the indexed model(s). For each role, lists duties, privileges, entry points and the inferred user-license tier (Activity, Operations, Finance, etc.). Surfaces orphan duties/privileges that grant no real access.

WHEN: developer needs to write or scaffold unit tests for a custom D365 object. Triggers: 'generate tests', 'unit test', 'SysTest', 'write test for', 'scénarios de test', 'test this class'. Generate X++ SysTest unit test code for a CUSTOM D365 F&O object based on functional test scenarios. [!] Only meaningful on custom/extension code (D365_CUSTOM_MODEL_PATH). SysTest tests in D365 are highly context-specific -- a generic template rarely compiles without adaptation. REQUIRED: provide test scenarios in the 'testScenarios' parameter (supplied by the functional consultant). Each scenario becomes a concrete test method with arrange/act/assert. For tables: generates tests for find(), exist(), validateWrite(), initValue(). For classes: generates stubs for each public method listed in scenarios. Uses REAL field names and method signatures from the knowledge base.

Generate a complete, compilable AxForm AOT XML with the CORRECT control serialization (<AxFormControl xmlns="" i:type="...">) for the requested pattern. Patterns: SimpleList, DetailsMaster, DetailsTransaction, ListPage, Dialog, DropDialog, Workspace, Extension. After generation, call validate_form_pattern on the result before write_aot_object.

WHEN: writing an extension or customization -- generates ready-to-use X++ code. Triggers: 'génère un CoC', 'crée une extension', 'generate extension', 'write a CoC class', 'event handler pour', 'template pour'. Uses REAL metadata from the KB (actual field names, method signatures). 'coc' = Chain of Command class, 'table_extension' = extend table with fields/methods, 'event_handler' = pre/post event handler, 'job' = runnable class, 'find_method' = find/exist pattern. ALWAYS call get_object_details first to verify the object exists.

WHEN: developer building an OData / DMF integration needs a quick rundown of a specific data entity: its public OData name, datasources, key fields, and IsPublic status. Triggers: 'data entity info', 'OData entity details', 'is X a public entity', 'entity datasources'. Cloud-safe: pure metadata read from the KB.

WHEN: developer needs to resolve a menu item -- find its target object (form / action / output), linked security privilege, label, and parameters. Triggers: 'menu item info', 'what does menu item X open', 'menu item target', 'security privilege for menu item'. Cloud-safe: parses the AxMenuItem XML already loaded in the KB. Returns the resolved object name, menu item type (Display/Action/Output), linked privilege, and the form/class/report it points to.

WHEN: you need a COMPLETE picture of a D365 object in ONE call. Returns in a single response: full structure (fields, method signatures, relation summary) AND all CoC extensions / event handlers -- equivalent to calling get_object_details THEN find_extensions. Use this INSTEAD of those two separate calls to reduce round-trips. Optionally includes best-practice violations (set includeValidation=true). Pass `methodName` to also include the full body of a specific method. Pass `aotType` to disambiguate when several AOT objects share the same name.

WHEN: you know the EXACT object name. Triggers: user gives an exact name like 'SalesTable', 'CustTable', 'VendInvoiceJour', any PascalCase D365 object name. Get complete details: all fields, methods, relations, indexes, source code, and metadata. COST NOTE: this returns the FULL object and can be very large (100KB+ for big tables/forms like SalesLine). If you ONLY need relations / FK / DeleteActions / data sources / who-references, call get_relation_graph instead -- it is O(1) and roughly 6x lighter (no source code). Reserve get_object_details for when you genuinely need field details, method bodies, or source code. Also merges live disk source when a custom model path is configured (disk takes priority). Pass `methodName` to get the FULL body of a specific method -- without it, only signatures are returned. Calling twice -- first without methodName to get the full structure and method table, then again with a specific methodName for its full body -- is the CORRECT and INTENDED two-step pattern. Do NOT call a third time for the same object. DISAMBIGUATION: when a name exists as several AOT types (e.g. a Table AND a Form both named 'SalesLine'), this returns the PRIMARY type (Table/Class/Entity before the much heavier Form) and notes the others -- pass `aotType` (e.g. 'AxTable', 'AxForm', or shorthand 'table'/'form'/'class') to pick a specific one. This prevents dumping the heaviest object and truncating the rest. NOT for searching -- use search_d365_code when the name is uncertain. NOT for listing a model's objects -- use list_objects for that.

Retrieve the NEXT page of a previously PAGINATED tool output. When a tool result is too large for a single response, it is split losslessly into ordered pages — the footer of each page gives you a `token` and the next `page` number. Call this tool with that token to read the continuation; nothing is dropped, so you can walk every page in order and reconstruct the full result. Pages are cached only briefly (the last few large results). If the token is unknown or expired, re-run the original tool to regenerate it.

WHEN: you need the COMPLETE bidirectional relation graph for an object in ONE call. Triggers: 'relations of', 'FK of', 'what tables link to', 'quelles tables liées à', 'avant de générer du code', 'before generating code', 'foreign keys', 'delete actions', 'who references', 'qui référence', 'graph de relations'. Returns ALL outgoing edges (FK relations, DeleteActions, DataSources, Extensions, Security...) AND all incoming back-references (forms, entities, CoC classes, privileges... that reference it). Backed by the pre-computed relation index -- O(1) lookup, no vector scan. Much faster and more complete than find_related_objects for known object names. ALWAYS call this before generating code that touches multiple objects or requires join logic. Use find_related_objects when the relation index is not yet built (fallback to vector scan).

WHEN: developer/security architect needs to know WHICH ROLES can access a specific form, table, menu item or service operation. Triggers: 'who can access', 'which roles see', 'security coverage for', 'quels roles ont accès à', 'find roles with access'. Walks the security graph backwards (EntryPoint -> Privilege -> Duty -> Role) and returns all roles that grant any level of access (Read / Update / Create / Delete / Correct) on the given object. Read-only: scans the in-memory KB, never writes.

WHEN: checking server status, loaded D365 version, or custom model path. Triggers: 'status', 'statut', 'is the server ready', 'how many chunks', 'index loaded'. Returns JSON with: status, indexed chunk count, loaded version, custom model path.

WHEN: developer wants to see what custom/extension objects exist in their model. Triggers: 'list my custom objects', 'what have we customized', 'show ISV objects', 'list custom model', 'what objects are in our model'. List all D365 F&O objects in the custom/extension model directory on disk. Reads the file system directly -- always reflects the latest uncommitted state. Pass `customModelPath` to specify a model directory; or set it once via the `D365-Custom-Model-Path` header in your .mcp.json (applies to all tool calls automatically).

WHEN: you need ALL objects of a given type or in a given model. Triggers: 'list all tables in ALM', 'show all classes', 'quels objets dans le modèle', 'give me all forms'. Full index scan -- returns EVERY matching object, not just top search results. Use to discover what tables, classes, forms, enums, etc. exist in a specific model. When no filters are given and a custom model is configured, defaults to listing that model. NOT for a single object -- use get_object_details. NOT for natural language search -- use search_d365_code.

WHEN: ALWAYS call this FIRST, before prepare_release_note_context -- it discovers the exact D365FO version strings and custom model ids actually indexed on THIS server, which you cannot guess. Triggers: 'release note', 'compare D365 versions', 'upgrade impact for a client', 'what changed for this client', 'regression risk', 'note de version'. Returns every indexed version (exact 'version' string to use as v1/v2, e.g. 10.0.2527.109) and every ready-to-use custom model (exact 'id' to use as customModelIds, plus its name and optional clientGroup tag -- models sharing the same clientGroup belong to the same client and should usually ALL be passed together, e.g. the client's own extensions AND a separate ISV vendor model). IMPORTANT: this server holds the ACTUAL indexed code diff and the client's ACTUAL custom code -- generic Microsoft Learn / Azure Updates / documentation-search tools do NOT have this data and must NOT be used for D365 F&O release-note or upgrade-impact questions about a specific client; those tools only know public, generic release notes, not this client's real regression/opportunity picture.

WHEN: mapping the technical D365 objects behind a business process, or understanding which tables/forms implement a flow. Triggers: 'processus métier', 'Order-to-Cash', 'Procure-to-Pay', 'Record-to-Report', 'business process flow', 'qui est impliqué dans', 'map the process', 'flux du processus', 'quels objets dans le flux'. Map a D365 F&O business process to its complete object chain. For known processes (Order-to-Cash, Procure-to-Pay, Record-to-Report, Plan-to-Produce, Inventory-Management, Hire-to-Retire, Project-Accounting, Asset-Lifecycle): shows every step with forms, tables, classes, entities, reports, and security roles involved. For any other object name: traces all dependencies (tables, classes, forms, entities) from that entry point. Produces a Mermaid process flow diagram. Use 'list' to see all known process mappings. NOT for a single object's FK relations only -- use `find_related_objects` for that (faster and more precise).

Export any D365 F&O data entity via OData (transactional, no DMF project required). Universal: works for ANY public entity. Supports $select, $filter, $orderby and follows server paging automatically. Returns CSV (default) or JSON. Use for live/ad-hoc exports and small-to-medium volumes. For very large bulk exports prefer dmf_export_package. Resolve the entity set name from the KB first (find_entity_for_table / get_data_entity_info) -- do not invent entity names.

Idempotent import of rows into any entity via OData: PATCH when the record exists (matched by keyFields), otherwise POST. Safe to re-run -- duplicates are updated, not re-created. Best for small-to-medium transactional loads (e.g. <= a few thousand rows). For bulk loads use dmf_import_file. Provide rows as a JSON array of objects; resolve key fields from the KB (get_data_entity_info) -- do not guess them.

CHAIN-OF-TOOLS PLANNER -- Execute a multi-step JSON plan in ONE call by chaining tools. Pass an EXPLICIT JSON array of steps (NL parsing disabled to prevent ambiguity). Maximum 5 steps per plan. The chain stops on any critical failure (ado_analyze_workitem, get_object_details). ## Required Format (JSON array) `[{"tool":"get_object_details","args":{"objectName":"SalesTable"}},{"tool":"validate_best_practices","args":{"objectName":"SalesTable"}}]` ## When to use - You already know the exact sequence of 2-5 tool calls needed - The output of step N is independent of step N+1 (or matches the carried context: analysis_output) - You want SSE progress events between steps ## When NOT to use - Single tool call (use the tool directly) - Plan depends on the user's intermediate decision (call tools one at a time) - More than 5 steps (split into separate calls) ## Cost: $0 -- pure in-process execution.

WHEN: building an AI-assisted D365 F&O upgrade release note (regressions + opportunities) for a specific client, and you (the calling assistant) want to do the reasoning yourself instead of the server calling its own LLM. Call resolve_client_profile FIRST -- if it finds a profile, OMIT v1/v2/customModelIds here and they will be auto-filled from it. If no profile exists, call list_release_note_inputs to get real values and pass them explicitly -- never guess them. Triggers: 'release note', 'upgrade impact for this client', 'what breaks for a client between these versions', 'regression risk', 'note de version'. Diffs two indexed D365FO versions (v1=older, v2=newer) and cross-references EVERY changed standard object against ALL the given custom models (a client can have several -- their own extensions AND a separate ISV vendor model, in which case pass both ids comma-separated) -- returning ONLY the subset of changes actually touched by the client's code (capped at 60, Removed > Modified > Added priority), each with old/new content and which custom object references it. Returns a JSON payload with an 'instructions' field telling you the EXACT schema to produce -- analyze the 'objects' array yourself, then call generate_release_note_document with your findings JSON to get the downloadable Word/PowerPoint.

WHEN: developer about to customise a standard D365 object asks 'should I use AxTableExtension, Chain of Command, EventHandler, or Delegate?'. Triggers: 'how to extend', 'best way to customise', 'extension strategy for', 'CoC ou event handler', 'comment etendre X'. Returns a ranked recommendation based on the target AOT type and the intent, with citations to the Microsoft Learn extensibility guide. Cloud-safe: pure KB lookup, no writes.

WHEN: at the START of any release-note / upgrade-impact conversation -- call this BEFORE list_release_note_inputs to check whether a Client Profile already exists for the CURRENT caller's Azure DevOps org/project (auto-detected from DEVOPS_ORG_URL/DEVOPS_PROJECT MCP headers -- you don't pass anything). If found, it gives you the client's currentVersionTag, targetVersionTag, customModelIds (their own extensions AND any attached ISV/vendor models) and the latest diff snapshot in one call -- use those directly as v1/v2/customModelIds for prepare_release_note_context, no further discovery needed. If not found, fall back to list_release_note_inputs and/or save_client_profile.

WHEN: you need to know which folder(s) are configured as the workspace/project root for the current caller. Reads D365-Custom-Model-Path and D365-Standard-Model-Path from the request headers or environment variables. Use before any tool that accepts a customModelPath/standardModelPath parameter.

WHEN: the user wants to force a full re-download and re-index of their Azure DevOps custom model. Triggers: 'resync', 'reindex', 'force sync', 'rebuild index', 'my model is stale', 'update index', 'mon index est vieux', 'rafraîchir l\'index', 'relancer l\'indexation'. Useful when the server's built-in PAT does not have access to the target DevOps organisation (e.g. a different Azure DevOps org or tenant). Pass a `pat` parameter to override the server PAT for this resync. The eviction + download runs in the background; returns status immediately. After calling, wait ~60 s then call `healthcheck` or any search tool to confirm the index is ready.

WHEN: no profile was found by resolve_client_profile and the user wants one created (or updated) for their client, so future release-note requests never need v1/v2/customModelIds again. Creates or updates a Client Profile keyed by the CURRENT caller's ADO org/project (auto-detected from MCP headers -- not a parameter). Only the fields you pass are changed; omit a field to leave it untouched on an existing profile.

WHEN: the user asks about business/functional context that lives OUTSIDE the D365 code KB -- specs, functional design docs, mapping sheets, contracts, meeting notes, screenshots' captions -- anything an admin uploaded via the admin portal's 'Context Documents' library (PDF, Word .docx, Excel .xlsx/.xlsm, CSV, plain text/Markdown/JSON). Does NOT search X++ code or AOT objects -- use search_d365_code / get_object_details for that. Triggers: 'what does the spec say about...', 'check the mapping document for...', 'cherche dans les documents de contexte', 'according to the functional design'. An excerpt containing a 'Image N' marker has a picture the text cannot convey (a diagram, a screenshot): call again with includeImages=true to receive those pictures inline.

WHEN: object name is unknown, partial, or you need to find by concept/keyword. Search the D365 F&O knowledge base for X++ code, tables, classes, forms, views, enums, EDTs, security objects using natural language or partial names. Returns ALL chunks (metadata, Declaration, methods) for the top-scoring objects so the LLM has complete context on the first call. Lower-scoring results return a short preview. No follow-up get_object_details call is needed for top results. NOT for listing all objects in a model -- use list_objects for that. NOT when the exact name is known -- use get_object_details for that. NEVER call search_d365_code twice in the same conversation turn. If one search did not find the object, answer from what you have -- do not repeat the search. When you need context on MORE THAN ONE concept simultaneously, use batch_search instead -- it runs all queries in parallel and is faster. NEVER call for ADO items (FDD, RDD, IDD, Bug, Task, PR, WorkItem, sprint, #1234) -- use ado_* tools instead.

Search D365 F&O labels across all indexed languages. Given text (e.g. 'Sales order'), finds the matching label ID (@SYS12345). Given a label ID (e.g. '@SYS12345' or '@SYS:12345'), finds the text in all languages. Accepts both D365 short form (@SYS124480) and colon form (@SYS:124480) -- both are normalized automatically. Searches across 392K+ label entries. WORKFLOW: call search_labels first to resolve the label text, then call find_references with the same label ID to find ALL X++ objects (forms, tables, classes, reports) that use it in their code or metadata. Languages: en-US and fr are loaded at startup. Other languages (de, nl, ar, es, zh...) are loaded on-demand -- first call ~15s, then instant.

WHEN: adding a new field to a table -- find the best existing D365 EDT to extend instead of using raw primitives (str, int64, real, date). Triggers: 'what EDT for', 'which EDT should I extend', 'quel EDT pour', 'quel type étendu', 'EDT for a field'. D365 best practice mandates EDT reuse over raw primitive types. Call BEFORE declaring any field with a primitive type. Returns ranked candidate EDTs with their base type, label, and model.

WHEN: developer wants to improve code quality before a PR merge or code review. Triggers: 'refactor', 'clean up', 'simplify', 'too long method', 'nested ifs', 'code smells', 'améliorer le code'. Suggest concrete refactoring actions for YOUR custom D365 F&O X++ code. [!] Only runs on custom/extension code (D365_CUSTOM_MODEL_PATH). Refactoring standard Microsoft code is not actionable. Analyzes: long methods (extract method), deep nesting (guard clauses), row-by-row operations (set-based), large switch statements (strategy pattern), hardcoded strings (constants), unprotected CLR calls (error handling), wide transactions (narrow scope). Returns before/after code examples.

WHEN: you have a large technical tool output (get_object_details, validate_best_practices, ado_analyze_workitem, detect_performance_issues...) and need it reframed for a non-technical audience. Calls the local Ollama instance (OLLAMA_HOST env var, default localhost:11434) to produce the summary. Model is configurable via ALMXPP_SUMMARIZE_MODEL (default: llama3.2).

WHEN: you need to understand the full data lifecycle of a D365 F&O table field: who writes it, who reads it, which forms display it, which reports use it, and which tables have FK relationships to its parent table. Triggers: 'where is field X set', 'qui écrit ce champ', 'data lineage', 'GDPR field audit', 'origin of field', 'what touches this field'. Requires XRef index for writer/reader analysis. Relation graph for forms and FKs. Examples: trace_field_lineage('CustTable','CreditMax') or trace_field_lineage('LedgerJournalTrans','AmountCurDebit').

WHEN: security design, licence audit, or 'what licence does this role require?'. Triggers: 'arborescence du rôle', 'licence nécessaire pour', 'what licence for role', 'role tree', 'droits du rôle', 'entry points of role', 'privilege tree for'. Builds the COMPLETE tree for ONE role: Role -> Duties -> Privileges -> Entry Points. For each entry point, classifies the required D365 licence per the March 2026 Licensing Guide: Team Members (~$8/user/mo, read-only + named tasks), Operations-Activity (~$50, warehouse mobile & production floor), Finance (~$180), Supply Chain Mgmt (~$180), Human Resources (~$22), Project Operations (~$120), Commerce (~$180). Grant-level aware: NoAccess/Read/View -> Team Members; Activity writes -> Operations-Activity; transactional writes -> full product licence based on functional area. Confidence: High (known module prefix) . Medium (keyword) . Low (fallback). Ends with a Optimization section: Team Members / Activity eligibility, role-split opportunities, per-user/month cost estimates (March 2026 MSRP). Always validate against the [Microsoft D365 Licensing Guide](https://go.microsoft.com/fwlink/?LinkId=866544). For a full multi-role scan, call `trace_role_license_tree` multiple times -- once per role. NOT for the pure technical duty/privilege/entry-point chain without licence inference -- use `trace_security_chain` for that.

WHEN: security audit -- need the TECHNICAL chain from Role/Duty/Privilege to Entry Points and Table/Form permissions. Also handles BUSINESS-LANGUAGE role explanation when businessLanguage=true. Triggers (technical): 'sécurité de', 'who can access', 'security for', 'role duty privilege', 'droits sur', 'technical security chain', 'trace le rôle', 'what privileges does', 'what duties are assigned', 'which role allows', 'accès au formulaire', 'what roles have access', 'quel rôle donne accès'. Triggers (business language): 'what can a user with role X do', 'explain this role', 'what does this role give access to', 'quel accès donne ce rôle', 'droits du rôle', 'what licence does this role need', 'droits requis pour'. Traverses: Role -> Duties -> Privileges -> Entry Points -> Table/Form Permissions. Set businessLanguage=true for plain-language capability list (no Duty/Privilege IDs). NOT for licence cost inference per entry point -- use trace_role_license_tree for that.

Run an in-house best-practice audit on any AOT object (custom or standard), from the indexed source -- NOT the Microsoft BP checker. Rules are this server's own: SEC (security chain), PERF (firstOnly, set-based, N+1), TXN (ttsbegin/ttscommit pairing), ERR (error handling), COC (next() vs super()), QUAL, DATA (EDT on fields), CONV (naming, ISV prefix) and CLOUD. It runs pre-compile and needs no D365 install, so it catches things while the code is being written -- but it does not replace xppbp.exe, whose rule set and monikers are different. For the authoritative Microsoft verdict run run_best_practices_check (xppc.exe -BestPractices, whole model) or run_best_practices_check_scoped (xppbp.exe, one object). Returns violation table: severity (Critical/Warning), rule ID, code snippet, fix instruction. For deep N+1 / row-by-row performance profiling use detect_performance_issues instead. [!] Auto-fixing Critical violations requires D365_CUSTOM_MODEL_PATH (custom code only).

WHEN: developer needs to check that a proposed object name follows D365 + ISV naming conventions, is unique against the indexed KB, and does not collide with a reserved or standard prefix. Triggers: 'is this a valid name', 'check naming', 'name conflict', 'valider le nommage'. Cloud-safe: KB read only, no writes.