AL MCP: al_downloadsymbols ignores projectPath — always operates on the first workspace project

Describe the issue

In a multi-project workspace, the al_downloadsymbols MCP tool ignores its projectPath parameter for project selection. Regardless of which project path is passed, it reads the manifest, checks references, and downloads into the package cache of the first project loaded at server start. This makes it impossible to provision symbols for the other projects of a multi-project workspace from a single MCP server instance.

Environment: microsoft.dynamics.businesscentral.development.tools 18.0.37.11445-beta (dotnet tool), al launchmcpserver, stdio transport, Windows 11, net10.0.

Steps to reproduce

1. Workspace with multiple projects, e.g. a main app and a test app with different dependencies (test app references Test Runner, Library Assert, etc.):

   al launchmcpserver app test-app --transport stdio
   

2. Call the tool for the second project:

   {"name":"al_downloadsymbols","arguments":{"projectPath":"C:/work/repo/test-app","globalSourcesOnly":true,"force":true}}
   

Expected

Symbols for test-app's references downloaded into test-app/.alpackages.

Actual

The response reports the first project's reference count and cache path (app/.alpackages); the test app's references (Test Runner, Library Assert, ΓǪ) are never examined. Relative paths and absolute paths behave identically. There is no error or warning that projectPath was not honored.

{"succeeded":true,"message":"All symbols are already in cache. No download needed.",
 "data":{"downloadedCount":0,"totalReferences":3,"requestedCount":0,
 "cachePath":"C:\\work\\repo\\app\\.alpackages"}}

Root cause

Microsoft.Dynamics.Nav.LanguageModelTools.DownloadSymbols.DownloadSymbolsService.DownloadSymbolsAsync selects the project as:

Project project = currentSolution.Projects.FirstOrDefault();

parameters.ProjectPath is only consumed by ConnectionOptionsBuilder.MergeFromLaunchJson to locate a launch.json for server-connection defaults ΓÇö it never participates in project selection. (Compare with the al_build handler, which resolves the target correctly via solution.FindProject(projectPath), and al_getdiagnostics, which filters on project.ProjectFolder.)

Impact / workaround

A multi-project workspace (e.g. app + test apps, the standard AL test setup) cannot be symbol-provisioned through one MCP server. Current workaround is launching a separate ephemeral al launchmcpserver <project> per project so each becomes the "first" project ΓÇö confirmed working, but it defeats the per-call projectPath parameter and the documented multi-project workspace support.

Suggested fix

Resolve the target project the same way al_build does (solution.FindProject(parameters.ProjectPath), falling back to the first project when the parameter is empty), and return an error when a supplied projectPath matches no loaded project instead of silently using a different one.

Internal work item: AB#648589

Start in DownloadSymbolsService.DownloadSymbolsAsync and trace how the current solution selects a project. Compare that resolution with al_build's solution.FindProject(projectPath) behavior and reproduce the multi-project MCP call from the issue. Done means the requested project's references and .alpackages cache are used, with an error for an unknown supplied path and first-project behavior only when the path is empty.