mcp-creatio

Create or update a system operation

upsert-admin-operation

DestructiveIdempotent

Create or update a Creatio system administration operation by omitting id to create or supplying id to update, bypassing blocked generic write tools and returning the operation id.

Instructions

Create a system operation (SysAdminOperation) — omit id — or update one by id. The platform blocks the generic create/update tools for this table; reading it works with read. Returns the operation id. 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": {
      "name": "<name>",
      "code": "<code>"
    },
    "name": "upsert-admin-operation"
  }
}

Input Schema

Name	Required	Description
`id`	No	Id of the operation to update; omit to create a new one (its id is returned).
`code`	Yes	Unique code, PascalCase without spaces, e.g. "CanManageAdministration".
`name`	Yes	Name, e.g. "Can manage administration".
`description`	No	What the operation allows.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.8.0Oct 25, 2026

changedInput schema / properties / code / description

Previous value: -"Code of the system operation (e.g., \"CanManageAdministration\"). Required and must be unique. Conventionally PascalCase with no spaces."New value: +"Unique code, PascalCase without spaces, e.g. \"CanManageAdministration\"."

changedInput schema / properties / description / description

Previous value: -"Optional human-readable description of what the operation gates."New value: +"What the operation allows."

changedInput schema / properties / id / description

Previous value: -"Existing SysAdminOperation Id. Omit to create a new record (a new GUID is generated server-side and returned in the response)."New value: +"Id of the operation to update; omit to create a new one (its id is returned)."

changedInput schema / properties / name / description

Previous value: -"Display name of the system operation (e.g., \"Can manage administration\"). Required for both create and update."New value: +"Name, e.g. \"Can manage administration\"."

First observedv0.6.5Jun 28, 2026

TDQS

A4.2/5.0

Behavior3/5

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

The description adds useful context beyond annotations: the platform block on generic tools and the returned operation id. However, with destructiveHint=true and idempotentHint=true annotated, it never explains what is destructed on update or how omitted/optional fields (e.g. `description`) behave during an update. That leaves the main risk unaddressed.

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

Conciseness5/5

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

Three short sentences, front-loaded with the create/update rule, followed by the constraint that explains why this tool exists, then the return value and a pointer to the guide. Nothing is wasted.

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

Completeness4/5

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

With no output schema, the description correctly states it returns the operation id, and it explains why generic tools cannot be used. It is nearly complete; it only leaves unstated how an update treats omitted optional fields and any code-uniqueness failure behavior.

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%, so every parameter (including the omit-id semantics and code formatting) is already documented in the schema. The description restates the id-create/update rule but contributes no meaning beyond what the schema provides, making the baseline 3 appropriate.

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?

The description names the exact resource (SysAdminOperation) and states both the create path (omit id) and the update path (by id) in the first sentence. It also distinguishes itself from the generic create/update siblings and from read, so an agent can route without inspecting schemas.

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

Usage Guidelines5/5

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

It gives explicit conditions: omit `id` to create, supply `id` to update, use `read` for reading, and notes the generic create/update tools are blocked for this table. Those are the exact routing decisions an agent must make against the sibling list.

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