maintain-wordpress

Original：🇺🇸 English

Translated

Keep WordPress sites on Hostinger web hosting updated and secure: checks core, plugin and theme versions, known vulnerabilities and install health on one site or every site in the account, reports what needs doing, applies updates in a safe order, and confirms each site still loads. Also covers cache purges, the Memcached object cache, maintenance mode and one-click wp-admin login links. Triggers: update my WordPress, update plugins, are my WordPress sites secure, WordPress vulnerabilities, outdated plugins or themes, WordPress maintenance, speed up WordPress, log me into wp-admin.

2installs

Sourcehostinger/api-mcp-server

Added on2026-10-31

NPX Install

npx skill4agent add hostinger/api-mcp-server maintain-wordpress

SKILL.md Content

View Translation Comparison →

Maintain WordPress

Check first, report, then update only what the user approves — one site at a time, proving each still loads before moving to the next.

Calling the operations

Read the
```
inputSchema
```
that
```
search
```
returns before the first call of each operation. If a name below is rejected as unknown,
```
search
```
for what the step does (e.g. "wordpress plugins update").
Batch reads with
```
multi-execute
```
(up to 20 steps a batch). Batches chain operations from one server only — the Hostinger Connector runs
```
wordpress
```
,
```
hosting
```
and
```
agency-hosting
```
as separate servers.
Updates, activations, uninstalls and core changes are queued jobs: a success response means "queued". Poll the matching read operation every 10–20 s until the change shows; never re-send the write.

1. Find the installs

One site:
```
wordpress_installations_list
```
with
```
domain
```
(substring match — take the exact entry). Every site:
```
wordpress_installations_list
```
without filters, adding
```
ownership: "all"
```
to include sites the user manages for others.

Keep

id

(the

software

parameter of every

wordpress_*

call),

username

,

domain

,

directory

,

is_valid

and

validation_error

.

Agency Plan WordPress sites come from

agency-hosting_websites_list-plan

with

website_types: ["wordpress"]

. When

wordpress_installations_list

does not include them, only

agency-hosting_wordpress_settings

and core version changes (

agency-hosting_wordpress_list-versions

,

agency-hosting_wordpress_change-version

) are available; plugins and themes are updated from wp-admin.

2. Check (read-only)

Per install:

```
wordpress_installations_show-core-version
```
— core version and the known vulnerabilities that affect it.

wordpress_installations_list-core-updates

— available core versions.

wordpress_plugins_list-installed

—

status

,

update

(the newer version, when there is one) and

vulnerabilities[]

with

fixed_in

.

```
wordpress_themes_list-installed
```
— the same for themes.

Four steps per install fit five installs in one batch. For an install with

is_valid: false

, run

wordpress_installations_check-if-are-valid

with

force: true

for a fresh reason and leave it out of updates — a broken install is the

troubleshoot-website

skill's job.

3. Report before changing anything

## example.com (WordPress 6.8.1)
Vulnerable: contact-form-x 5.2 → fixed in 5.3 (update available)
Vulnerable, inactive: old-slider 1.0 — no fix; uninstall recommended
Updates: core 6.8.1 → 6.8.3 (minor), 4 plugins, 1 theme

Vulnerable items come first. A vulnerable plugin without a fix, or an inactive one, is better removed with

wordpress_plugins_uninstall

than left installed — inactive code on disk can still be reached. Ask which updates to apply.

4. Back up first

The API has no backup operation. Before updating, ask the user to create a backup in hPanel or confirm the latest automatic one is recent enough. Say it plainly; the user may choose to go ahead without one.

5. Update, one site at a time

Plugins that fix a vulnerability —
```
wordpress_plugins_update
```
with their slugs.
The remaining approved plugins, then themes with
```
wordpress_themes_update
```
.
Core with
```
wordpress_installations_update-core
```
:
```
minor: true
```
for patch releases; a major
```
version
```
only when the user asks for it.

For a busy site the user may want

wordpress_maintenance_toggle

with

enabled: true

during the run — and it is always turned off again afterwards, even when something failed.

After each site:

wordpress_litespeed-cache_purge-lite-speed

.

curl -s -o /dev/null -w "%{http_code}\n" https://DOMAIN/

and the same for

https://DOMAIN/wp-login.php

— both should be

with no PHP error in the body.

wordpress_installations_check-if-are-valid

with

force: true

.

When a site breaks: stop the run, deactivate the plugin updated last with

wordpress_plugins_deactivate

, check again, and report which update caused it before touching any other site.

6. Performance and access

Page cache:
```
wordpress_litespeed-cache_show-lite-speed-status
```
; purge after design or content changes.

Object cache:

wordpress_object-cache_show-memcached-status

, then

wordpress_object-cache_toggle-memcached

with

enabled: true

— the usual quick speed-up.

PHP version:
```
hosting_php_get
```
is large (around 25 KB), so read it only when the user asks about PHP. PHP 8.x is markedly faster than 7.x; confirm plugin compatibility before
```
hosting_php_update-version
```
.
wp-admin:
```
wordpress_login_create-links
```
returns temporary one-click login links. Give them to the user only; never store or reuse them.
Hostinger's own plugins update with
```
wordpress_plugins_update-hostinger
```
(
```
slug
```
).

Many sites

Tell the user how many installs there are before starting. Check in batches, keep one running report, and update site by site so a failure stops the run with the rest untouched.

maintain-wordpress

NPX Install

Tags

SKILL.md Content

Maintain WordPress

Calling the operations

1. Find the installs

2. Check (read-only)

3. Report before changing anything

4. Back up first

5. Update, one site at a time

6. Performance and access

Many sites