mcp-creatio

Grant or deny a system operation

set-admin-operation-grantee

DestructiveIdempotent

Grant or deny a system operation to specified users or roles; repeating the same operation and grantee updates the existing permission instead of adding another.

Instructions

Allow or deny a system operation for users/roles. Repeating it for the same operation and user/role updates the existing grant instead of adding another. See get-guide: admin-operation-guide.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "adminOperationId": "<adminOperationId>",
      "adminUnitIds": "<adminUnitIds>",
      "canExecute": "<canExecute>"
    },
    "name": "set-admin-operation-grantee"
  }
}

Input Schema

Name	Required	Description
`canExecute`	Yes	true grants (allow), false denies.
`adminUnitIds`	Yes	Users or roles to grant/deny — SysAdminUnit ids (read SysAdminUnit by Name), not contact ids.
`adminOperationId`	Yes	Id of the system operation (read SysAdminOperation by Code).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.8.0Oct 25, 2026

changedInput schema / properties / adminOperationId / description

Previous value: -"Id of the SysAdminOperation being granted or revoked. Look up via `read` on `SysAdminOperation` filtered by Code."New value: +"Id of the system operation (read SysAdminOperation by Code)."

changedInput schema / properties / adminUnitIds / description

Previous value: -"SysAdminUnit Ids (users or roles) that should receive the same grant/revoke state. Resolve via `read` on `SysAdminUnit` filtered by Name. Use SysAdminUnit.Id (NOT ContactId)."New value: +"Users or roles to grant/deny — SysAdminUnit ids (read SysAdminUnit by Name), not contact ids."

changedInput schema / properties / canExecute / description

Previous value: -"`true` grants the operation (allow) to every listed admin unit; `false` revokes it (deny)."New value: +"true grants (allow), false denies."

First observedv0.6.5Jun 28, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety and repeat-behavior profile is structured data. The description's upsert sentence ('repeating ... updates the existing grant instead of adding another') mostly restates idempotentHint, though it usefully frames it as an upsert rather than an append. It adds nothing about what a deny does to an existing allow, or about partial failures across multiple adminUnitIds.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, followed by the repeat-behavior and the guide pointer. Efficient overall; the guide reference is the only line that does not carry direct instruction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool whose safety profile is covered by annotations and whose three params are fully documented by the schema, so the essentials are present. Gaps remain around effect semantics (does deny remove an existing grant? what happens with multiple adminUnitIds?) and return value, since there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema itself explains canExecute semantics, the SysAdminUnit id requirement, and the SysAdminOperation lookup by Code. The description adds no parameter-level meaning beyond that, which is the correct baseline-3 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair (allow/deny) and resource (system operation) plus the target scope (users/roles). Combined with the name, an agent can distinguish this from delete-admin-operation-grantee (revoke) and upsert-admin-operation (define the operation itself) without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'allow or deny' and the negation pointer to the guide, but no sibling is named and no condition is given for when to use this instead of delete-admin-operation-grantee. The get-guide reference defers guidance rather than providing it inline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.