Skip to main content
Glama
Sign In

Frontman for WordPress

by io.github.frontman-ai
OverviewDiscussionsAdmin

wc_update_setting_option

Destructive

Updates one WooCommerce setting option. Ask the user for confirmation before calling with confirm=true. Mirrors woocommerce-mcp-server method update_setting_option using local WordPress authentication; no WooCommerce REST API keys are required.

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": {
      "site_id": "<site_id>",
      "group": "<group>",
      "id": "<id>",
      "settingData": "<settingData>",
      "confirm": "<confirm>"
    },
    "name": "wc_update_setting_option"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe WooCommerce setting ID.
groupYesThe WooCommerce setting group ID.
confirmYesMust be true only after the user explicitly confirms this WooCommerce mutation.
site_idYesThe connected site's id returned by list_sites. Call list_sites first; do not use a URL or WordPress post ID.
settingDataYesSetting fields to update.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already flag destructive=true, idempotent=false and openWorld=true, so the safety profile is covered. The description adds real value beyond that: an explicit human-confirmation protocol tied to the confirm flag, and the fact that it uses local WordPress authentication with no WooCommerce REST API keys required. It still does not say what happens to setting fields omitted from settingData, which matters for a destructive non-idempotent mutation.

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 sentences, front-loaded with the action, then the confirmation rule, then the auth note; nothing is padded. The implementation-mirroring clause is the weakest sentence but it justifies the no-API-keys claim.

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 mutation with full annotation coverage, a complete schema and no output schema, the definition covers what an agent most needs: confirmation gating and authentication model. The remaining gap is update semantics for settingData (merge vs replace, partial failure behavior), which is a meaningful but not fatal omission.

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 site_id, group, id and confirm is already documented in the schema, and the description adds no syntax, format, or merge-semantics detail for settingData. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

"Updates one WooCommerce setting option" states a specific verb and resource, and the singular "one" scopes the operation. It is clearly distinct from read siblings like wc_get_setting_options, but it does not explicitly distinguish itself from the near-identical wp_update_option, so the agent must infer which layer (WordPress option vs WooCommerce setting) applies.

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?

The description gives one concrete procedural rule: ask the user for confirmation before calling with confirm=true. That is genuine when-to-use guidance, but there is no guidance on when to prefer this over wp_update_option or the more specific wc_update_* tools, and no stated prerequisites beyond authentication.

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

All Frontman for WordPress 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