Update permission group settings by ID to adjust access types, environment permissions, approval rules, and member capabilities. Use this endpoint to reconfigure roles without recreating groups.
This endpoint updates a Permission Group identified by the permissionGroupId parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | ||
| permissionGroupId | Yes | The identifier of the Permission Group. |
Changes observed during successful MCP inspections.
v0.1.9Input schema / properties / requestBody / properties / approvalPermissionTypeAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "cannotApprove",
+ "canApproveOthers",
+ "canBypassApproval",
+ "custom"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Represents the permission group level change request approval permission."
+}Input schema / properties / requestBody / properties / environmentApprovalPermissionsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "environmentApprovalPermissionType": {
+ "description": "Represents the environment specific change request approval permission.",
+ "enum": [
+ "cannotApprove",
+ "canApproveOthers",
+ "canBypassApproval"
+ ],
+ "type": "string"
+ },
+ "environmentId": {
+ "description": "Identifier of the Environment.",
+ "format": "uuid",
+ "type": "string"
+ }
+ },
+ "required": [
+ "environmentId",
+ "environmentApprovalPermissionType"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "List of environment specific change request approval permissions."
+}Input schema / properties / requestBody / properties / newEnvironmentApprovalPermissionTypeAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "cannotApprove",
+ "canApproveOthers",
+ "canBypassApproval"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Represents the environment specific change request approval permission."
+}Input schema / properties / requestBody / requiredRemoved value: -[
- "name",
- "canManageMembers",
- "canCreateOrUpdateConfig",
- "canDeleteConfig",
- "canCreateOrUpdateEnvironment",
- "canDeleteEnvironment",
- "canCreateOrUpdateSetting",
- "canTagSetting",
- "canDeleteSetting",
- "canCreateOrUpdateTag",
- "canDeleteTag",
- "canManageWebhook",
- "canUseExportImport",
- "canManageProductPreferences",
- "canManageIntegrations",
- "canViewSdkKey",
- "canRotateSdkKey",
- "canCreateOrUpdateSegments",
- "canDeleteSegments",
- "canViewProductAuditLog",
- "canViewProductStatistics",
- "canDisable2FA",
- "accessType",
- "newEnvironmentAccessType",
- "environmentAccesses"
-]v0.1.7Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it only says the endpoint 'updates' a group. It does not disclose whether this is a partial or full replacement, whether existing permissions are overwritten, whether null clears a value, required authorization, side effects, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and has no filler, making it easy to scan. However, it is so terse for a high-complexity update endpoint that it omits usage and behavior context, which costs it the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the rich request-body schema, the missing output schema and annotations leave the update semantics and return behavior unexplained. For a mutation endpoint with a large nested body, one sentence is not enough for an agent to know how the update behaves or what a successful call returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the schema: it restates that `permissionGroupId` identifies the group, which the schema already says, and it does not explain `requestBody` or the semantics of the many optional nested fields. With schema coverage at 50% and no compensation in prose, the request body parameter remains under-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('updates') and a clear resource ('Permission Group'), and identifies the target via `permissionGroupId`. It is distinguishable from get/create/delete siblings by the verb, though it does not explicitly differentiate itself from related update tools like update-member-permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to update a Permission Group versus creating, getting, or deleting one, nor any prerequisites or consequences. The sentence states the operation but leaves all selection context to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.