Update an allowed public setting
Option writes are the most tightly restricted category in the server. Only five options can be written, and everything else is refused — including anything that looks like a credential.
The five writable options
| Option | What it is |
|---|---|
blogname |
The site title |
blogdescription |
The tagline |
posts_per_page |
How many posts a listing shows |
date_format |
The date display format |
time_format |
The time display format |
That is the complete list. It exists because these are presentational settings with a bounded blast radius, and because an assistant able to write arbitrary options could change almost anything about a WordPress site.
A developer can extend the list through a filter, which is a deliberate decision to widen it for a specific installation rather than something to do casually.
Its own gate
Option writes are governed by Allow option writes, separate from Allow content writes. Opening the content gate does not permit option writes.
The separation is the point: editing posts is routine, changing site-wide settings is not.
What is always refused
Regardless of the allowlist, some options can never be written: the site and home URLs, the database version, user roles, cron, rewrite rules, the site language, the active theme and plugins, and POM AI's own settings and keys.
Anything whose name looks like a credential is also refused — names containing secret, salt, auth key, nonce key, license key, api key, auth token, private key, session token or recovery key.
So the option tools cannot be used to read or write credentials out of the database, which is the main reason to be comfortable with them existing at all.
Reading options
wp_get_option reads a single permitted public option. Generic plugin-option dumps are unavailable. For POM Theme, use the settings catalog and typed field contracts.
Reading is governed by the content read scope, not the option write gate.
The workflow
1. Read the current value.
Show me the current site tagline.
2. Use a dry run.
wp_update_option supports dry_run, which returns the before and after without writing:
Use a dry run to change the tagline to "Industrial automation for growing manufacturers" and show me the result.
3. Write, then read back.
Apply it, then read the option back.
4. Check the site. The tagline appears in the header, the browser title and often in search results. Look at the rendered page rather than only the stored value.
5. Purge the cache. These options appear on every page.
Which of the five deserve most care
blogname and blogdescription appear in page titles, feeds, emails sent by WordPress, and search engine results. Changing them is a small edit with a wide surface.
posts_per_page changes pagination across every archive. Set it too low and you create hundreds of pages of pagination; too high and archive pages become slow. Check an archive page afterwards.
date_format and time_format change every displayed date on the site. Confirm the result matches the locale conventions your audience expects — a format that reads correctly to you may not to them.
When a write is refused
| Message | Meaning |
|---|---|
| The write group is disabled in POM AI MCP settings | Allow option writes is closed |
pom_ai_mcp_option_denied |
The option is not on the writable list, or is denied outright |
pom_ai_mcp_forbidden |
The acting user lacks the capability |
A refusal here is usually correct behaviour rather than a problem to work around. If an assistant needs to change an option that is not on the list, that is a task for a person in the WordPress admin.
Related
- Site and menu tools
- Configure POM Theme settings for theme options, which are separate
- MCP boundaries