Effective Permissions API

The effectivePermissions API page tells an MCP client what the signed-in user may do in Microsoft Dynamics 365 Business Central, before the client tries. It returns one row per API page in the environment, with the caller's verdicts for read, insert, modify, delete and execute. An MCP client such as the BC MCP Pro connector uses it to hide the tools a user may not use, with a single call instead of trying every page.

The page is read-only. It only reports: nothing it returns widens or narrows what a user can do. Business Central remains the enforcer.

The endpoint

GET https://api.businesscentral.dynamics.com/v2.0/{environment}/api/vangelderSolutions/mcpguard/v1.0/companies({companyId})/effectivePermissions

The page is MCP Guard Eff. Permissions (73633175). The user needs the permission set MCP GUARD - USER. To offer it to an MCP client, add the page to the MCP configuration with Allow Read turned on. See MCP Configurations.

The fields

Field	Meaning
`pageId`, `pageName`	The API page, for example `30009`, `APIV2 - Customers`.
`apiPublisher`, `apiGroup`, `apiVersion`, `entitySetName`	Where the page lives in the API.
`sourceTableId`, `sourceTableName`	The source table of the page.
`canRead`	Whether the user may read the source table. Permission sets, security groups and licence entitlements are included.
`canInsert`, `canModify`, `canDelete`	Whether the user's permission sets grant direct permission on the source table.
`canExecute`	Whether the user may execute the page itself. Without it every call fails, whatever the table permissions say.
`hasSecurityFilter`, `securityFilter`	Whether a security filter applies to the source table for this user, and which one.

The verdicts are calculated at the moment of the call, for the caller only. A user cannot read the verdicts of another user.

How the verdicts are decided

Read comes from Business Central itself, so it reflects everything Business Central applies to a read: permission sets, security groups and entitlements.

Insert, modify, delete and execute come from the permission sets assigned to the user in the current company. Only direct permission counts. Indirect permission does not count, because an API page performs the operation directly. A user with the SUPER permission set gets true for all of them.

The security filter is the filter on the user's read permission for the source table. When one of the user's permission sets grants the table without a filter, Business Central applies no filter, and the page reports none.

What the page cannot see

Licence entitlements for write operations. A licence can still block an insert that the permission set allows.
Tables that an API page reads in code besides its source table.
Filters that live in application code.

So canRead false and canExecute false are safe to act on: the MCP client can hide the tool. canRead true means that the source table is readable, not that every call will succeed. Treat the write verdicts as "the permission set allows it". When Business Central refuses a call, that refusal is final.

Cost