Skip to main content
Glama
Sign In

uCoz

by io.github.ucoz-skills
OverviewDiscussionsAdmin

Change module settings

settings_write
Destructive

Changes the settings of a module of the active site: updates only the passed keys and reports which of them changed. A dry run returns the current values of the keys without saving.

Input Schema

NameRequiredDescriptionDefault
actionYesOperation to run. Each oneOf entry describes one action and lists its parameters.
moduleYesModule code. site holds the general site settings.
valuesYesFlat setting keys and new values, e.g. { "name": "News", "entries_per_page": 10, "comments_enabled": true }. A flat key joins the nested path with _ (cover.thumb_width -> cover_thumb_width); list fields such as fields are sent whole. Key names are 1-64 letters, digits or _; field names are described in the module OpenAPI specification (docs_tool).
confirmNoPass true only after the user approves this change. Required in some cases by: settings_update (see the action).
dry_runNoReturn the current values of the requested keys without saving.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / action / oneOf
      Previous value: -[
-  {
-    "const": "settings_update",
-    "description": "Changes only the passed keys of the settings of a module. The result lists changed keys (before and after) and unchanged keys: an unchanged key was unknown, already set, or clamped by the module; access keys are shown only as (set) or empty. confirm is required (not for a dry run) to turn on users reinstall_popup_templates or mass_mail, forum reset_visitor_record, site availability_closed, seo seo_DisableIndexing; to turn off users awards_enabled (deletes all awards), shop search_log_history (drops the search log), or options_other_categories of blog, news, board, publ, load, dir, stuff (removes entries from their additional categories); to change shop cart_invoice_next_number; and to pass users registration_allow_unet or registration_allow_local (can switch registration from uID to local users for good). These keys take a plain value, not an object or a list. A key passed both flat and nested is refused. Required: module, values. Optional: dry_run, confirm."
-  }
-]New value: +[
+  {
+    "const": "settings_update",
+    "description": "Changes only the passed keys of the settings of a module. The result lists changed keys (before and after) and unchanged keys: an unchanged key was unknown, already set, or clamped by the module; access keys are shown only as (set) or empty. warnings, when present, lists the passed values the module ignored. confirm is required (not for a dry run) to turn on users reinstall_popup_templates or mass_mail, forum reset_visitor_record, site availability_closed, seo seo_DisableIndexing; to turn off users awards_enabled (deletes all awards), shop search_log_history (drops the search log), or options_other_categories of blog, news, board, publ, load, dir, stuff (removes entries from their additional categories); to change shop cart_invoice_next_number; and to pass users registration_allow_unet or registration_allow_local (can switch registration from uID to local users for good). These keys take a plain value, not an object or a list. A key passed both flat and nested is refused. Required: module, values. Optional: dry_run, confirm."
+  }
+]
  2. Changed1 schema field changed
    • changedInput schema / required
      Previous value: -[
-  "action"
-]New value: +[
+  "action",
+  "module",
+  "values"
+]
  3. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is partly covered. The description adds genuinely new behavior: only passed keys are written, the response distinguishes changed from unchanged keys, and a dry run previews without saving. It stops short of stating that some changes require confirm or are irreversible, which lives in the action's schema text rather than the description.

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 sentences, front-loaded with the mutation semantics and followed by the dry-run caveat; no filler, no restatement of the title. Every clause carries information an agent needs.

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 multi-module mutation, the description covers purpose, partial-update scope, result reporting and dry-run preview, while the schema carries the heavy confirm/irreversibility details and annotations flag destructiveness. The one meaningful omission is that the description never signals "some keys require confirm and may destroy data" — an agent skimming only the prose would miss that before opening the action enum text.

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 every parameter carries a rich description, including the enum-constrained action with full confirm semantics and value-shape rules. The top-level description adds no parameter meaning beyond that (module, values, confirm and dry_run are untouched), 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?

States a specific verb and resource ("Changes the settings of a module of the active site") plus the key semantic detail that it is a partial update touching only passed keys. It does not explicitly name settings_read or modules_write as the counterpart, so sibling differentiation is left to the tool-name pairing rather than stated.

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 only implied: the dry_run sentence hints at a preview-then-commit workflow, and "reports which of them changed" implies verification use. There is no explicit when-to-use versus settings_read, no prerequisite guidance (e.g. needing module knowledge from modules_read or docs_tool), and no when-not guidance.

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

All uCoz toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources