isWebMCP

Microsoft · Power Pages · Proposed scenario

Add evidence to an already-public Power Pages release

An illustrative pilot for a Power Pages engineering or reference-solutions team: review anonymous-page source and check supported fixes after release. Private sites remain private, and no Microsoft product integration is claimed.

Documented by the company

What the official sources establish

Our proposed workflow—not a deployed integration

  • A proposed owner is the Power Pages reference-solutions team, supported by a tenant administrator. Select an already-approved public reference site containing only synthetic content; do not expose a development tenant to make the scanner work.
  • Add a bounded source check after the existing deployment workflow. Save the page findings as a release artifact and route supported label or control issues to the page-template owner. Downloaded Power Pages YAML is not an input to our hosted URL scanner.
  • Let the owner review and publish its own fix, then repeat the same public URL, scanner model, and input context. Compare within that stable URL; separate environments or newly generated preview URLs need their own baselines.

What isWebMCP can provide now

  • Public, unauthenticated source findings; accessible-controls guidance; and SDK/CLI source comparisons. A team using GitHub Actions can adapt the existing CI example, subject to approved hosted-service access.
  • The MCP server can return a supported implementation recipe or compare supplied source summaries. It has no Dataverse privileges and cannot change a site or publish a Power Pages solution.

What needs development or agreement

  • Authenticated portal scans, private execution, Dataverse authorization evaluation, a native Power Platform adapter, and browser journey verification are not available. There is no enterprise SSO, tenant report history, or SLA commitment.

Proposed pilot · Not performed

A bounded way to test the hypothesis

Proposed two-week pilot: one already-public synthetic reference site, three named pages, a page-template engineer, and an administrator who approves scope and hosted data handling.

Deliverables to produce

  • A page inventory, one baseline per URL, an owner-reviewed remediation change, and comparable after-reports retained in the team release system.

Measures to collect—not results

  • Proposed acceptance: all three pages yield complete reports or an explicit unsupported outcome; supported changed pages retain compatible baselines and a documented disposition for every prioritized finding.
  • Measure initial setup time and whether the team voluntarily reuses the check on a second release. Zero visibility or permission changes is a mandatory boundary, not an achieved result.

Stop or decline if…

  • Stop if the target is private, requires session cookies, contains sensitive records, or needs tenant restrictions relaxed. Do not treat an inaccessible page as an agent-readiness failure.

Risks, constraints and unanswered questions

  • Anonymous HTML does not reveal authenticated forms, Dataverse permissions, or conditional interactions. Existing platform tooling may make the extra source check redundant; the pilot must establish incremental utility.

Source and date ledger

Research reviewed 2026-09-05. Dates describe the source, not a company trial. An unavailable publication date is left unknown.