mcp-creatio

Read system settings

query-sys-settings

Read-only

Retrieve current values and metadata for Creatio system settings by their codes, including a list of codes that were not found.

Instructions

Current values and metadata of system settings by code. Response: the platform's answer — a success flag, a values map by code (each with its value) and notFoundSettings for unknown codes. See get-guide: sys-settings-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": {
      "sysSettingCodes": "<sysSettingCodes>"
    },
    "name": "query-sys-settings"
  }
}

Input Schema

Name	Required	Description	Default
`sysSettingCodes`	Yes	Setting codes to read, e.g. ["SiteUrl", "EmailDefSendName"].

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.0Oct 25, 2026

changedInput schema / properties / sysSettingCodes / description

Previous value: -"List of system setting codes to query. Provide at least one Creatio sys setting code (e.g., \"EmailDefSendName\", \"SupportEmail\")."New value: +"Setting codes to read, e.g. [\"SiteUrl\", \"EmailDefSendName\"]."

First observedv0.6.5Jun 28, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds concrete behavioral detail beyond that: the response has a success flag, a values map keyed by code, and notFoundSettings for unknown codes, which is especially valuable because no output schema exists.

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?

Two tight sentences front-load the purpose and then explain the return shape and guide reference. Every element earns its place, particularly the response details given the absence of an output schema.

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 simple one-parameter read tool with no output schema, the description supplies purpose, response structure, and unknown-code behavior, and points to a guide for deeper rules. It does not detail what metadata fields are returned, but overall it is complete enough to invoke correctly.

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?

There is one required parameter, sysSettingCodes, and schema description coverage is 100% with an example. The description reinforces code-based lookup and unknown-code handling but adds little syntax beyond what the schema already documents, so the baseline 3 applies.

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

Purpose4/5

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

The description names the resource (system settings), the lookup key (by code), and the returned values/metadata. It implicitly distinguishes this read operation from sibling mutations such as set-sys-settings-value and create-sys-setting, but does not explicitly name alternatives.

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: use it when you know setting codes and need current values. The pointer to get-guide: sys-settings-guide adds some routing context, but there is no explicit when-to-use/when-not-to-use guidance or named alternative.

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