Skip to main content
Glama

wp_update_settings

Update a WordPress site's title, description, and admin email settings via the REST API to manage core configuration from MCP.

Instructions

Update WordPress site settings

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNo
emailNo
titleNo
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden and largely fails it. "Update" implies mutation, but there is no mention of required privileges (site settings typically need admin), whether omitted fields are preserved or reset, or whether the change is reversible. The only behavioral signal is the verb itself.

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

Conciseness3/5

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

The single sentence is front-loaded and free of filler, which is structurally fine. But its brevity here reflects under-specification rather than economy — the tool needs more content, not less.

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

Completeness2/5

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

For a mutation tool with four undocumented, all-optional parameters, no annotations, and no output schema, the definition is too thin. An agent has no way to know which settings are updatable, what values are valid, or what the call requires, so it would be guessing before invoking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for all four parameters (url, email, title, description), and the description adds nothing about their meaning, format, or effect. The agent cannot tell that these map to site title, admin email, tagline, and site URL, nor which are safe to send.

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

Purpose3/5

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

The description states a clear verb and resource ("Update WordPress site settings"), so the basic action is unambiguous. However, it never says which settings can be changed, and it does not distinguish itself from the sibling wp_get_settings (read counterpart) or clarify scope versus wp_update_user/wp_update_page. The name plus a generic sentence leaves the agent inferring the rest.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus wp_get_settings or the other wp_update_* siblings, and no prerequisites are stated. The agent must guess that this is the only route for site-wide settings.

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