The associated AI at Work roadmap entry, 577813, lists the feature as In development, with public preview dated January 2026 and general availability targeted for January 2027. Those dates need careful interpretation: January 2026 is already past, while January 2027 remains a future target. The preview field is not, by itself, proof that every eligible environment has access. Microsoft explicitly describes its roadmap dates and feature descriptions as estimates subject to change.
What the MCP server changes
Microsoft describes the Model Context Protocol interface as a standardized way to expose Power Pages data, APIs, and business logic to compatible AI clients. Its documentation specifically identifies Microsoft 365 Copilot and internal staff performing portal operations without navigating the portal interface as supported scenarios.
The roadmap’s preview description is narrower and more concrete than that broad architectural promise: makers can enable CRUD operations through the Power Pages Web API layer without writing custom code, and provision the MCP endpoint through site settings.
The practical distinction is important. This is not merely another way to search site content. The documented interface supports operations that can alter records. That makes permission design part of the deployment decision, not housekeeping to be postponed until after the demonstration. Microsoft says the interface respects the site’s existing authorization boundaries.
“No custom code” still means configuration
Microsoft’s implementation documentation supplies a useful qualification to the roadmap’s low-code message: enabling the server is only one part of establishing a working connection.
The identity setup supports Microsoft Entra ID or Microsoft Entra External ID. Prerequisites include a functional Power Pages site, maker or administrator access, an MCP-compatible client, and permission to create app registrations in Microsoft Entra. The configuration includes exposing an MCP scope, registering a client application, assigning delegated permissions, and granting tenant administrator consent.
Site configuration then connects those identity details to Power Pages. Microsoft documents bearer authentication, OpenID Connect settings, a client ID, the MCP scope, and the MCP/Enabled setting with a value of true. The scope configuration must include the full MCP scope URI together with openid and profile, separated by spaces. Provider-specific settings differ between Entra ID and External ID.
The takeaway: no-code enablement does not mean no identity engineering. An endpoint switch cannot substitute for a correctly configured application, authentication flow, and permission model.
The documented Microsoft 365 Copilot path
Microsoft’s client-connection guide describes an agent built in Copilot Studio and published to Microsoft 365 Copilot. Its deployment sequence covers:
- Adding an MCP tool with the Power Pages server endpoint.
- Configuring OAuth 2.0 using the application’s client ID, secret, endpoints, and scopes.
- Registering the generated redirect URI in Entra.
- Creating a connection, publishing and sharing the agent, and adding the Teams and Microsoft 365 Copilot channel.
For this documented route, end users need a valid Microsoft 365 Copilot license and access to the agent. First-time users also establish their own connection through Connection Manager; after authentication succeeds, they return to the conversation and retry their query. A chat window alone is not the entire access setup.
This is a meaningful boundary on the roadmap’s reference to popular AI chat clients. Microsoft describes a standardized interface, but its published Microsoft 365 deployment still requires explicit client authentication and user access configuration.
What administrators should assess first
The sensible evaluation question is not simply, “Can the agent update a record?” It is, “Which records should this user be allowed to update through this agent?”
As an operational recommendation, start with a limited test workflow and verify both permitted and denied operations before expanding access. Treat create, update, and delete permissions separately rather than assuming every conversational workflow needs all three. These are deployment precautions, not claims that Microsoft provides an additional approval mechanism.
Microsoft also identifies several concrete configuration checks when the server does not function: site-setting names are case-sensitive, the client ID must match the app registration, all three required scopes must be present, and Boolean values must be entered correctly. Its guide warns that incorrect names or values can prevent operation.
Power Pages MCP therefore offers a useful change in how users reach business data, rather than a replacement for the controls governing that data. The opportunity is fewer trips through portal screens. The responsibility is making sure the conversational shortcut leads only where the user is authorized to go.