wpxmcp

Update a block template

update_template

Change a WordPress block template's content site-wide, storing modifications in the database without altering theme files. Revert via the Site Editor.

Instructions

Update a block template or template part's markup. This changes the layout of every page that uses it, so it takes effect site-wide immediately. WordPress stores the customisation in the database, leaving the theme's own file untouched — you can always revert in the Site Editor.

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": {
      "id": "<id>",
      "content": "<content>"
    },
    "name": "update_template"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Template id, e.g. "twentytwentyfour//single".
`kind`	No	Whether the id names a template or a template part.	template
`title`	No	New template title.
`content`	Yes	Full block markup for the template.
`site_id`	No	Which configured WordPress site to act on. Optional — with a single site configured it is used automatically; with several, the default site is used unless you name one. Run list_sites for valid ids.
`description`	No	New template description.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.0.0Sep 15, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

First observedv1.0.0Aug 24, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds materially beyond annotations: the site-wide immediate effect on every page using the template, storage in the database rather than the theme file, and reversibility in the Site Editor. These consequences align with readOnlyHint=false and explain why destructiveHint=false holds (revertible). No contradiction.

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?

Three sentences, each earning its place: core action, consequence, then persistence/reversibility. The verb and resource are front-loaded in the first sentence with zero filler.

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 site-wide mutation with no output schema, the description covers the essential operational facts: scope, blast radius, persistence, and revert path. A note on required permissions or response shape would fully close the gap, but nothing an agent needs in order to call it correctly is missing.

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 the baseline is 3 even without param details in the description. The description's 'markup' maps to the content property and 'template or template part' maps to kind, but it adds no novel meaning beyond what the schema already documents.

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

Purpose5/5

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

Opens with a specific verb+resource: 'Update a block template or template part's markup.' The scope (template vs template part) and object (markup) are explicit, and the DB-vs-file distinction separates it from sibling write_theme_file/edit_theme_file tools while get_template/list_templates handle reads.

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

Usage Guidelines4/5

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

Provides clear context for when to call it: the agent learns the operation targets block template markup, applies site-wide immediately, and persists as a database customization. It lacks an explicit exclusion clause naming alternatives (e.g., write_theme_file for direct file edits, reset_template_customization for reverting), so it misses the 'when not to use' bar for a 5.

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

Deploy Server