Skip to main content
Glama

ALM X++ MCP Server

by io.github.alimbenhelal-pro
OverviewDiscussionsAdmin

get_object_details

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aotTypeNoOptional: AOT type to disambiguate when several objects share the name, e.g. 'AxTable', 'AxForm', 'AxClass' (shorthand 'table'/'form'/'class'/'enum'/'edt'/'view'/'entity' also accepted). When omitted and the name is ambiguous, the primary type (Table/Class/Entity before Form) is returned with a note listing the others.
methodNameNoOptional: specific method name to return full body for, e.g. 'send', 'run', 'validate'. When provided, returns the complete method source instead of the signature table.
objectNameYesThe exact object name, e.g. 'SalesTable', 'VendInvoiceApprovalConfig', 'ALMAlternativeItemsTable'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / aotType
      Added value: +{
+  "default": null,
+  "description": "Optional: AOT type to disambiguate when several objects share the name, e.g. 'AxTable', 'AxForm', 'AxClass' (shorthand 'table'/'form'/'class'/'enum'/'edt'/'view'/'entity' also accepted). When omitted and the name is ambiguous, the primary type (Table/Class/Entity before Form) is returned with a note listing the others.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / objectName / description
      Previous value: -"The exact object name, e.g. 'SalesTable', 'VendInvoiceApprovalConfig', 'HSOAlternativeItemsTable'"New value: +"The exact object name, e.g. 'SalesTable', 'VendInvoiceApprovalConfig', 'ALMAlternativeItemsTable'"
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Despite annotations already declaring readOnlyHint, idempotentHint, and non-destructive behavior, the description adds significant behavioral context: response can exceed 100KB, methodName changes output from signatures to full source, disk source takes priority, ambiguous names return the primary type and note alternates. These are non-obvious behaviors an agent needs to invoke correctly, and none contradict the 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 longer than average, but it earns its length with dense, non-redundant guidance organized into readable sections (WHEN, COST NOTE, DISAMBIGUATION, NOT). A small amount of repetition exists around when to prefer get_relation_graph, but overall the structure front-loads the critical trigger and keeps each sentence informative.

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?

Even without an output schema, the description explains what the returned data contains (fields, methods, relations, indexes, source code, metadata), size expectations, the signature-vs-full-body distinction, disk-source merging, and type disambiguation. Given the tool's complexity and no output schema, this is a complete, self-sufficient description for correct invocation.

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

Parameters5/5

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

Schema coverage is 100%, so a baseline of 3 applies, but the description adds substantial meaning: objectName must be 'EXACT' and PascalCase; methodName omission yields only signatures while providing it yields the full body; aotType is explained as a disambiguation mechanism with accepted shorthand values. It also clarifies a subtle interaction between methodName and the intended two-step workflow, going well beyond 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?

The description states a specific verb and resource: 'Get complete details: all fields, methods, relations, indexes, source code, and metadata' for an exact object name. It distinguishes itself clearly from search_d365_code and list_objects, and from get_relation_graph, making the purpose unmistakable.

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 is exceptionally well-specified: it says to use this tool only when exact names are known, and explicitly directs to get_relation_graph for relations-only needs, search_d365_code for uncertain names, and list_objects for listing a model's objects. It also documents the intended two-step calling pattern and warns against a third call, leaving no ambiguity about when and how to use it.

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