mcp-creatio

Call a configuration service

call-configuration-service

Destructive

Call any Creatio configuration-package REST method by service and method when no dedicated tool covers the task; use it for uncovered operations and expect possible data changes.

Instructions

Escape hatch: call any configuration-package REST method (/0/rest//) when no dedicated tool covers the task — those validate input and explain their effects, so prefer them. The method may change data. Response: { status, contentType, body } (JSON parsed).

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": {
      "service": "<service>",
      "method": "<method>"
    },
    "name": "call-configuration-service"
  }
}

Input Schema

Name	Required	Description	Default
`body`	No	JSON body for POST/PATCH/PUT: the method's parameters as top-level keys, e.g. { "operation": "CanManageAdministration" }.
`query`	No	Query-string parameters.
`method`	Yes	Method name, e.g. "GetCanExecuteOperation".
`service`	Yes	Service name, e.g. "RightsService" (called at /0/rest/<service>/<method>).
`httpMethod`	No	HTTP method; most Creatio configuration services use POST.	POST

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.8.0Oct 25, 2026

changedInput schema / properties / body / description

Previous value: -"Request body sent as JSON for POST/PATCH/PUT. Ignored for GET/DELETE. Pass the service parameters as a flat object (e.g., {\"recordId\":\"<guid>\",\"name\":\"...\"}). Creatio configuration services use [WebInvoke BodyStyle=Wrapped], so each parameter becomes a top-level key."New value: +"JSON body for POST/PATCH/PUT: the method's parameters as top-level keys, e.g. { \"operation\": \"CanManageAdministration\" }."

changedInput schema / properties / httpMethod / description

Previous value: -"HTTP method. Most Creatio configuration services use POST."New value: +"HTTP method; most Creatio configuration services use POST."

changedInput schema / properties / method / description

Previous value: -"Service method name (UriTemplate) to invoke (e.g., \"UpsertAdminOperation\")."New value: +"Method name, e.g. \"GetCanExecuteOperation\"."

removedInput schema / properties / query / additionalProperties / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  }
-]

addedInput schema / properties / query / additionalProperties / type
```
Added value: +[
+  "string",
+  "number",
+  "boolean"
+]
```

changedInput schema / properties / query / description

Previous value: -"Optional query-string parameters appended to the URL."New value: +"Query-string parameters."

changedInput schema / properties / service / description

Previous value: -"Configuration service name as registered in Creatio (e.g., \"RightsService\"). The full URL is /0/rest/<service>/<method>."New value: +"Service name, e.g. \"RightsService\" (called at /0/rest/<service>/<method>)."

First observedv0.6.5Jun 28, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description reinforces this with 'the method may change data' and supplies the otherwise-undocumented response shape { status, contentType, body } with JSON parsing, which has real value given there is no output schema. It could go further on auth requirements or failure modes, so not a 5.

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, escape-hatch framing and the preference rule front-loaded, then behavior, then return shape. No filler and no repetition of schema fields.

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?

For a destructive, no-output-schema raw-dispatch tool, the description covers purpose, safety warning, and response format. The notable gap is discovery: it never says how an agent should find valid service/method names, which matters a lot for an escape hatch.

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%, including the route pattern, body-as-top-level-keys convention, and the httpMethod default note, so the schema already carries most semantic weight. The description adds only the route form, which duplicates the service parameter's own description; baseline 3 applies.

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?

Names the resource and the exact route pattern (/0/rest/<service>/<method>) and frames the tool explicitly as an escape hatch. This makes it instantly distinguishable from the dedicated CRUD/settings tools in the sibling list.

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?

States the selection rule directly: use only when no dedicated tool covers the task, and prefer dedicated tools because they validate input and explain effects. That is an explicit when-to-use plus a named alternative class.

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