[MCP] Add codeunit APIs as MCP tools in MCP configuration

[Onat Buyukakkus (onbuyuka)]

Fixes AB#643238

Summary

Adds Codeunit as a new object type in the MCP configuration UI, at parity with API pages and queries, and sources all API metadata from the Api Web Service table.

• Unified Select APIs lookup lists API pages, queries and codeunits together. Opening the lookup from a tool row's Object Id field filters to that row's object type; the Select APIs action stays unfiltered.
• Add APIs by API Group and Add all standard APIs work across pages, queries and codeunits.
• New public facade CreateCodeunitAPITool; GetAPIToolId object type extended to Codeunit.
• Permission model: renamed Allow Bound Actions -> Allow Actions (page caption + facade AllowActions, with AllowBoundActions deprecated behind #if not CLEAN29). For codeunit tools Allow Actions is the invoke toggle; Read/Create/Modify/Delete are not applicable.
• Missing-object / missing-parent warnings, export/import, upgrade and version handling updated for codeunits.
• API Overview page (812) now lists API pages, queries and codeunits, all sourced from the same Api Web Service table. Because each codeunit procedure has its own endpoint, no single object URL is shown for codeunit rows.

Metadata source: Api Web Service

API metadata for all three object types now comes from the Api Web Service table, replacing the separate Page Metadata, Query Metadata and CodeUnit Metadata lookups in both the MCP configuration and the API Overview page:

• A single source keyed by Object Type + Object ID, exposing Publisher / Group / Version, Service Name (entity set name), ObjectName, ALNamespace, and the InsertAllowed / ModifyAllowed / DeleteAllowed capability flags.
• Only published APIs are listed.
• The table holds one row per API version; consumers aggregate versions per object (the MCP selection applies the highest version when a tool is created).
• V1 APIs (Microsoft.API.V1) and the Base Application beta customer/vendor queries (5480/5481) remain excluded from the MCP selection.

This removes the previous codeunit-specific handling (namespace matching, regex-derived entity names and fixed microsoft/codeunits/beta values); codeunits now carry their real publisher, group, version and entity name, and page create/modify/delete editability reads the capability flags directly.

API Overview page (812)

The API Overview page now uses Api Web Service as its single source for all object types, so pages and queries are no longer read from Page Metadata / Query Metadata (and codeunits no longer use the interim CodeUnit Metadata namespace match). A shared AddAPIObjects helper enumerates the published web services per object type, and an object published under several versions is listed once with its versions aggregated.

• The page lists all published API pages, queries and codeunits. It is intentionally comprehensive and does not apply the MCP-specific V1 / 5480-5481 exclusions.
• The Entity column now shows the entity set name from Api Web Service Service Name (e.g. postedSalesInvoices) - the value that appears in the API URL - instead of the singular EntityName previously read from metadata.

Beta APIs

Microsoft and standard beta pages (publisher microsoft or empty) are excluded from the selection lookup, bulk add, the publisher list and the version picker. Third-party beta pages stay available. Beta queries and codeunits are unaffected.

Test plan

• Codeunit permission tests (TestCodeunitToolDoesNotAllowRead/Create/Modify/Delete, TestCodeunitToolAllowsActions) plus a CreateMCPCodeunitConfigTool helper.
• Existing bound-actions tests renamed to AllowActions.
• Updated the MCP test library LookupAPIObjects wrapper and the GetHighestAPIPageVersion helper (now takes an object id) for the new signatures.
• API Overview tests updated for the Api Web Service source: TestAPIOverviewIncludesKnownAPIPage now asserts the entity set name (postedSalesInvoices), and TestAPIOverviewListsEveryAPIPage counts distinct published API pages from Api Web Service.

[Divyanshu Kapoor (divyanshukapoor)]

MCPConfigImplementation.Codeunit.al — line 739 (IsMicrosoftBetaAPI)

Behavior change worth confirming (non-blocking). IsMicrosoftBetaAPI only classifies a beta row as beta when the publisher is microsoft or empty, and ExcludeMicrosoftBeta is passed true only for pages (queries/codeunits pass false). Net effect vs. the old APIVersion <> 'beta' filter: non-Microsoft (partner) beta API pages are now surfaced in the picker, and Microsoft v2.0+beta pages now show only v2.0

[Divyanshu Kapoor (divyanshukapoor)]

. MCPConfigToolList.Page.al — line 229 (SetPermissions)

Nit (non-blocking). SetPermissions() always filters Object Type::Page, but it runs for Query/Codeunit rows too. If a Query/Codeunit Object Id coincides with a published API page's Object ID, it reads that page's Insert/Modify/Delete Allowed into the editability flags. Harmless today (those fields' Editable also require Object Type = Page), but fragile — consider an early if Rec."Object Type" <> Rec."Object Type"::Page then exit; after clearing the flags.

[Divyanshu Kapoor (divyanshukapoor)]

MCPUpgrade.Codeunit.al — line 36 (IsAPIPage)

Confirm ordering (non-blocking). This upgrade path depends on IsAPIPage(), which queries Api Web Service with Published = true. Please confirm the upgrade runs after web services are registered/published — otherwise IsAPIPage returns false for real API pages and API Version won't be back-filled. Same dependency applies to MCPConfigMissingParent line 38.

[Divyanshu Kapoor (divyanshukapoor)]

The facade/caption were renamed Page→"Allow Actions", but the backing table field remains "Allow Bound Actions" and is now reused as the invoke toggle for codeunit tools — whose endpoints this PR explicitly documents as unbound actions (see the APIOverview GetApiUrl comment "one endpoint per procedure (unbound action)"). The persisted field name is now semantically inaccurate for codeunit rows.

[Divyanshu Kapoor (divyanshukapoor)]

The new permission tests insert an MCP Configuration Tool directly with a random Object Id, bypassing CreateCodeunitAPITool / ValidateAPICodeunitTool. So the new public facade CreateCodeunitAPITool and its guards (CodeunitNotFoundErr, InvalidCodeunitTypeErr) are untested — the only genuinely new creation logic in the PR has no test asserting it rejects a non-existent codeunit or a non-API codeunit, nor that it stamps the highest codeunit version.
Fix: Add tests: (1) CreateCodeunitAPITool on a real API codeunit succeeds and sets "Allow Bound Actions" + "API Version"; (2) it errors on a missing codeunit and on a non-API codeunit; mirror the existing page/query validation tests.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The lookup coverage still exercises only the unfiltered path. TestLookupAPIObjects calls the test-library helper with TypeFilter = false, so the new filtered lookup branch used from the Object ID lookup is never verified. A regression that lets a page row pick a query/codeunit (or vice versa) would still leave this suite green. Add a test that drives the lookup with TypeFilter = true and asserts the selected object type matches the current row.

_{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 · AL review agent v1.34.4}