Skip to main content
Glama

ALM X++ MCP Server

by io.github.alimbenhelal-pro
OverviewDiscussionsAdmin

ado_analyze_pr_impact

Read-onlyIdempotent

[~] PRIORITY TRIGGER: Use this tool when the user says 'analyse PR', 'review PR', 'check PR', 'PR #', 'impact du PR', 'analyse la PR', 'what changed in PR', 'D365 impact of PR', 'code review PR', 'violations in PR', 'PR review'. NEVER call search_d365_code when 'PR' or 'Pull Request' + a number is mentioned. Analyse the full D365 F&O code impact of a Pull Request. Reads each changed file's CONTENT straight from the PR's source commit via the ADO REST API, so it reviews the PROPOSED (un-merged) code -- including brand-new files that do not yet exist on the target branch. DO NOT fall back to local git show/git diff: this tool already pulls the un-merged content over the API and analyses it against the indexed standard KB. When includeSource is true (the default), the FULL un-merged source of every analysed file is embedded in the output (one fenced block per file), so you have everything needed for a complete semantic review -- BP findings AND the actual code -- in a single call. NEVER run git to read the files. This matters for metadata-only PRs (tables/enums/menu items/reports): the BP engine is X++-centric and may report few violations on AOT XML, but the embedded source lets you review those changes properly. For every X++ class/table/form/extension modified in the PR: (1) Best Practice validation -- reports Critical and Warning violations. (2) Upgrade impact -- cross-references CoC targets, event handlers, and extensions against the D365 standard code. (3) Extension conflicts -- finds existing CoC/extensions that may conflict. (4) Produces a ready-to-post PR review comment addressed to the PR author. After reviewing, call ado_post_pr_comment to post the review (requires user confirmation). Requires DEVOPS_ORG_URL + DEVOPS_PAT (Code: Read).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prIdYesPull Request ID (integer), e.g. 42.
projectNoOptional: Azure DevOps project name. Falls back to DEVOPS_PROJECT env var.
maxFilesDeepNoMax X++ files to fully analyse (default 10, max 20). Larger PRs get a summary for remaining files.
repositoryIdYesGit repository name or ID.
includeSourceNoEmbed the un-merged SOURCE of each analysed file in the output so the reviewer can do a full semantic code review without a local git checkout. Default true.
includeWarningsNoInclude Warning-level violations in addition to Critical (default: true). Set false for Critical-only.
sourceCharsPerFileNoMax characters of source to embed per file when includeSource is true (1000-40000, default 8000). Larger files are truncated with a note.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / includeSource
      Added value: +{
+  "default": true,
+  "description": "Embed the un-merged SOURCE of each analysed file in the output so the reviewer can do a full semantic code review without a local git checkout. Default true.",
+  "type": "boolean"
+}
    • addedInput schema / properties / sourceCharsPerFile
      Added value: +{
+  "default": 8000,
+  "description": "Max characters of source to embed per file when includeSource is true (1000-40000, default 8000). Larger files are truncated with a note.",
+  "type": "integer"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnly/idempotent/open-world/non-destructive; the description adds substantial behavior: it reads un-merged source via the ADO REST API, analyses against the indexed standard KB, embeds source when includeSource is true, acknowledges the BP engine's X++-centric limitation for AOT XML, and states the required scope (DEVOPS_ORG_URL + DEVOPS_PAT with Code:Read). No contradiction with annotations.

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

Conciseness4/5

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

The description is front-loaded with a priority trigger and organized around numbered analysis steps, so an agent can quickly identify the tool's purpose. It is long and contains some redundant warnings ('DO NOT fall back' vs 'NEVER run git'), but nearly every sentence carries operational or selection value.

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?

Despite having no output schema, the description fully covers the input preconditions, the method, the returned content (source and four concrete analysis outputs), and the follow-up action (ado_post_pr_comment requiring user confirmation). This gives an agent enough context to invoke and interpret the tool correctly for a complex PR analysis.

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

Parameters3/5

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

Schema description coverage is 100% with detailed per-parameter docs, so the baseline is 3 and the description need not compensate. The description repeats context for includeSource but contributes little new meaning for prId, repositoryId, maxFilesDeep, or sourceCharsPerFile; the 'FULL source' claim is also tempered by the sourceCharsPerFile truncation rule in the schema.

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?

States a clear, specific purpose: 'Analyse the full D365 F&O code impact of a Pull Request,' with enumerated outputs (BP validation, upgrade impact, extension conflicts, review comment). It also explicitly frames itself as the tool to use for PR review and names search_d365_code as the tool to avoid, so its scope is unambiguous against at least the most likely sibling.

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?

Provides unusually explicit trigger phrases, a hard 'NEVER' exclusion for search_d365_code, and direction not to use local git workflows or to call ado_post_pr_comment afterwards. However, it does not disambiguate from the closely named sibling ado_review_xpp_pr, which likely occupies the same PR-review space, leaving some potential selection ambiguity.

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

All ALM X++ MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources