[MCP] Server Features in MCP configuration: API Tools, Dynamic Tool Mode, Data Query Tools (Preview)

[onbuyuka]

Summary

Adds a Server Features surface to the MCP configuration card so admins can opt configurations into the Data Query Tools (Preview) MCP runtime, alongside the existing Dynamic Tool Mode and API Tools controls. Each feature is a self-contained handler behind an interface, so the card is data-driven and extensible. Activation persists on the real MCP Configuration fields shipped in BC-Platform #44811; only the Data Query Tools server runtime lands separately (see Platform dependency).

Feature handlers (interface-based)

• New interface "MCP Server Features" — SetActive / IsActive / HasSettings / OpenSettings / Description / LoadSystemTools / TryGetParentFeature. enum "MCP Server Feature" implements it, binding each value to a handler codeunit; resolving ServerFeature := Rec.Feature replaces the old per-feature case blocks.
• Both the MCP Server Feature List and MCP System Tool List pages are fully generic: each walks ServerFeature.Ordinals() + FromInteger(...) (the same pattern as MCP Config Warning Type) and dispatches every action — activation, settings, descriptions, and system-tool loading — through the handler. Adding a feature is a new enum value + handler codeunit — no page edits.
• Each feature owns its description, activation, settings, system tools, and rules; SetActive delegates to codeunit "MCP Config Implementation", which reads/writes the real MCP Configuration fields (EnableDynamicToolMode, EnableApiTools, EnableAlQueryTools); IsActive reads them back.

Card UX

• Server Features list-part with per-row Activate / Deactivate / Configure, mirroring page 7775 "Copilot AI Capabilities" → Copilot Capabilities GA. Configure appears only for features that have settings — gated on a per-row Configurable flag set from the handler's HasSettings(). Dynamic Tool Mode renders indented as a sub-feature of API Tools (TryGetParentFeature + an Indentation column on the temp table).
  • API Tools — gates the Available APIs list-part (Visible = not IsDefault and APIToolsActive), where the admin curates which API pages / queries the client can reach. No settings.
  • Dynamic Tool Mode — its Configure dialog hosts Discover Read-Only Objects; activation flows to EnableDynamicToolMode, deactivation cascade-clears DiscoverReadOnlyObjects. Enabling it requires API Tools to be enabled first — impl.EnableDynamicToolMode enforces the gate (APIToolsRequiredForDynamicErr).
  • Data Query Tools (Preview) — contributes the Data Query Tools system tools when active. No settings.
• Available APIs (page 8352) — the curated API list. Its Select APIs action opens a single lookup listing both API pages and API queries (new temp table "MCP API Object Buffer" + page "MCP API Object Lookup", populated by impl.LookupAPIObjects); the per-row Object Id lookup shares the same path. The part was renamed 'Available Tools' → 'API Tools' → 'Available APIs' to disambiguate it from the API Tools feature row.
• The single settings StandardDialog (page 8369 "MCP Server Feature Settings") is used only by Dynamic Tool Mode; its handler runs it via OpenSettings, writing on OK.
• The System Tools list-part (right-rail FactBox) is rebuilt by iterating the active features and calling each handler's LoadSystemTools.

Configuration list (page 8350)

• The Default field is read-only on the card; Set as Default / Clear Default actions (promoted) live on the configuration list instead.
• Read-only API Tools / Data Query Tools status columns (bound to Rec.EnableApiTools / Rec.EnableAlQueryTools) replaced the previous Dynamic Tool Mode / Discover Read-Only Objects columns.

Public API

• codeunit 8350 "MCP Config" exposes EnableAPITools and EnableDataQueryTools alongside the existing EnableDynamicToolMode / EnableDiscoverReadOnlyObjects. The two feature procedures read/write the MCP Configuration.EnableApiTools / .EnableAlQueryTools fields.

New objects

• interface "MCP Server Features"
• enum 8351 "MCP Server Feature" (implements "MCP Server Features"; API Tools, Dynamic Tool Mode, Data Query Tools)
• table 8355 "MCP Server Feature" (temporary; carries Configurable + Indentation)
• table 8357 "MCP API Object Buffer" (temporary; unifies API pages + queries for the Select APIs lookup)
• page 8368 "MCP Server Feature List", page 8369 "MCP Server Feature Settings", page 8376 "MCP API Object Lookup"
• handler codeunits 8369 "MCP API Tools Feature", 8368 "MCP Data Query Tools Feature", 8370 "MCP Dyn. Tool Mode Feature"

Deprecated

• Pages 8353 "MCP API Config Tool Lookup" / 8367 "MCP Query Config Tool Lookup" are obsoleted (ObsoleteState = Pending, ObsoleteTag = '29.0', wrapped in #if not CLEAN29) — superseded by the unified MCP API Object Lookup (8376). They're public System Application objects, so they're deprecated rather than deleted (removing them breaks dependent extensions — AS0029). Their internal MCP Config Implementation lookup procedures (LookupAPIPageTools / LookupAPIQueryTools) and the test-library wrappers were removed (neither is public surface).

Permissions

• MCP - Objects lists the new app tables (MCP Server Feature, MCP API Object Buffer).

Platform dependency

BC-Platform PR #44811 has merged, and this PR is productionized against it — no mocks remain (grep -rn "MOCK:|PLATFORM-PENDING" "src/System Application/App/MCP/" is empty).

• Activation persists on MCP Configuration.EnableApiTools (field 8, InitValue = true) / .EnableAlQueryTools (field 9), read/written through four MCP Config Implementation procedures. An upgrade (MCP Upgrade.EnableApiToolsOnExistingConfigurations) turns API Tools on for existing configurations (InitValue only covers new ones).
• Data Query Tools system tools come from "MCP Utilities".GetSystemToolsInDataQuery().

The platform uses the "AL Query Tools" field name; our UX stays "Data Query Tools" (it maps onto EnableAlQueryTools).

The Data Query Tools server runtime (compile + execute of client-submitted AL queries) is a separate, larger platform dependency — this PR only configures and advertises the tools. See Appendix E in docs/features/al-query-mcp-config-ui/design.md.

Test plan

• MCP Config Test (codeunit 130130): activation tests asserting the real EnableApiTools / EnableAlQueryTools field state; a Server Features TestPage set on page 8351 "MCP Config Card" (the list shows all three features in order, Configure is enabled only on Dynamic Tool Mode, activating Dynamic Tool Mode flips its row Status and sets EnableDynamicToolMode, and the part is hidden on the default configuration; API Tools is enabled before Dynamic Tool Mode so the gate is satisfied); TestLookupAPIObjects exercising the unified API lookup; and Export/Import round-trip tests asserting the two new fields survive.
• Manual walkthrough of the Server Features list / Configure / Activate-Deactivate cycle and the Select APIs lookup against a local BC instance.

Fixes AB#631012

🤖 Generated with Claude Code

[github-actions]

AL Documentation Audit

Documentation gaps were detected in the following apps:

• MCP-Test: 0% documentation coverage
• MCP: 67% documentation coverage

To generate documentation, run /al-docs init or /al-docs update using GitHub Copilot CLI or Claude Code.
This review is for awareness to help keep documentation in sync with code changes. It is okay to dismiss this request.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Performance} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

RefreshSubPages fires DB reads on every record navigation

RefreshSubPages() is called from OnAfterGetCurrRecord, which fires every time the user navigates to a different row on the configuration card. Each call invokes IsActive(ConfigId) for every feature enum value (currently 3 features), issuing at least 3 database reads per navigation. Users rapidly scrolling through configurations will trigger a burst of reads.

Recommendation:

• Move the full RefreshSubPages reload out of OnAfterGetCurrRecord and keep it only in OnAfterGetRecord (triggered once per record load) plus the specific OnValidate handlers that actually change feature state, rather than on every cursor movement.

trigger OnAfterGetRecord()
begin
    IsDefault := MCPConfigImplementation.IsDefaultConfiguration(Rec);
    RefreshSubPages();
end;

trigger OnAfterGetCurrRecord()
begin
    // do not reload sub-pages here; already handled in OnAfterGetRecord and OnValidate triggers
end;

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Upgrade} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Import allows inconsistent enableApiTools=false + enableDynamicToolMode=true

During ImportConfiguration, both EnableApiTools and EnableDynamicToolMode are written directly to the record before Insert(), with no cross-field validation. A JSON payload containing enableApiTools: false and enableDynamicToolMode: true will produce a configuration that violates the new invariant—Dynamic Tool Mode requires API Tools—without raising any error.

Recommendation:

• After reading all boolean flags from JSON and before MCPConfiguration.Insert(), add a consistency check: if EnableDynamicToolMode is true but EnableApiTools is false, either force EnableApiTools := true or throw an import error.

if MCPConfiguration.EnableDynamicToolMode and not MCPConfiguration.EnableApiTools then
    MCPConfiguration.EnableApiTools := true; // enforce prerequisite on import

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Upgrade} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Missing negative test for Dynamic Tool Mode + API Tools gate

The test TestEnableDynamicToolMode was updated to first enable API Tools before enabling Dynamic Tool Mode, ensuring the positive path succeeds. However, there is no test that verifies calling EnableDynamicToolMode(ConfigId, true) when API Tools is disabled raises APIToolsRequiredForDynamicErr. Without a negative test, a future regression removing or relocating the guard would go undetected.

Recommendation:

• Add a test procedure (e.g., TestEnableDynamicToolModeRequiresAPITools) that calls MCPConfig.EnableDynamicToolMode(ConfigId, true) on a config where API Tools is disabled and asserts that the expected error is thrown.

[Test]
procedure TestEnableDynamicToolModeRequiresAPITools()
var
    ConfigId: Guid;
begin
    ConfigId := CreateMCPConfig(false, false, true, false);
    // API Tools is off by default on new config
    asserterror MCPConfig.EnableDynamicToolMode(ConfigId, true);
    Assert.ExpectedError('API Tools must be enabled');
end;

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Security} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

ImportConfiguration assigns enableDynamicToolMode, discoverReadOnlyObjects, and enableApiTools directly from JSON and inserts the record without reusing the guard logic that enforces 'API Tools must be enabled before Dynamic Tool Mode'.

A crafted import file can therefore persist feature combinations that the interactive toggle flow rejects, weakening the configuration's access-control model. Validate imported feature flags through the same toggle procedures, or re-run the same invariants before insert, so imported configs cannot bypass those checks.

_{Agent judgement — not directly backed by a BCQuality knowledge article.}

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

Copilot PR Review

Iteration 3 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@be1b92b624679f8c031061602e7d3a3b5f71a688

Findings by domain

Findings split into Knowledge-backed (cite a BCQuality article) and Agent (the agent's own judgement, no matching BCQuality rule).

Domain	Findings	Knowledge-backed	Agent	Inline	Fallback
Other	1	1	0	0	1
Performance	1	1	0	0	0

Totals: 2 knowledge-backed · 0 agent findings.

Orchestrator pre-filter (16 file(s) excluded)

• layer-disabled (knowledge) : 16 file(s)

_{Findings produced by the Copilot CLI agent against BCQuality at be1b92b624679f8c031061602e7d3a3b5f71a688. Reply 👎 on any inline comment to flag false positives.}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Other} \quad \color{gray}{\texttt{\small Iteration\ 3}}$

ValidateAPIQueryTool only rejects Microsoft.API.V1 queries; beta query APIs still pass validation.

That means the new unified API-object lookup and Add APIs by API Group path can persist preview query endpoints even though the page flow explicitly filters beta APIs elsewhere. Reject beta query versions in query validation, and keep the selection filters aligned, so configurations cannot expose preview contracts unintentionally.

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[gggdttt]

🟡 Medium Severity — Upgrade Iteration 1

Missing negative test for Dynamic Tool Mode + API Tools gate

The test TestEnableDynamicToolMode was updated to first enable API Tools before enabling Dynamic Tool Mode, ensuring the positive path succeeds. However, there is no test that verifies calling EnableDynamicToolMode(ConfigId, true) when API Tools is disabled raises APIToolsRequiredForDynamicErr. Without a negative test, a future regression removing or relocating the guard would go undetected.

Recommendation:

• Add a test procedure (e.g., TestEnableDynamicToolModeRequiresAPITools) that calls MCPConfig.EnableDynamicToolMode(ConfigId, true) on a config where API Tools is disabled and asserts that the expected error is thrown.

[Test]
procedure TestEnableDynamicToolModeRequiresAPITools()
var
    ConfigId: Guid;
begin
    ConfigId := CreateMCPConfig(false, false, true, false);
    // API Tools is off by default on new config
    asserterror MCPConfig.EnableDynamicToolMode(ConfigId, true);
    Assert.ExpectedError('API Tools must be enabled');
end;

Line mapping was unavailable, so this was posted as an issue comment.

👍 useful · ❤️ especially valuable · 👎 wrong - reply with why

This one looks make sense. Should we consider it?