Skip to main content
Glama

ALM X++ MCP Server

by io.github.alimbenhelal-pro
OverviewDiscussionsAdmin

search_d365_code

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topKNoMaximum number of results to return (default: 10, max: 50)
queryYesNatural language search query. Examples: 'vendor invoice approval', 'tables in ALM', 'SalesTable fields', 'security privileges for purchasing'
scopeNoOptional routing override: 'auto' (default — session/custom first, standard fallback), 'custom' (session only — fails over to standard if nothing found), 'standard' (skip session entirely), 'both' (federated, no priority).
domainNoOptional: filter results to a specific AOT type. Examples: 'AxTable', 'AxClass', 'AxForm', 'AxEnum'. Leave empty for all types.
topObjectsNoNumber of top-scoring objects whose ALL chunks are returned (default: 5, max: 20). Increase to broaden coverage, decrease for tighter focus.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / scope
      Added value: +{
+  "default": null,
+  "description": "Optional routing override: 'auto' (default — session/custom first, standard fallback), 'custom' (session only — fails over to standard if nothing found), 'standard' (skip session entirely), 'both' (federated, no priority).",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Natural language search query. Examples: 'vendor invoice approval', 'tables in HSO', 'SalesTable fields', 'security privileges for purchasing'"New value: +"Natural language search query. Examples: 'vendor invoice approval', 'tables in ALM', 'SalesTable fields', 'security privileges for purchasing'"
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses rich behavioral traits: top-scoring objects return ALL chunks (metadata, Declaration, methods) so no follow-up get_object_details is needed, lower-scoring results return only a short preview, and the hard rule against calling twice in one turn. This meaningfully shapes agent expectations about output size and call strategy.

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 long but every sentence earns its place — it covers routing, behavior, and hard operational rules with zero filler. The WHEN/NOT/NEVER markers provide effective scannable structure despite being a single paragraph, and the most decision-critical info (when to use) is front-loaded.

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?

With no output schema, the description properly explains return behavior (full chunks vs preview). The name-based, listing-based, multi-concept, and ADO alternatives are all named. Safety is covered by annotations, parameters are fully documented in the schema, and edge-case policies (don't repeat search, answer from what you have) are included. Nothing an agent needs to call this correctly is missing.

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, but the description adds real semantic value: it explains the practical consequence of topObjects/topK ('Returns ALL chunks for the top-scoring objects... Lower-scoring results return a short preview') and implies that top results are self-sufficient. It doesn't add per-parameter syntax, but the result-behavior mapping goes beyond the schema's generic parameter descriptions.

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 ('Search') plus resource ('the D365 F&O knowledge base') and enumerates exactly what can be found: X++ code, tables, classes, forms, views, enums, EDTs, security objects, via natural language or partial names. It clearly distinguishes itself from siblings by stating what it is NOT (list_objects, get_object_details, batch_search, ado_* tools).

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?

Usage conditions are explicit and comprehensive: use it WHEN the name is unknown/partial or searching by concept; use list_objects for listing a model; use get_object_details when the exact name is known; use batch_search for multiple simultaneous concepts; use ado_* tools for ADO items. It even forbids repeated calls in the same turn, leaving zero ambiguity about when to invoke this tool.

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