Kreiswolke Maintenance Agent Toolkit

Yes — that's what it's designed for. Every capability is a REST endpoint, registered with the WordPress Abilities API (WP 6.9+), so any MCP-capable client you trust — or plain curl — can discover and use them. Authentication is a standard WordPress Application Password; destructive operations are snapshot-first with on-disk verification. The plugin is useful to humans and to whatever tooling you already run.

Yes, fully. The app adds orchestration (the maintenance agent, scheduling, multi-site dashboards, reports); the plugin alone gives you the reports, rollback, careful updates, and hardening on a single site.

Not unless you connect it to the companion app, and then only as described under "External services". There is no telemetry, no tracking, no phone-home.

The emergency companion exists for exactly one scenario: a failed update breaks the main plugin (or the site), and you still need the heartbeat, the maintenance splash, and the restore tools to work. A regular plugin can't promise that — an MU-plugin can. It is written atomically (no half-written file can white-screen a site), updated only on activation/version change, and removed on uninstall.

Only when you enable an Apache-level hardening feature, and only inside one clearly marked block. The plugin backs up your .htaccess before every change, offers one-click restore, ships a kill-switch (create one file via FTP and all rules turn off), and removes the block fully on deactivation/uninstall. Blocking at the webserver is the point of these features: the request is rejected before PHP starts.

The gate puts a small PIN page in front of wp-login.php. It was built after watching bots hammer login pages on real servers: every attempt boots PHP, WordPress, and the database — a WordPress-layer rate limiter still pays that cost on each hit. The gate stops those requests at the webserver, before WordPress runs; bot/load protection is the primary purpose, the added login secrecy is a bonus. It is opt-in, requires a PIN before it can be enabled, and is built to fail open: if the plugin is removed by any means, the rule disables itself; a kill-switch file disables it instantly; logout/password-reset URLs are never blocked.

base64 encodes/decodes Ed25519 signature material and HTTP Basic auth — both are binary-to-text transports, not obfuscation; every site is commented. The single unserialize() reads WordPress's own Application Passwords usermeta and is hardened with allowed_classes => false. The error handler and shutdown hooks feed the plugin's own error log and let a restore endpoint return structured JSON even if a fatal occurs; the handler returns false so PHP's normal error flow is untouched.

Everything except the Apache-level rules, which are detected as not applicable; for each, the plugin shows an equivalent nginx snippet to paste into your server config instead of pretending it worked.

No. The plugin is a deterministic toolkit — predictable, inspectable, no model calls. AI-assisted planning happens in the optional companion app, server-side, only for connected sites.