Skip to main content
Glama

ALM X++ MCP Server

by io.github.alimbenhelal-pro
OverviewDiscussionsAdmin

generate_query

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNoOptional: limit rows (1 = firstonly, N = top N)
fieldsNoOptional: specific fields to select (comma-separated). All fields if not specified.
filtersNoOptional: WHERE filter expressions (comma-separated), e.g. 'CustAccount == 1001, SalesStatus == SalesStatus::Open'
orderByNoOptional: field to ORDER BY
tableNameYesPrimary table name, e.g. 'SalesTable', 'CustTable'
joinTablesNoOptional: tables to join (comma-separated), e.g. 'CustTable,SalesLine'
descriptionNoOptional: natural language description of the query. If provided, fields/joins/filters are auto-detected.
crossCompanyNoWhether to add crosscompany clause (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context by explaining that generated X++ is only a template, that joins depend on the relation index, and that results are returned side-by-side with explanations. 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 longer than average but well-structured with WHEN, triggers, supported features, warnings, and return value. Every section earns its place, and important usage warnings are clearly flagged.

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?

There is no output schema, but the description explicitly states the return format: side-by-side X++ and SQL with explanations. It also covers prerequisites, supported query features, natural-language input, and the production caveat, making it sufficient for an agent to invoke correctly.

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 meaningful semantics by explaining that natural-language descriptions trigger auto-detection of fields/joins/filters and that multi-table joins are auto-detected from relations, which clarifies the description and joinTables parameters beyond schema details.

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 action—generate both X++ select statements and equivalent T-SQL queries for D365 F&O tables—and clearly identifies the resource and output. It also distinguishes itself from related tools by referencing the prerequisite use of find_related_objects and get_relation_graph for join accuracy.

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?

The 'WHEN' section and trigger phrase list tell an agent exactly when to invoke this tool. It also gives explicit guidance to call find_related_objects or get_relation_graph first for multi-table joins, and warns that generated X++ is a template requiring adaptation, which is strong usage direction.

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