Integrates with GitHub Copilot to allow AI-powered code assistance for AL development, including searching objects, viewing definitions, finding references, and managing AL packages.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AL MCP Server Find references to Customer table"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give AI assistants complete visibility into your AL dependencies and symbols.
AI coding assistants can't see compiled AL packages or understand Business Central object relationships. This creates a blind spot when helping with AL development.
The AL MCP Server bridges this gap by exposing your AL workspace's compiled symbols (.app files) directly to AI assistants through the Model Context Protocol.
Related MCP server: CodeAtlas MCP Server
Node.js 18+ (download)
.NET SDK 8.0+ (download)
Compiled AL packages (.app files in .alpackages directory)
Verify your setup:
dotnet --version # Should show 8.0 or higherThe AL MCP Server installs automatically via npx - no manual installation needed.
claude mcp add al-mcp-server -- npx al-mcp-serverOr via VS Code settings:
{
"claude.mcpServers": {
"al-symbols-mcp": {
"command": "npx",
"args": ["al-mcp-server"]
}
}
}Create .vscode/mcp.json in your workspace:
{
"servers": {
"al-symbols-mcp": {
"type": "stdio",
"command": "npx",
"args": ["al-mcp-server"]
}
}
}Add to Cursor settings (Settings → Features → Model Context Protocol):
{
"al-symbols-mcp": {
"command": "npx",
"args": ["al-mcp-server"]
}
}Add to ~/.continue/config.json:
{
"mcpServers": {
"al-symbols-mcp": {
"command": "npx",
"args": ["al-mcp-server"]
}
}
}Add to VS Code settings:
{
"cody.mcpServers": {
"al-symbols-mcp": {
"command": "npx",
"args": ["al-mcp-server"]
}
}
}Use these connection details:
Command: npx
Args: ["al-mcp-server"]
Type: stdio
Ask your AI assistant:
Search for Customer table in my AL projectThe server will auto-start and provide intelligent AL assistance!
The AL MCP Server provides 6 token-optimized tools for AL code analysis:
al_search_objects
Search for AL objects by name, type, or wildcard pattern
Filter by business domain (Sales, Finance, Inventory, etc.)
Support for all AL object types (Table, Page, Codeunit, Report, etc.)
Token-efficient summary mode enabled by default
al_get_object_definition
Get detailed object information by ID or name
Includes fields, procedures, properties, and keys
Configurable detail level with field/procedure limits
Summary mode for token efficiency
al_find_references
Find all references to an object or field
Track extensions, variables, parameters, return types
Field-level reference tracking across all object types
Optional context for detailed reference information
al_search_object_members
Unified search for object child elements
Search procedures, fields, controls, or dataitems
Wildcard pattern matching support
Pagination and detail level control
al_get_object_summary
Get intelligent categorized overview of objects
Organizes procedures by purpose (validation, posting, utilities, etc.)
Identifies key entry points automatically
Highly token-efficient categorized output
al_packages
Unified package management with action parameter
Load: Auto-discover and load packages from project root
List: Show all currently loaded packages
Stats: Database statistics and object counts
Search across all loaded AL packages simultaneously
Wildcard pattern matching for flexible queries
Filter by object type, package, or business domain
Auto-discovery of .alpackages directories
Complete object definitions with all metadata
Procedure and field information with properties
Page control structure analysis
Report/query dataitem traversal
Find all object references and dependencies
Track object extensions and customizations
Field-level usage analysis across pages, tables, reports
Variable and parameter tracking in codeunits
Search by business area (Sales, Purchasing, Finance, Inventory, Manufacturing, Service)
Pattern-based domain detection
Cross-package domain analysis
AL MCP Server
├── Symbol Extraction Layer
│ └── AL CLI integration for .app file parsing
├── Streaming Parser
│ └── Efficient handling of large symbol files (50MB+)
├── In-Memory Database
│ └── Optimized indices for sub-100ms queries
├── MCP Protocol Handler
│ └── JSON-RPC communication with AI assistants
└── Auto-Discovery Engine
└── Smart .alpackages directory detectionPerformance Features:
Lazy initialization - packages load on first request
Streaming JSON parsing prevents memory issues
Multiple optimized indices for O(1) lookups
Version filtering uses latest package only
Token-optimized responses reduce AI context usage
Runtime:
Node.js 18 or higher
.NET SDK 8.0 or higher
NuGet package source (nuget.org)
Project Structure:
AL workspace with app.json
Compiled .app packages in .alpackages directory
Supported AL Packages:
Modern namespace-based packages
Legacy non-namespace packages (PTEs)
Business Central base application
AppSource extensions
The server analyzes compiled AL symbols, not raw .al source files.
AL CLI not found
The server auto-installs AL tools
Requires .NET SDK 8.0 or higher
Verify: dotnet --version
NU1100 error
Update to .NET SDK 8.0+
Configure NuGet: dotnet nuget add source https://api.nuget.org/v3/index.json -n nuget.org
No sources found
Check NuGet sources: dotnet nuget list source
Should include nuget.org
No packages found
Ensure .app files exist in .alpackages directory
Use al_auto_discover tool to search for packages
Check that packages were compiled successfully
Server not responding
Verify Node.js 18+ is installed
Check AI assistant MCP configuration
Review server logs in AI assistant output
Need Help?
Once configured, ask your AI assistant:
"Show me all Sales-related codeunits"
"Find all references to the Customer table"
"What procedures are in the Sales-Post codeunit?"
"Search for all pages that use the Item table"
"Give me a summary of the Gen. Journal-Post Batch codeunit"The AI assistant will use the MCP tools to provide accurate, context-aware responses based on your actual AL packages.
Fork the repository
Create a feature branch
Write tests for changes
Ensure all tests pass
Submit a pull request
MIT License - see LICENSE file for details.
Transform AL development with AI assistants that truly understand your codebase.
Find object/field references in YOUR WORKSPACE. Tracks extensions, variables, parameters, field usage, and table relations across all object types.
| Name | Required | Description | Default |
|---|---|---|---|
| targetName | Yes | Target object or table name | |
| fieldName | No | Field name (optional, use "*" for all fields) | |
| referenceType | No | Reference type filter | |
| sourceType | No | Source object type filter | |
| includeContext | No | Include detailed context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It explains the tool tracks various references but omits details like read-only nature, permissions, performance implications, or output format. The behavioral information is present but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. It is concise with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the tool's complexity (5 parameters with enums), the description does not cover expected return format, pagination, or error scenarios. It is insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. The high-level description complements the schema but doesn't offer new semantic meaning beyond what the parameter descriptions provide. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'object/field references'. It specifies the scope 'in YOUR WORKSPACE' and lists what it tracks (extensions, variables, etc.). This distinguishes it from sibling tools like al_get_object_definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates workspace scope but does not provide explicit guidance on when to use this tool vs alternatives like al_search_objects. No exclusions or conditions for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AL object definition from YOUR WORKSPACE. Retrieves compiled code structure by ID or name. Use summaryMode:true for token efficiency. Use limits for large objects.
| Name | Required | Description | Default |
|---|---|---|---|
| objectId | No | Object ID | |
| objectName | No | Object name (alternative to ID) | |
| objectType | No | Object type | |
| packageName | No | Package (for disambiguation) | |
| includeFields | No | Include table fields | |
| includeProcedures | No | Include procedures | |
| summaryMode | No | Summary view (recommended) | |
| fieldLimit | No | Max fields (10 summary/100 full) | |
| procedureLimit | No | Max procedures (10 summary/50 full) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions retrieving compiled code structure but does not disclose behavioral traits such as read-only nature, auth requirements, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear front-loading of purpose, followed by method and usage tips. No filler, but could be slightly more detailed without major bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description is terse. It covers key usage tips but lacks explanation of return format or how fields like includeFields affect output. Average completeness for complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description adds value with usage guidance like 'summaryMode for token efficiency' and 'limits for large objects', but does not substantially enhance parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get' and resource 'AL object definition' with specific retrieval methods by ID or name. Distinguishes from sibling tools like al_find_references and al_get_object_summary by focusing on full definition retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides tips for token efficiency with summaryMode and limits for large objects, but lacks explicit when-to-use or when-not-to-use compared to sibling tools like al_get_object_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
✅ TOKEN EFFICIENT: Get categorized overview of AL object in YOUR WORKSPACE. Intelligent procedure grouping with 96% token reduction vs full definition.
| Name | Required | Description | Default |
|---|---|---|---|
| objectName | Yes | Object name | |
| objectType | No | Object type (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses token efficiency and intelligent grouping, but does not mention side effects, authentication needs, or limitations. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with a clear first sentence and a benefit-oriented second sentence. The emoji is unnecessary but not detrimental. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description provides minimal context. It explains the tool's purpose and benefit but lacks details on return format, error handling, or prerequisites. Adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no further semantics beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get', the resource 'categorized overview of AL object', and the scope 'in YOUR WORKSPACE'. It distinguishes from siblings by mentioning token reduction vs full definition, differentiating it from al_get_object_definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a token-efficient overview is needed, explicitly comparing to 'full definition'. However, it lacks explicit when-not-to-use conditions or clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Package management: load compiled .app packages, list loaded packages, or get stats. Auto-discovers .alpackages if path provided.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| path | No | Path to packages directory or AL project root (for load action) | |
| autoDiscover | No | Auto-discover .alpackages directories (default: true for load) | |
| forceReload | No | Force reload packages |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. Mentions auto-discovery but does not describe side effects of 'load' (e.g., changing state), implications of 'forceReload', or whether 'list' and 'stats' are safe operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and to the point, no redundant sentences. Could be slightly more structured but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description should cover return values and error conditions. It does not describe what each action returns or what errors might occur, leaving the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for each parameter. The description adds context about auto-discovery but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (package management) and resource (.app packages) with three specific actions: load, list, stats. Differentiates from sibling tools which are about searching objects and references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context about auto-discovery but lacks explicit guidance on when to use each action or when to use this tool over alternatives. Siblings are different enough that confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search procedures, fields, controls, or dataitems within an object in YOUR WORKSPACE. Unified search for all object child elements.
| Name | Required | Description | Default |
|---|---|---|---|
| objectName | Yes | Parent object name | |
| objectType | No | Object type (optional) | |
| memberType | Yes | Member type to search | |
| pattern | No | Filter pattern (wildcards supported) | |
| limit | No | Max results (default: 20) | |
| offset | No | Pagination offset (default: 0) | |
| includeDetails | No | Include full details |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states 'search' which is obvious from the tool name. It does not disclose whether the operation is read-only, any destructive side effects, authentication requirements, or rate limits. The description adds no behavioral insight beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the core purpose. It is front-loaded with the verb and resource. No fluff, but could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description should provide more context about return values, pagination behavior, or default limits. It lacks completeness for a tool of this complexity, leaving the agent to infer behavior from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% so the baseline is 3. The description adds no parameter-level explanation beyond the schema, but does not omit anything. It does not illustrate usage or provide additional context for parameters like pattern or pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource 'procedures, fields, controls, or dataitems within an object', distinguishing it from siblings like al_search_objects which searches objects themselves. It explicitly says 'Unified search for all object child elements' which reinforces the specific domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the scope ('in YOUR WORKSPACE') and the type of elements searched. While it doesn't explicitly mention when not to use or name alternatives, the sibling tools provide context: al_search_objects for objects, al_find_references for references. The usage is implied but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AL objects in YOUR WORKSPACE (.app packages). Analyzes compiled AL code structure. Use summaryMode:true & limit for token efficiency. For complex objects prefer al_get_object_summary. Supports domain filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Search pattern (wildcards supported) | |
| objectType | No | Filter by type | |
| packageName | No | Filter by package | |
| domain | No | Business domain filter | |
| includeFields | No | Include table fields (increases tokens) | |
| includeProcedures | No | Include procedures (increases tokens) | |
| limit | No | Max results (default: 20) | |
| offset | No | Pagination offset (default: 0) | |
| summaryMode | No | Summary view (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies read-only search/analysis but does not explicitly state non-destructiveness, auth needs, or other behavioral traits. The description is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding unique value: purpose, efficiency tip, and alternative tool. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 9 parameters and no output schema, the description covers purpose, usage tips, and alternatives. It lacks explicit mention of output format or pagination details, but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description reinforces some parameters (summaryMode, limit, domain) but adds little new semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches AL objects in the workspace and analyzes compiled code structure. It distinguishes itself by mentioning domain filtering and noting an alternative tool for complex objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: use summaryMode:true and limit for token efficiency, and prefer al_get_object_summary for complex objects. This directly helps the agent choose the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.5.0al_find_referencesal_get_object_definitional_get_object_summaryal_packagesal_search_object_membersal_search_objectsEach tool has a clearly distinct purpose: references, object definition, summary, package management, member search, and object search. No overlap; an agent can easily differentiate.
Five tools follow the 'al_verb_noun' pattern (e.g., al_find_references, al_get_object_definition), but 'al_packages' uses a noun only, breaking the pattern. Otherwise consistent.
With 6 tools, the set is well-scoped for AL development code analysis. Each tool serves a distinct purpose without being excessive or insufficient.
Covers core code analysis needs: references, definitions, summaries, and searches. Missing modification or deployment tools, but read-only analysis is reasonably complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Versioned documentation registry and semantic search for AI tools and coding assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/StefanMaron/AL-Dependency-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server