# Power Portals Pro (nuget · PowerPortalsPro.Mcp)

Component API, code samples and Dataverse metadata for building Power Portals Pro portals.

- Trust score: 70/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-21

## Components

- nuget · `PowerPortalsPro.Mcp`: 70/100 (this document), [markdown](https://verifymcp.io/servers/power-portals-pro-powerportalspro-mcp/powerportalspro-mcp.md), [page](https://verifymcp.io/servers/power-portals-pro-powerportalspro-mcp/powerportalspro-mcp)

## Channel facts

- Registry: `nuget`
- Package: `PowerPortalsPro.Mcp`
- Version: `9.0.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-21.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - No production dependencies, so there is no dependency health to assess.
- **Provenance & Transparency**: 32/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - License check failed: no license is declared.
  - Actively maintained (last published 2 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 73/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 11537 tokens (~180/item across 64 items; 64 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 20/100
  - Stability observed for 6 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 7 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 64 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the Power Portals Pro MCP server?

Power Portals Pro runs locally as a NuGet package, launched with dnx PowerPortalsPro.Mcp@9.0.0 --yes. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add power-portals-pro-powerportalspro-mcp -- dnx PowerPortalsPro.Mcp@9.0.0 --yes
```

### Cursor

```json
{
  "mcpServers": {
    "power-portals-pro-powerportalspro-mcp": {
      "command": "dnx",
      "args": [
        "PowerPortalsPro.Mcp@9.0.0",
        "--yes"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "power-portals-pro-powerportalspro-mcp": {
      "command": "dnx",
      "args": [
        "PowerPortalsPro.Mcp@9.0.0",
        "--yes"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add power-portals-pro-powerportalspro-mcp -- dnx PowerPortalsPro.Mcp@9.0.0 --yes
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "power-portals-pro-powerportalspro-mcp": {
      "type": "local",
      "command": [
        "dnx",
        "PowerPortalsPro.Mcp@9.0.0",
        "--yes"
      ],
      "enabled": true
    }
  }
}
```

### Hermes

```yaml
mcp_servers:
  power-portals-pro-powerportalspro-mcp:
    command: "dnx"
    args: ["PowerPortalsPro.Mcp@9.0.0", "--yes"]
```

### Netclaw

```json
{
  "McpServers": {
    "power-portals-pro-powerportalspro-mcp": {
      "Transport": "stdio",
      "Command": "dnx",
      "Arguments": [
        "PowerPortalsPro.Mcp@9.0.0",
        "--yes"
      ]
    }
  }
}
```

### Other

```json
{
  "mcpServers": {
    "power-portals-pro-powerportalspro-mcp": {
      "command": "dnx",
      "args": [
        "PowerPortalsPro.Mcp@9.0.0",
        "--yes"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-20 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-19 (score 69, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-09-18 (score 54, −14)

- [security regression] Malware scan: pass → unverified
- [functional regression] Schema quality: 10216 → 11537
- [functional improvement] Stability: unverified → 0.10
- [functional] Package version: 8.1.0 → 9.0.0

### 2026-09-16 (score 68, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-09-15 (score 53)

First indexed and scored.

## MCP tools (64)

### `read_records` (~280 tokens)

Read records from any table in the environment. Either name a `table` for a straight page of it, or pass `fetchXml` for anything more — filters, joins, ordering, aggregates. The FetchXML a saved view carries (from list_views) can be run verbatim, which is how you see the rows a portal grid will actually show. Use this to find out what real data looks like: the option-set value a row really carries, whether a lookup is populated, whether the record your code just wrote came out right. Reads as the connected service principal or user, NOT as a portal user — none of the portal's table, column or row security applies, so this cannot tell you what a given portal user would see. Read-only: there is no tool that creates, changes or deletes a business record.

Input parameters:

- `columns` (string|null): Comma-separated columns to return, e.g. "name,telephone1". Omit for every column.
- `fetchXml` (string|null): A FetchXML query to run verbatim. Takes precedence over `table`.
- `table` (string|null): Logical name of the table, e.g. "contact". Omit when passing fetchXml.
- `top` (integer): Maximum rows (1-250, default 20). Ignored when fetchXml sets its own count.

### `whats_new` (~96 tokens)

Return PowerPortalsPro release notes, newest first. Use it to check when a feature arrived or whether something changed behaviour, especially if the project's pinned version is older than this server's.

Input parameters:

- `limit` (integer): Maximum releases to return (1-10, default 3).
- `sinceVersion` (string|null): Only include releases after this version, e.g. "6.1". Omit for the most recent few.

### `update_portal_role_configuration` (~162 tokens)

Change how a role is handed to newly registered users: switch its assignment mode, replace its FetchXML criteria, or activate/deactivate the row. Only the arguments you pass are changed. Criteria is validated before writing, the same as on create. Assignment needs both this row and the role it names to be active.

Input parameters:

- `active` (boolean|null): true to activate, false to deactivate. Omit to leave the state alone.
- `assignmentMode` (string|null): New assignment mode: "automatic", "criteria" or "none".
- `criteria` (string|null): New FetchXML criteria, rooted in "contact". Pass an empty string to clear it.
- `roleName` (string, required): Name of the Portal Role whose configuration row should change.

### `list_portal_roles` (~102 tokens)

List the Portal Role records in the environment and the Portal Role Configuration rows that decide which of them newly registered users start with. Use it before writing an AddPortalRole call, so the code binds to a name that exists, and before creating a role, so an almost-identical duplicate isn't added. Shows each role's active state: an inactive role grants nothing and mints no claim. check_setup compares every role name the project's code uses with these records.

### `get_component_api` (~213 tokens)

Return the full API reference for a PowerPortalsPro component or type: every parameter and prop with its type, default, permitted values and description. This is the authoritative source — prefer it over recalling a parameter name, because the surface is large and changes between releases. Wide types are summarized; pass `filter` to search members by name or `section` to get one group in full.

Input parameters:

- `filter` (string|null): Only include members whose name or description contains this text. Use it to find a specific parameter on a wide component.
- `name` (string, required): Component or type name, e.g. "MainGrid", "TextEdit", "IPowerPortalsProService". An id from search_docs also works.
- `section` (string|null): Limit to one group: "parameters", "events", "properties", "methods" or "values".
- `stack` (string|null): Which stack's version to return: "blazor" or "react". Omit to see whichever exist.

### `update_portal_website` (~172 tokens)

Change a Power Portals Pro Website record: correct its URL, set a new licence key, or activate/deactivate it. Only the arguments you pass are changed. Deactivating has the same effect as deleting — every data endpoint on that host starts returning 402 — but is reversible, so prefer it. Licence key values are never read back, only written.

Input parameters:

- `active` (boolean|null): true to activate, false to deactivate. Omit to leave the state alone.
- `licenseKey` (string|null): A new licence key. Pass an empty string to clear it, which makes the check fail.
- `newUrl` (string|null): A corrected URL. The licence check matches this against the request's host.
- `url` (string, required): The current URL of the record to change.

### `get_conventions` (~92 tokens)

Return the PowerPortalsPro golden rules and conventions for a stack — the same guidance shipped as AGENTS.md in every generated project. Read this before writing PowerPortalsPro code for the first time in a session: it covers data access, localization, security filtering and the mistakes that are easy to make and hard to diagnose.

Input parameters:

- `stack` (string, required): Which stack: "blazor" or "react".

### `configure_app_service` (~162 tokens)

Apply the recommended platform settings to an existing web app: Always On, HTTPS only, HTTP/2, TLS 1.2 minimum, and the WebSockets and session-affinity pair that this project's stack needs. Use it after check_deployment reports a platform finding, or on an app that was created outside this server. The user is asked to confirm; the change restarts the app. Changes nothing that is already correct.

Input parameters:

- `confirm` (string|null): Required when the client cannot prompt the user: the exact app name, echoed back.
- `name` (string|null): The web app name. Omit to use the one recorded in this workspace's binding.
- `resourceGroup` (string|null): The resource group, when the name is ambiguous.

### `get_setup_script` (~542 tokens)

Generate a ready-to-run setup script for a new Power Portals Pro portal, with the supplied values filled in. Covers creating the project, registering both Entra apps (Dataverse connection and Microsoft sign-in), creating their secrets and writing them to user secrets, adding the Dataverse application user, provisioning an Azure Translator resource, and binding the folder. The script is written, NOT run — present it to the user to review and run themselves, because it creates real objects in their tenant, environment and subscription. It is safe to re-run and never prints a secret.

Input parameters:

- `dataverseRole` (string|null): Security role for the Dataverse application user. Defaults to 'System Administrator', because the script runs before the managed solution is imported and the narrower 'Power Portals Pro Application U…
- `enableEnhancedAuthorization` (boolean): Set false to turn off the Dataverse-native security model, which the template enables by default. When left on, supply websiteId.
- `environmentUrl` (string, required): Dataverse environment URL, e.g. 'https://contoso.crm.dynamics.com'.
- `interactivity` (string|null): Blazor render mode: 'Auto', 'Server' or 'WebAssembly'. Ignored for React. Defaults to Auto.
- `location` (string|null): Azure region for the Translator resource. Defaults to 'westus', which is the only region that works without also editing Program.cs.
- `projectName` (string, required): Name of the project and its solution folder, e.g. 'ContosoPortal'.
- `resourceGroup` (string|null): Azure resource group for the Translator resource. Defaults to '<project>-rg'.
- `shell` (string|null): Shell to target: 'powershell' or 'bash'. Defaults to powershell on Windows, bash elsewhere.
- `stack` (string|null): Which stack: 'blazor' or 'react'. Defaults to blazor.
- `steps` (string|null): Which steps to include, comma-separated, or omit for all. Ids: project, solution, dataverse-app, signin-app, translator, bind.
- `translationProvider` (string|null): Machine-translation provider: 'Azure', 'DeepL' or 'Google'. Only Azure can be scripted.
- `userAudience` (string|null): Who signs in: 'External', 'Internal' or 'Both'.
- `websiteId` (string|null): The powerpagesite record id, when enhanced authorization is on.

### `list_choices` (~90 tokens)

List the options of a Dataverse choice column, with their integer values and labels. Needed whenever you filter or compare on a choice — the stored value is the integer, and it is environment-specific for custom option sets.

Input parameters:

- `column` (string, required): The choice column's logical name, e.g. "statuscode".
- `table` (string, required): The table's logical name, e.g. "incident".

### `assign_application_user_role` (~131 tokens)

Give a Dataverse application user a security role. Use it when get_application_user shows the user exists but holds no role, or holds one too narrow for what the portal needs. Roles are additive — assigning one never takes another away. Needs System Administrator on the environment. The user is asked to confirm.

Input parameters:

- `clientId` (string, required): The Entra application (client) id.
- `confirm` (string|null): Required when the client cannot prompt the user: the client id, echoed back.
- `securityRole` (string, required): The security role's exact name. list_security_roles shows what exists.

### `add_app_registration_redirect_uri` (~196 tokens)

Add a reply URL to an existing app registration, keeping the ones already there. This is the step after a first deployment: the sign-in registration only knows the localhost URI until the production one is added, and sign-in fails with AADSTS50011 until it is. Pass the deployed URL and the callback path — for the templates' Microsoft sign-in that is /signin-microsoft. The user is asked to confirm.

Input parameters:

- `clientId` (string|null): The registration's client id. Preferred over the display name, which is not unique.
- `confirm` (string|null): Required when the client cannot prompt the user: the exact display name, echoed back.
- `displayName` (string|null): The registration's display name. Ignored when clientId is supplied.
- `redirectUri` (string): The full redirect URI, e.g. "https://myportal.azurewebsites.net/signin-microsoft".

### `remove_application_user_column_profile` (~142 tokens)

Take a Dataverse application user out of a column security profile. Unless it holds System Administrator or another profile covering the same columns, creating portal users starts failing immediately and password sign-in can no longer read stored hashes. Only a direct membership can be removed; a profile held through a team is changed on the team. Needs System Administrator on the environment. The user is asked to confirm.

Input parameters:

- `clientId` (string, required): The Entra application (client) id.
- `confirm` (string|null): Required when the client cannot prompt the user: the client id, echoed back.
- `profileName` (string, required): The column security profile's exact name.

### `list_portal_websites` (~79 tokens)

List the Power Portals Pro Website records that licence this environment's portals — the URL each one covers, whether a licence key is set, and whether the record is active. Use it when every data endpoint returns 402, which is what a missing or inactive record for the request's host looks like. Licence key values are never returned.

### `update_portal_role` (~201 tokens)

Change a Portal Role: rename it, set its description, or activate/deactivate it. Only the arguments you pass are changed. Deactivating is the safe way to switch a role off — an inactive role grants nothing and mints no claim, but its assignments survive, so reactivating restores everyone who held it. Renaming is the dangerous one: the name is the only thing joining the record to the AddPortalRole call, so renaming here without changing the code silently revokes the role from everybody holding it.

Input parameters:

- `active` (boolean|null): true to activate, false to deactivate. Omit to leave the state alone.
- `description` (string|null): A new description. Pass an empty string to clear it.
- `name` (string, required): The current name of the role to change.
- `newName` (string|null): A new name. Change the matching AddPortalRole call too, or the role stops granting anything.

### `create_key_vault` (~248 tokens)

Create an Azure Key Vault for this portal's secrets, grant the App Service's managed identity read access to it, and grant the signed-in user write access so secrets can be put in. Afterwards, the secret tools accept destination:"key-vault", which sends a newly minted client secret straight into the vault and leaves only a reference in the app settings. IMPORTANT: a Key Vault name is reserved for 90 days after deletion unless explicitly purged, so the name is the one thing here that is not cheaply undoable. Costs a fraction of a cent per thousand operations. The user is asked to confirm.

Input parameters:

- `appServiceName` (string|null): The web app whose identity gets read access. Omit to use the workspace binding's.
- `confirm` (string|null): Required when the client cannot prompt the user: the vault name, echoed back.
- `region` (string|null): Azure region. Defaults to the workspace binding's.
- `resourceGroup` (string|null): Resource group. Defaults to the workspace binding's.
- `vaultName` (string, required): The vault name. Globally unique across Azure, 3-24 characters, letters/digits/hyphens.

### `enable_managed_identity` (~256 tokens)

Give the App Service a managed identity, so it can authenticate as itself with no secret. PREFER passing managedIdentityId with a user-assigned identity from create_managed_identity: a user-assigned identity is a resource of its own that survives the app being rebuilt and is shared across deployment slots. Omitting it turns on the app's SYSTEM-assigned identity instead, which is created and destroyed with the app and differs per slot - so rebuilding the app mints a new identity and orphans the Dataverse application user and Key Vault grants built on the old one. Free, safe to re-run, and the app restarts. The user is asked to confirm.

Input parameters:

- `confirm` (string|null): Required when the client cannot prompt the user: the exact app name, echoed back.
- `managedIdentityId` (string|null): A user-assigned identity to attach: its name, or its full ARM resource id. Omit to turn on the app's own system-assigned identity, which is not recommended.
- `name` (string|null): The web app. Omit to use the one recorded in this workspace's binding.
- `resourceGroup` (string|null): The resource group, when the name is ambiguous.

### `create_portal_role_configuration` (~242 tokens)

Create a Portal Role Configuration row, which decides whether newly registered users are given a role as their account is created. Modes: "automatic" gives it to every new user; "criteria" gives it to those whose contact matches a FetchXML rule; "none" leaves the row dormant. Criteria FetchXML must be rooted in the contact table and must not be an aggregate — this tool checks that before writing, because the portal fails closed on bad criteria and a broken rule looks exactly like a rule that matched nobody. Safe to re-run: an existing row for that role is reported back rather than duplicated. The portal's Role Configuration page (/RoleConfigurationAdmin) edits the same rows, and in React builds the criteria visually and shows who it matches today.

Input parameters:

- `assignmentMode` (string|null): When to assign it: "automatic", "criteria" or "none". Defaults to "automatic".
- `criteria` (string|null): FetchXML rooted in "contact" describing who qualifies. Required for "criteria" mode.
- `roleName` (string, required): Name of the Portal Role to configure. It must already exist — use create_portal_role first.

### `list_app_services` (~90 tokens)

List the App Service web apps in the bound Azure subscription, with their host names and state. Use it to find the app a portal is deployed to when the user refers to it by a name you cannot map to a resource, or to confirm a name is free before creating one.

Input parameters:

- `resourceGroup` (string|null): Limit the listing to one resource group. Omit to list the whole subscription.

### `list_relationships` (~130 tokens)

List a Dataverse table's relationships by schema name. SubGrid takes a RelationshipName and ManyToManyLookupEdit takes an N:N one, and both must match exactly — call this rather than guessing the name from the table names.

Input parameters:

- `filter` (string|null): Only include relationships whose name or related table contains this text.
- `kind` (string|null): Restrict to "onetomany" (child records), "manytoone" (lookups on this table) or "manytomany".
- `table` (string, required): The table's logical name, e.g. "account".

### `get_deployment_plan` (~118 tokens)

The ordered steps to get this project running on Azure App Service, the plan tiers available with their real current prices, and the settings the portal will need. Needs no Azure sign-in, so it works before anything exists. Use it to answer 'how do I deploy this' and to tell the user what a given tier will cost before they commit to anything.

Input parameters:

- `region` (string|null): Azure region to price, e.g. "eastus" or "westeurope". Defaults to the workspace's region, then eastus.

### `add_app_registration_secret` (~322 tokens)

Add a new client secret to an existing app registration and write it to the project's user secrets or an App Service application setting. Use it to rotate before an expiry — client secrets last a year by default and the portal stops starting the day one lapses, with an error that does not mention Entra. Adding a secret does not revoke the old one, so the swap has no gap. The value is never returned. NOT idempotent: every call mints another secret. The user is asked to confirm.

Input parameters:

- `clientId` (string|null): The registration's client id. Preferred over the display name, which is not unique.
- `configurationKey` (string): The configuration key to store it under, e.g. "D365:ClientSecret" or "Authentication:Microsoft:ClientSecret".
- `confirm` (string|null): Required when the client cannot prompt the user: the exact display name, echoed back.
- `destination` (string): Where to put it: "user-secrets" (default), "app-service", "both", or "return" to have the value shown so you can paste it somewhere this server cannot reach.
- `displayName` (string|null): The registration's display name. Ignored when clientId is supplied.
- `expiryMonths` (integer): Months until it expires. Defaults to 24 (2 years), the longest Entra's portal offers. Graph has no ceiling, so up to 120 (10 years) is allowed — ask the user how long they want before going past 24.

### `search_docs` (~252 tokens)

Search PowerPortalsPro documentation, component API reference and code samples. Returns ranked results with an id and a short excerpt; pass an id to get_doc, get_component_api or get_example for the full content. Use this for open questions ("how do I filter a grid per user"). If you already know the component name, call get_component_api directly instead. Search in English: the documentation is English, so translate the user's question first if they asked in another language. Answer them in theirs — and note that component, parameter and column names are always English in code, whatever language the conversation is in.

Input parameters:

- `kind` (string|null): Restrict to one kind of result: "doc", "type" or "sample". Omit for all three.
- `limit` (integer): Maximum results (1-25, default 8).
- `query` (string, required): What to look for, in English. Component names, parameter names and plain questions all work.
- `stack` (string|null): Restrict to one UI stack: "blazor" or "react". Omit to search both. Results for the wrong stack are actively harmful, so set this whenever you know which stack the project uses.

### `list_security_roles` (~87 tokens)

List the Dataverse security roles available in the root business unit, so a role can be chosen by name before assigning it. Use it before create_dataverse_application_user or assign_application_user_role rather than guessing a name — role names vary between environments and an assignment silently does nothing if the name does not match.

Input parameters:

- `nameContains` (string|null): Only list roles whose name contains this.

### `assign_application_user_column_profile` (~226 tokens)

Add a Dataverse application user to a column security profile — by default the 'Power Portals Pro Application User' profile the managed solution ships. Any application user on a role narrower than System Administrator needs it: a security role can never grant a secured column, and the portal creates contacts and handles password hashes through two of them. Without it, creating a portal user fails with 'does not have create permissions to a … secured field' and password sign-in cannot read the stored hash. Works for any application user by client id — the app registration's, and the managed identity's a deployed app connects as. Needs System Administrator on the environment. The user is asked to confirm.

Input parameters:

- `clientId` (string, required): The Entra application (client) id — of the app registration, or of the managed identity a deployed app connects as.
- `confirm` (string|null): Required when the client cannot prompt the user: the client id, echoed back.
- `profileName` (string): The column security profile's exact name. Defaults to the one the managed solution ships.

### `get_page_recipe` (~127 tokens)

Return everything about one topic as a single coherent unit: the guide prose, the Blazor sample, the React sample and the API reference links. Prefer this over several separate calls when you are about to implement a feature — one complete working example beats three fragments you have to reassemble.

Input parameters:

- `stack` (string|null): Which stack's samples to include: "blazor" or "react". Omit for both.
- `topic` (string, required): Topic, component name or page route, in English, e.g. "MainGrid", "SubGrid", "grids/main-grid".

### `describe_role_table_privileges` (~143 tokens)

Show what a security role currently grants on one table, privilege by privilege, with the depth of each. Use it before add_table_privileges_to_role to see what is actually missing, and after a portal reports an empty grid or a failed save to find out whether the role is the reason. Depth matters as much as the privilege: an application user owns no records, so a privilege held at User depth grants it nothing at all.

Input parameters:

- `securityRole` (string, required): The security role's exact name. list_security_roles shows what exists.
- `table` (string, required): The table's logical name, e.g. "account". list_tables shows what exists.

### `create_signin_app_registration` (~585 tokens)

Create the Entra app registration behind 'Sign in with Microsoft' on the portal's login page, with the /signin-microsoft redirect URI filled in from the project's launchSettings (the templates randomise the local port, so there is nothing to guess), add a client secret, and write both into the project's user secrets or an App Service setting. This is a SECOND, SEPARATE registration from the Dataverse one — sharing one means a single secret rotation takes down both sign-in and data access, and gives the sign-in app a Dataverse role it never needed. The secret value is never returned. The user is asked to confirm.

Input parameters:

- `clientId` (string|null): The client id of an app registration that already exists. Supply it to add a secret and reply URLs to that one instead of creating anything.
- `confirm` (string|null): Required when the client cannot prompt the user: the exact display name, echoed back.
- `destination` (string): Where to put the credentials: "user-secrets" (default), "app-service", "both", or "return" to have the secret shown so you can paste it somewhere this server cannot reach.
- `displayName` (string|null): The exact display name to give the registration. Overrides portalName when supplied, and is also how an existing registration is found by name.
- `expiryMonths` (integer): Months until the client secret expires. Defaults to 24 (2 years), the longest Entra's portal offers, because the failure this causes in practice is a lapsed secret rather than a stolen one. Graph its…
- `portalName` (string): The portal's name, composed into the registration name as "<portalName> - Sign-in". Defaults to "Customer Portal"; a tenant with several portals should pass its own name so the two registrations read…
- `redirectUris` (array|null): Extra redirect URIs, e.g. "https://myportal.azurewebsites.net/signin-microsoft". The local one from launchSettings is added automatically, and any already on an existing registration are kept.
- `signInAudience` (string): Who may sign in: "AzureADandPersonalMicrosoftAccount" (any work or school account plus personal Microsoft accounts — the default, and what a portal for external users needs), "AzureADMultipleOrgs" (a…

### `set_app_service_settings` (~213 tokens)

Add or update application settings on a web app, merging with what is already there rather than replacing it. Use the double-underscore form of a configuration key — D365:ClientId becomes D365__ClientId — because the colon form does not work on Linux App Service. Prefer a Key Vault reference (@Microsoft.KeyVault(SecretUri=...)) over a literal for anything secret. The user is asked to confirm and is shown which names are being set, never their values. The app restarts.

Input parameters:

- `confirm` (string|null): Required when the client cannot prompt the user: the exact app name, echoed back.
- `name` (string|null): The web app name. Omit to use the one recorded in this workspace's binding.
- `resourceGroup` (string|null): The resource group, when the name is ambiguous.
- `settings` (object, required): The settings to set, as a JSON object of name to value, e.g. {"ASPNETCORE_ENVIRONMENT":"Production"}.

### `get_setup_plan` (~157 tokens)

Explain what has to exist before a Power Portals Pro portal will run: creating the project from the template, importing the managed Dataverse solution, registering the Entra app the portal connects to Dataverse as, registering the Entra app people sign in with, provisioning an Azure Translator resource, and binding the folder to an environment. Says what each step creates, which permissions it needs, and which configuration keys it produces. Use this to answer 'how do I set up a new portal'; use get_setup_script to turn it into commands.

Input parameters:

- `steps` (string|null): Which steps to explain, comma-separated, or omit for all of them. Ids: project, solution, dataverse-app, signin-app, translator, bind.

### `add_table_privileges_to_role` (~352 tokens)

Grant a security role privileges on one table. This is the step after installing the managed solution: the role that ships with PowerPortalsProCore covers the framework's own tables only, and the application user needs access to the consumer's tables too. This holds under both security models: impersonation intersects privileges rather than delegating them, so this role caps what every portal user can do. Purely additive — a privilege already held at an equal or deeper scope is left exactly as it is, and nothing is ever revoked. Safe to re-run. Cannot modify the role that ships in the managed solution: Dataverse permits it, but it is our component and an upgrade can reapply it. Needs System Administrator on the environment. The user is asked to confirm.

Input parameters:

- `confirm` (string|null): Required when the client cannot prompt the user: the role name, echoed back.
- `depth` (string): Basic, Local, Deep or Global. Defaults to Global, which is usually what an application user needs: it owns no records and belongs to no meaningful business unit, so the narrower depths grant it nothi…
- `privileges` (string): Comma-separated privileges: Create, Read, Write, Delete, Append, AppendTo, Assign, Share. "All" grants every privilege the table defines. Defaults to Read, which is the least that is ever useful — na…
- `securityRole` (string, required): The security role's exact name. list_security_roles shows what exists.
- `table` (string, required): The table's logical name, e.g. "account". list_tables shows what exists.

### `create_portal_website` (~138 tokens)

Create a Power Portals Pro Website record so a portal served from that URL passes the licence check. Without one, every data endpoint on that host returns 402. Safe to re-run: an existing record for the URL is reported back rather than duplicated, which matters because two records for one URL leave it undefined which answers the check.

Input parameters:

- `licenseKey` (string|null): The licence key for this website. It is stored and never read back by this server.
- `url` (string, required): The URL the portal is served from, e.g. "https://localhost:7273" or "https://portal.contoso.com".

### `create_dataverse_app_registration` (~456 tokens)

Create the Entra app registration the portal connects to Dataverse as, add a client secret, and write the client id and secret into the project's user secrets (or an App Service application setting). This is the backend identity for the client-credentials flow — no redirect URIs, no Graph permissions and no admin consent are needed or added. The secret value is never returned; only where it was stored and when it expires. Safe to re-run: an existing registration with that name is reused. The user is asked to confirm first. IMPORTANT: this is only half the setup — Dataverse also needs an application user for the client id, and the tool output says how.

Input parameters:

- `clientId` (string|null): The client id of an app registration that already exists. Supply it to add a secret to that one and write its credentials out, instead of creating anything.
- `confirm` (string|null): Required when the client cannot prompt the user: the exact display name, echoed back.
- `destination` (string): Where to put the credentials: "user-secrets" (default), "app-service", "both", or "return" to have the secret shown so you can paste it somewhere this server cannot reach.
- `displayName` (string|null): The exact display name to give the registration. Overrides portalName when supplied, and is also how an existing registration is found by name.
- `expiryMonths` (integer): Months until the client secret expires. Defaults to 24 (2 years), the longest Entra's portal offers, because the failure this causes in practice is a lapsed secret rather than a stolen one. Graph its…
- `portalName` (string): The portal's name, composed into the registration name as "<portalName> - Dataverse". Defaults to "Customer Portal"; a tenant with several portals should pass its own name so the two registrations re…

### `list_views` (~90 tokens)

List a Dataverse table's saved views WITH THEIR REAL GUIDs. MainGrid and SubGrid take view ids (DefaultViewId, ViewIds), and those ids exist only in this environment — they cannot be guessed or remembered. Always call this before writing a grid that binds to views, instead of leaving a placeholder.

Input parameters:

- `table` (string, required): The table's logical name, e.g. "contact".

### `dataverse_status` (~63 tokens)

Report which Dataverse environment this project folder is bound to, which account it connects as, and whether that connection currently works. Call this first if any other Dataverse tool reports it is not configured — it explains exactly what is missing and which command the user should run.

### `describe_table` (~141 tokens)

Describe a Dataverse table's columns, with the PowerPortalsPro editor each one maps to. Use this before writing a form or a grid: it gives you the exact column logical names and tells you whether a column needs a TextEdit, a LookupEdit, a ChoiceEdit and so on. Platform bookkeeping columns are hidden by default.

Input parameters:

- `filter` (string|null): Only include columns whose logical or display name contains this text.
- `includeSystem` (boolean): Include audit and ownership columns that are normally hidden. Default false.
- `table` (string, required): The table's logical name, e.g. "contact". Use list_tables if you are unsure.

### `get_upgrade_plan` (~193 tokens)

Plan an upgrade of this project from the PowerPortalsPro version it references to a newer one: which releases it crosses, every breaking change in them with its migration instructions, which files name a version that has to change (project files, package.json, and the server pin in .mcp.json), and the order to do it in. Call this before changing any version string — bumping the packages without the breaking changes produces build errors whose cause is several releases back. Writes nothing; install_solution upgrades the Dataverse side and the file edits are yours to make.

Input parameters:

- `fromVersion` (string|null): Version the project is on now. Omit to read it from the project's PackageReferences, which is normally right.
- `toVersion` (string|null): Version to upgrade to, e.g. "8.0" or "8.0.0.0". Omit for the newest published release.

### `create_portal_role` (~209 tokens)

Create a Portal Role record in Dataverse so an AddPortalRole registration has something to bind to. Give it the exact name used in code — the string is the only thing joining the two, and a mismatch produces a role that grants nothing with no error anywhere. Safe to re-run: a role of that name is reported back rather than duplicated, which matters because two roles of one name are indistinguishable to whoever assigns them. Creating the role does not give it to anybody — assign it to contacts in the model-driven app, or use create_portal_role_configuration to hand it to new users automatically. Administrators can also maintain roles, and the rules that hand them out, on the portal's Role Configuration page (/RoleConfigurationAdmin in both project templates).

Input parameters:

- `description` (string|null): Optional description, for whoever assigns the role in the model-driven app.
- `name` (string, required): The role name, matching the AddPortalRole call exactly, e.g. "Credit Manager".

### `check_deployment` (~195 tokens)

Compare what this project's portal needs against what its App Service actually has, and report what is wrong. This is the first thing to reach for when a deployed portal misbehaves: it catches the configuration keys that only ever existed in the developer's user secrets (the app then never starts), ASPNETCORE_ENVIRONMENT left on Development (a React portal's deep links redirect to localhost), WebSockets off on a Blazor Server portal (the circuit silently degrades to long polling), session affinity set wrong for the stack, and a Portal Website record whose URL does not match the host (every data endpoint returns 402 while the pages render perfectly). Read-only: it needs nothing but Reader and is safe against production.

Input parameters:

- `name` (string|null): The web app name. Omit to use the one recorded in this workspace's binding.
- `resourceGroup` (string|null): The resource group, when the name is ambiguous.

### `install_solution` (~248 tokens)

Download a Power Portals Pro managed solution and import it into the environment this folder is bound to. Installs PowerPortalsProCore by default, or PowerPortalsProLocalization, or PowerPortalsProEnhancedAuthorization (needs Power Pages installed); takes the latest release unless a version is given. This is how you provision the framework's tables and licence check on a new environment, and how you upgrade an existing one — a managed upgrade keeps data and customisations. The user is asked to confirm first and is shown which environment will change; where the client cannot prompt, pass the environment URL as `confirm`. The import runs in the background: this returns a job id, and get_solution_import_status reports progress. Imports take minutes.

Input parameters:

- `confirm` (string|null): The environment URL, required only when the client cannot prompt the user.
- `solution` (string|null): Solution unique name: "PowerPortalsProCore" (default), "PowerPortalsProLocalization" or "PowerPortalsProEnhancedAuthorization".
- `version` (string|null): Release version, e.g. "7.0.0.0" or "7.0". Omit for the latest.

### `azure_status` (~89 tokens)

Show which Azure subscription this folder deploys to, where that came from, and whether the saved sign-in still works. Call it first whenever an Azure tool reports that nothing is configured, and before suggesting the user run any `az` command — this server does not use the Azure CLI and does not read its logged-in state, so `az account show` says nothing about what these tools will do.

### `delete_portal_website` (~155 tokens)

Permanently delete a Power Portals Pro Website record. This takes the site's licence with it: from the next request, every data endpoint on that URL returns 402. Prefer update_portal_website with active:false, which does the same thing reversibly — deletion is only right for a record that was wrong to begin with, such as a typo'd URL or a duplicate. The user is asked to confirm; where the client cannot prompt, pass the record's exact URL as `confirm`. Never call this on your own initiative.

Input parameters:

- `confirm` (string|null): The record's exact URL, required only when the client cannot prompt the user.
- `url` (string, required): The URL of the record to delete.

### `delete_portal_role_configuration` (~132 tokens)

Permanently delete the Portal Role Configuration row for a role. The role itself and its existing assignments are untouched — this only stops the role being given to users who register from now on. Deactivating the row with update_portal_role_configuration has the same effect and is reversible. The user is asked to confirm; where the client cannot prompt, pass the role's exact name as `confirm`.

Input parameters:

- `confirm` (string|null): The role's exact name, required only when the client cannot prompt the user.
- `roleName` (string, required): Name of the Portal Role whose configuration row should be deleted.

### `list_email_queues` (~81 tokens)

List the Dataverse queues that have an email address, which are the ones usable as the portal's D365:EmailSenderEmailAddress. Use it to find an existing no-reply address before creating another, and to check that a queue's outgoing delivery method is set to actually send — a queue with outgoing delivery None accepts the email and delivers nothing.

### `get_doc` (~77 tokens)

Return one documentation section in full, by the id from search_docs (e.g. "grids/main-grid#views"). Passing a page id without the #fragment returns the whole page, which is longer — prefer the specific section.

Input parameters:

- `id` (string, required): Section id, or a bare page route to get every section of that page.

### `create_app_service` (~310 tokens)

Create the Azure resources a portal runs on: the resource group, an App Service plan and the web app, with the platform settings this project's stack needs (WebSockets and session affinity for a Blazor Server or Auto portal, affinity off for React or WebAssembly) already applied. The user is asked to confirm and is shown the plan's real monthly cost from Azure's price list before they answer; where the client cannot prompt, pass the app name as `confirm`. Safe to re-run — anything that already exists is reused rather than duplicated. Defaults to the cheapest tier that can stay warm, for every environment including production.

Input parameters:

- `confirm` (string|null): Required when the client cannot prompt the user: the exact app name, echoed back.
- `name` (string, required): The web app name. Becomes https://<name>.azurewebsites.net, so it must be globally unique.
- `region` (string|null): Azure region, e.g. "eastus". Defaults to the workspace binding's, then eastus.
- `resourceGroup` (string|null): Resource group to create the resources in. Defaults to the workspace binding's, then "<name>-rg".
- `sku` (string|null): Plan tier. Defaults to B1 — the cheapest tier with Always On — for every environment. Scale up later rather than starting high.
- `windows` (boolean): Create a Windows plan instead of Linux. Linux is the default: markedly cheaper per tier and no IIS in the request path.

### `list_app_registrations` (~132 tokens)

List the Entra app registrations in the signed-in tenant, with their client ids, redirect URIs and client-secret expiry dates. Use it to find an existing registration before creating a duplicate, to get the client id for a configuration value, and to answer 'why did the portal stop starting' — an expired client secret is the usual reason and the expiry dates are right here. Secret values are never returned; Entra does not store them in retrievable form either.

Input parameters:

- `nameStartsWith` (string|null): Only list registrations whose name starts with this. Omit to list the first 100.

### `remove_application_user_role` (~149 tokens)

Take a security role away from a Dataverse application user. The reason to reach for this is narrowing an application user that was given System Administrator to get things working — assign the narrower role first, then remove the broad one, so there is no window where the portal can do nothing. Removing the only role a user holds stops every Dataverse call it makes. Needs System Administrator on the environment. The user is asked to confirm.

Input parameters:

- `clientId` (string, required): The Entra application (client) id.
- `confirm` (string|null): Required when the client cannot prompt the user: the client id, echoed back.
- `securityRole` (string, required): The security role's exact name.

### `get_example` (~126 tokens)

Return a complete, working code sample verbatim from the PowerPortalsPro demo site. These compile and are current, so prefer adapting one over writing from scratch. Accepts a sample id from search_docs, or a component name to get that component's main example.

Input parameters:

- `name` (string, required): Sample id (e.g. "blazor:TextEditMainDemo") or a component name (e.g. "TextEdit").
- `stack` (string|null): Which stack's sample to return: "blazor" or "react". Omit to get both when both exist.

### `create_dataverse_application_user` (~216 tokens)

Create the Dataverse application user for an Entra app registration and give it a security role, in one step. This is the other half of create_dataverse_app_registration and nothing works without it — a registration on its own gets a token and is then refused by every Dataverse call. The Entra service principal must exist first, which create_dataverse_app_registration ensures. Safe to re-run: an existing application user is reused and an existing role assignment is left alone. Needs System Administrator on the environment. The user is asked to confirm.

Input parameters:

- `clientId` (string, required): The Entra application (client) id to create the user for.
- `confirm` (string|null): Required when the client cannot prompt the user: the client id, echoed back.
- `securityRole` (string|null): Security role to assign, e.g. "System Customizer". Use list_security_roles to see what exists. Omit to create the user with no role — it will be able to do nothing until one is assigned.

### `list_tables` (~96 tokens)

Find Dataverse tables in this project's environment by name. Returns logical names — the names you write in code — alongside display names. A search term is required: a real environment has over a thousand tables. Use this to confirm a table's logical name before writing it.

Input parameters:

- `search` (string, required): Text to match against the logical name, schema name or display name, e.g. "contact", "invoice", "ppp_".

### `get_record` (~129 tokens)

Read a single record by its id, from any table. Shows one column per line rather than a table, so a wide record stays readable — the shape you want when checking what a specific row actually contains. Reads as the connected service principal or user, NOT as a portal user, so none of the portal's own security applies. Read-only.

Input parameters:

- `columns` (string|null): Comma-separated columns to return. Omit for every column.
- `id` (string, required): The record's id (GUID).
- `table` (string, required): Logical name of the table, e.g. "account".

### `create_email_queue` (~271 tokens)

Create a Dataverse queue to act as the portal's no-reply email sender, for the address in D365:EmailSenderEmailAddress. This is the recommended sender for account-confirmation and password-reset mail: the address belongs to the portal rather than to a person, so no employee's name appears on automated messages, replies do not land in anybody's inbox, and nothing breaks when somebody leaves. Safe to re-run: an existing queue with that address is reported back rather than duplicated, since two queues sharing an address leave it undefined which one answers. The user is asked to confirm.

Input parameters:

- `confirm` (string|null): Required when the client cannot prompt the user: the email address, echoed back.
- `description` (string|null): Optional description recorded on the queue.
- `emailAddress` (string, required): The email address the portal will send from, e.g. "noreply@contoso.com". Must match D365:EmailSenderEmailAddress exactly.
- `name` (string): The queue's name, which becomes the sender's display name on the email. Defaults to "Portal No-Reply".
- `outgoingDeliveryMethod` (integer): Outgoing delivery method: 2 (server-side synchronisation, the default and the only value that actually sends) or 0 (none).

### `get_solution_import_status` (~100 tokens)

Check how a solution import started by install_solution is going. Returns whether it is still running, the percentage complete where Dataverse reports it, and the outcome with Dataverse's own message once it finishes. Imports take minutes, so poll this rather than waiting on the install call.

Input parameters:

- `asyncOperationId` (string, required): The async operation id returned by install_solution.
- `importJobId` (string, required): The import job id returned by install_solution.

### `delete_portal_role` (~153 tokens)

Permanently delete a Portal Role record, and with it every assignment of that role to a contact. Prefer update_portal_role with active:false — deactivating grants nothing and mints no claim either, but keeps the assignments so it can be reversed; deleting throws them away and nothing remembers who held it. The user is asked to confirm; where the client cannot prompt, pass the role's exact name as `confirm`. Show the user what will be lost before calling, and never call this to tidy up on your own initiative.

Input parameters:

- `confirm` (string|null): The role's exact name, required only when the client cannot prompt the user.
- `name` (string, required): Name of the role to delete.

### `create_managed_identity` (~245 tokens)

Create a user-assigned managed identity in Azure - an Entra identity that holds no secret and so has nothing to expire. It is a resource in its own right, which is the point: it survives the App Service being deleted and rebuilt, and is shared by every deployment slot, so the Dataverse application user and Key Vault grants built on it stay valid across a teardown. This only creates it; enable_managed_identity attaches it to an app. Free, and safe to re-run. Returns the identity's CLIENT id, which is what goes in D365:ManagedIdentityId and what a Dataverse application user must be created from - not the principal id, which is for Azure RBAC.

Input parameters:

- `confirm` (string|null): Required when the client cannot prompt the user: the identity name, echoed back.
- `identityName` (string|null): Name for the identity, e.g. "customer-portal-identity". Defaults to the bound app's name with "-identity" appended.
- `region` (string|null): Azure region. Defaults to the workspace binding's.
- `resourceGroup` (string|null): Resource group. Defaults to the workspace binding's.

### `find_parity` (~78 tokens)

Check whether a component or feature exists on both the Blazor and React stacks, and what differs. Use it before assuming a Blazor parameter has a React equivalent, or vice versa — the two stacks are close but not identical.

Input parameters:

- `component` (string, required): Component or feature name, e.g. "MainGrid", "GridTemplateColumn".

### `publish_customizations` (~146 tokens)

Publish all pending customizations in the environment, so changes made in the maker portal become live. Reach for this when the portal is serving stale metadata — a column you just added not appearing, a renamed label still showing the old text, a new option-set value missing from a choice. It is the same action as 'Publish all customizations' in the maker portal, so it publishes EVERYTHING pending in the environment, not only your own changes: on a shared development environment that can make a colleague's half-finished work live. Not needed after install_solution — importing a managed solution publishes what it brings. Safe to re-run, and on a large environment it can take several minutes.

### `get_application_user` (~135 tokens)

Show the Dataverse application user for an Entra client id, the security roles it holds, and its column security profiles. Call it whenever the portal authenticates but every Dataverse call is refused — either there is no application user for the client id, or there is one and it holds no role, and both look identical from the portal's side — and whenever creating a portal user fails with 'does not have create permissions to a … secured field', which means it holds a role but no profile covering the secured contact columns.

Input parameters:

- `clientId` (string, required): The Entra application (client) id the portal connects with.

### `describe_app_service` (~139 tokens)

Show one web app's platform configuration and the NAMES of its application settings. Values are never returned, except for a short list of documented non-secrets such as ASPNETCORE_ENVIRONMENT and D365__Url — a portal's settings hold the Dataverse client secret and every sign-in provider's secret, and those must not reach a transcript. Use check_deployment instead when the question is whether the app is correctly configured; this is for when you need the raw picture.

Input parameters:

- `name` (string, required): The web app name.
- `resourceGroup` (string|null): The resource group, when the name is ambiguous or the subscription is large.

### `list_solutions` (~118 tokens)

List the solutions installed in this environment and the Power Portals Pro releases available to install, so you can see whether the environment is behind. The framework needs PowerPortalsProCore; PowerPortalsProLocalization is optional and only backs the translation-memory features; PowerPortalsProEnhancedAuthorization is optional and assigns Power Pages web roles to new users on portals using enhanced authorization (it requires Power Pages in the environment). Use this before install_solution, and when a portal fails in ways that suggest missing tables or a 402 from every data endpoint.

### `deploy_to_app_service` (~191 tokens)

Build this project with `dotnet publish` and push the result to its App Service. On a React portal the publish also runs the Vite build and stages the SPA, so Node must be installed. The user is asked to confirm first — this replaces what is currently serving traffic. Deployment itself costs nothing beyond the plan that is already running.

Input parameters:

- `configuration` (string): Build configuration. Release unless you have a reason.
- `confirm` (string|null): Required when the client cannot prompt the user: the exact app name, echoed back.
- `name` (string|null): The web app name. Omit to use the one recorded in this workspace's binding.
- `projectPath` (string|null): Path to the web project (.csproj). Omit to find the single web project in the workspace.
- `resourceGroup` (string|null): The resource group, when the name is ambiguous.

### `check_setup` (~115 tokens)

Check what this project folder still needs before the portal will run: whether a project exists, which configuration keys its startup code requires, which of those are actually set, whether the Dataverse connection works, whether the managed solution that provisions the framework's own tables is installed, whether every portal role name the code uses has an active Portal Role record, and whether the folder is bound to an environment. Call this when a portal will not start, when every data endpoint returns 402, or when an assigned portal role appears to do nothing.

### `list_components` (~213 tokens)

Browse what PowerPortalsPro ships: components, hooks, enums, interfaces and options classes. Use it to discover whether something exists before writing it yourself. The catalog is large, so narrow with stack, kind, package or filter. Framework plumbing — abstract bases, query-builder internals, extension containers — is left out unless you ask for it.

Input parameters:

- `filter` (string|null): Only include types whose name or summary contains this text.
- `includeInternal` (boolean): Also list framework-internal types. Only useful when tracing how the framework itself is built; do not write new code against them.
- `kind` (string|null): Restrict to one kind: "component", "hook", "enum", "interface" or "class".
- `package` (string|null): Restrict to one package, e.g. "react-fluent" or "Web.Blazor.FluentUI". Substring match.
- `stack` (string|null): Restrict to one stack: "blazor" or "react".

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/power-portals-pro-powerportalspro-mcp/powerportalspro-mcp#diagnostics

## Score history

- 2026-09-21: 70
- 2026-09-20: 70
- 2026-09-19: 69
- 2026-09-18: 54
- 2026-09-17: 68
- 2026-09-16: 68
- 2026-09-15: 53

## Common questions

### What is the Power Portals Pro MCP server?

Power Portals Pro is an MCP server listed in the public MCP registry as io.github.Power-Portals-Pro/powerportalspro-mcp. Component API, code samples and Dataverse metadata for building Power Portals Pro portals. This page covers its NuGet package (PowerPortalsPro.Mcp).

### Is the Power Portals Pro MCP server safe to use?

Power Portals Pro scores 70 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Power Portals Pro MCP server expose?

Power Portals Pro exposes 64 tools: read_records, whats_new, update_portal_role_configuration, list_portal_roles, get_component_api, and 59 more. Their descriptions and schemas cost roughly 11,537 tokens of context every time the server is loaded.

### Is the Power Portals Pro MCP server still maintained?

Power Portals Pro is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- NuGet package: https://www.nuget.org/packages/PowerPortalsPro.Mcp
- Socket report: https://socket.dev/nuget/package/PowerPortalsPro.Mcp
- Repository: https://github.com/Power-Portals-Pro/PowerPortalsPro-Feedback
- Website: https://demo.powerportalspro.com/getting-started/mcp-server
- Changelog RSS feed: https://verifymcp.io/servers/power-portals-pro-powerportalspro-mcp/powerportalspro-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/power-portals-pro-powerportalspro-mcp/powerportalspro-mcp.json
- HTML version of this page: https://verifymcp.io/servers/power-portals-pro-powerportalspro-mcp/powerportalspro-mcp