MagicWP Updates: Teams, API Tokens, MCP and Backups You Keep

Running one WordPress site is mostly about the site. Running several is about everything around it: who is allowed to change what, which updates are outstanding, how you automate repetitive work, and whether you can safely undo a mistake. The October 2026 MagicWP updates tackle those problems together. You can now bring people into workspaces without sharing accounts, scope their access down to individual sites, connect scripts through API tokens, and manage sites through an AI assistant using MagicWP MCP.

There is also a new cross-site Updates view, full backups you can deliberately keep, notes attached to individual sites, and improvements to account security and status reporting. Some of these features save clicks. Others change how you should organize the people and tools that manage your WordPress sites.

TL;DR

• Workspaces let teammates, clients and freelancers sign in with their own accounts; roles and optional site restrictions control what they can access.
• API tokens allow workspace-scoped automation with selected permissions, optional IP restrictions and an expiration date.
• MagicWP MCP connects supported AI assistants to permitted management actions. It is included with paid plans, supports read-only and full-access token presets, and records actions in Activity.
• Updates brings WordPress core, themes and plugins together across your sites, with individual, per-site and cross-site update actions.
• Kept backups let you preserve up to three full, offsite backups per site through the API until you delete them, separately from routine daily backups.
• Site notes, clearer status messages and account-security hardening make day-to-day operations easier to follow.

Workspaces: bring your team without sharing a login

A shared password is an awkward way to run a team. It gives people the same identity, makes activity harder to attribute, and creates a credential-rotation problem every time someone leaves. Workspaces replace that approach with individual MagicWP accounts for colleagues, contractors and clients.

Invite someone to a workspace and they sign in with their own account and two-factor authentication. A workspace switcher at the top of the sidebar lets a member move between their personal workspace and workspaces they have joined. That is useful for an agency managing client sites, but it also makes sense for an in-house team whose developer, finance and content responsibilities should not be bundled under one login.

The workspace's Activity page records who did what and when. The important distinction is accountability: the record can identify a member rather than a shared set of credentials. For a team troubleshooting a changed setting or reconstructing a deployment, that is much more useful than knowing only that “the admin account” was used.

Four roles, with site-level access when you need it

Workspace members can have one of four roles: Admin, Developer, Customer or Billing. You can also restrict a member to selected sites instead of giving them the entire workspace.

The role split is designed around practical boundaries. A Developer can work on assigned sites without seeing billing. A Billing member can handle invoices without changing a WordPress site, and an invoice records who paid it. The Customer role offers a distinct assignment for client access; its exact permissions should be reviewed in the workspace before you invite someone. Likewise, an Admin role should go only to people who need broad control.

Site restrictions matter as much as roles. A developer may be trusted to change plugins but still have no reason to access a different client's site. Set the smallest practical scope first and expand it when the work actually requires it.

There is one detail worth planning for when a member leaves. MagicWP lists the sites where that person had access to credentials so you can decide what to rotate. Removing their workspace membership stops future access through that membership, but you should not assume it invalidates credentials they might previously have viewed. Treat offboarding as both an access change and a credential review.

API tokens: automate work without handing a script your account

A team member and a script should not use the same authentication model. A person needs a sign-in and a role; a script needs a narrowly scoped credential that you can expire or revoke independently. MagicWP now supports API tokens under Settings → API tokens, with the MagicWP API available at api.magicwp.io.

Each token belongs to one workspace and grants only the permissions you select. You can limit use to specified IP addresses and choose an expiration date. The dashboard also shows when and from where a token was last used, and lets you revoke it in one click. MagicWP publishes an API description that compatible tools can read directly.

That opens up workflows such as a deployment script checking a site before a release, a CI job taking a backup, or an internal tool gathering site information. The specific calls and request formats should come from the published API description rather than assumptions about endpoint paths.

A few operational rules make the new access useful without creating unnecessary risk:

• Use a separate token per integration. A CI job and an internal reporting script should not share the same key. If one is compromised or retired, you can revoke only that integration.
• Select only required permissions. A tool that reads site status has no reason to receive deletion or other write privileges.
• Set an expiry and restrict IPs where practical. IP restrictions work well for a runner with known outbound addresses; they can be unsuitable for tools whose outbound IPs change.
• Keep tokens out of source control and logs. Store them in the secret-management facility used by your deployment or automation platform.
• Review last use and revoke unused tokens. Token inventory is part of operating a workspace, not a one-time setup step.

The important improvement here is not simply “MagicWP has an API.” It is that automation can be scoped to one workspace and only the actions it needs, with an independent lifecycle from the human who created it.

MagicWP MCP: manage sites from an AI assistant

The API is useful when you want to write code. MagicWP MCP is for situations where you want to describe a task to a compatible AI assistant and have it work with your MagicWP sites. MagicWP now operates its own Model Context Protocol (MCP) server, with support for Claude Code, Claude Desktop, Cursor, Codex and Gemini CLI.

With the connection configured, you can ask an assistant to check the health of your sites, update plugins after taking a fresh backup, create staging, adjust PHP and cache settings, or add a redirect. The assistant can carry out permitted actions and report the result; the MCP integration can also follow longer-running jobs, such as site creation, through completion.

These are examples of supported workflows, not a reason to grant every assistant unrestricted access. MCP uses an API token you create. The For MCP (read-only) and For MCP (full) presets give you starting points, and the tools available to the assistant follow the permissions of that token.

Start read-only, then expand intentionally

If your first goal is to ask “which of my sites need attention?”, begin with the read-only preset. It is a good fit for audits, checks and learning how the assistant presents information. When you have a concrete task that changes configuration or content, create or authorize a token with the required write permissions.

For example, a reasonable maintenance request is:

Check my sites for outstanding WordPress updates. Tell me which sites need attention first. Do not change anything.

After reviewing the answer, you might follow up with:

Take a backup of the selected site, update its plugins, and report which updates succeeded or need manual attention.

The second request should be run only with the necessary permissions, and any live-site maintenance still deserves ordinary change control: check compatibility, consider staging, and know what you will restore if a plugin causes a regression. Natural language changes the interface; it does not remove the risk of changing production software.

Destructive MCP actions require you to type the site's domain as confirmation. Actions performed through the assistant also appear in workspace Activity, marked “via MCP”, so the audit trail distinguishes assistant-driven work from other activity. These safeguards are useful, but the token permissions remain the first and most important boundary.

Availability: MagicWP MCP is included with paid plans. Open MCP in the dashboard for the current setup instructions and example prompts; connection screens and client-specific configuration can change over time.

One Updates view for WordPress core, plugins and themes

Updates are easy to underestimate when you manage more than a few sites. A plugin may be current on one client site but outdated on another. Switching through each site's WordPress admin to discover that difference wastes time and makes it easier to overlook something.

MagicWP's new Updates view puts WordPress core, plugin and theme versions in one place across the sites you own. It shows what is installed alongside what is available. From there you can update one item, update everything on a particular site, or apply updates across your sites.

The most valuable aspect is the choice of scope. A security-related plugin release might warrant attention on every affected site, while a major theme update might deserve a staging test on one site before broader rollout. Bulk actions are a convenience, not a requirement to change everything at once.

Auto-updates remain WordPress auto-updates

MagicWP's auto-update switches write the settings WordPress itself uses. WordPress then applies those updates on its own schedule, using its own rollback behavior. That is distinct from scheduling an update job in the MagicWP dashboard, and it matters when you are investigating when an automatic update actually occurred.

MagicWP checks each site against WordPress.org every six hours. If you need a fresh check before a maintenance window, use Check now rather than assuming the current list reflects the last few minutes. The six-hour check describes update discovery; it should not be interpreted as a promise that WordPress installs every enabled auto-update within six hours.

For live stores, membership sites and other sensitive workloads, a cautious sequence still makes sense: review available releases, create a backup, test high-risk changes on staging, apply updates, then verify checkout, sign-in and key forms. The MagicWP backup documentation explains the existing backup and restore tools. Centralized visibility makes that process easier to coordinate; it does not replace verification after the change.

Backups you can keep until you choose to delete them

Automatic daily backups protect against many routine failures, but a backup taken immediately before a risky change serves a different purpose. You want a known restore point that remains available while you test the change, not one that disappears according to an ordinary short retention window.

MagicWP now lets you create a full kept backup through the API. It remains until you delete it, with a limit of three kept backups per site. These backups appear on the site's Backups page, are stored offsite like daily backups, can be restored in one step, and do not count toward your storage allocation.

The creation method matters: the release describes taking a kept backup through the API. Do not assume there is a new “keep forever” button in the dashboard unless you see it in the current interface. The Backups page is where retained backups are visible and restorable.

Three kept backups are enough for deliberate checkpoints, not endless archival. A practical allocation could be one before a major plugin upgrade, one before a theme or PHP change, and one before a migration or structural update. Remove a checkpoint once the change is verified and the retention is no longer needed, so there is room for the next one.

A retained backup is also not a substitute for checking restore readiness. The backup captures a point in time. If new orders, form entries or customer changes arrive after it, restoring the old snapshot can overwrite those newer changes. On a busy WooCommerce store, plan a rollback that accounts for transactional data rather than treating any full-site restore as consequence-free.

Site notes keep operational context beside the site

People often know the one important thing about a site that does not belong in WordPress settings: which client owns it, which plugin must not be updated without approval, or where its staging environment lives. That knowledge tends to disappear into chat threads or private notes.

You can now keep notes on each site in MagicWP. They appear on the site's Overview, and a note icon on the Sites page lets you read them without opening the site. A short note like “Confirm checkout with client before changing the payment plugin” can prevent a well-intended maintenance action from turning into an incident.

Use site notes for shared operating context, not as a password manager. Record what someone needs to know, where to find the authoritative runbook, and who to ask when a change is sensitive. Do not place secrets in ordinary notes.

More reliable status messages and stronger account protection

Two smaller changes are worth mentioning because they affect whether the dashboard is trustworthy when something unusual happens.

First, site status messages are now delivered more reliably to the dashboard. Messages about a site being provisioned or the reason it has been suspended were not always appearing where they should. The fix makes those states easier to understand without guessing what a blank or incomplete status means.

Second, MagicWP has hardened several account-security paths: sign-in, password reset, two-factor authentication and account activity logging. The changes include stronger protection against repeated sign-in attempts. This is an account-side improvement rather than a new setting you need to enable, although using your own two-factor authentication and reviewing member access remain important.

Together with workspace Activity and MCP attribution, these changes make the system better at answering two questions that matter during troubleshooting: what is happening to the site, and who or what initiated a change?

Frequently Asked Questions

Can I invite a freelancer without giving them access to every site?

Yes. Invite them to a workspace with their own account, select an appropriate role, and restrict their access to the sites they actually work on. That avoids sharing a password or exposing unrelated client sites. When the project ends, remove their membership and review the sites where they could access credentials. Rotate those credentials where appropriate; removing an account does not automatically undo information someone previously obtained.

What is the difference between an API token and MagicWP MCP?

An API token is a credential that lets a script or other tool access permitted MagicWP API operations in one workspace. MagicWP MCP is an interface that exposes permitted site-management tools to compatible AI assistants. MCP uses an API token, so its effective capabilities depend on the permissions you grant. Use the API directly for deterministic scripts, and MCP when an assistant-driven workflow or conversational interface is genuinely helpful.

Which AI assistants can connect to MagicWP MCP?

The October release lists Claude Code, Claude Desktop, Cursor, Codex and Gemini CLI. MagicWP MCP is included with paid plans, and the dashboard's MCP area provides setup steps and example prompts. Client configuration can change, so use those current steps instead of copying settings from an older guide. For an initial connection, a read-only token is a sensible way to verify what the assistant can see before permitting changes.

Can an AI assistant delete a site without confirmation?

The MCP integration requires you to type the site's domain for destructive actions. The assistant is also limited by the permissions on its API token, and MCP actions are recorded in Activity with a “via MCP” label. These safeguards do not make broad write access a good default. Start with read-only permissions and grant destructive capabilities only when there is a real operational need.

Does MagicWP's Updates page replace WordPress auto-updates?

No. The Updates view centralizes visibility and lets you perform individual, per-site or cross-site updates. Its auto-update switches set WordPress's own auto-update configuration; WordPress performs automatic updates on its schedule and handles its rollback behavior. MagicWP checks WordPress.org for available versions every six hours, and Check now requests a fresh check. Plan high-impact updates separately when staging and verification are required.

How long do kept backups last, and how many can I save?

A kept backup stays until you delete it, subject to a limit of three kept full backups per site. You create one through the API, and it appears in the site's Backups page for one-step restore. It is stored offsite and does not count toward your storage allocation. Routine daily backups are a separate capability. Remember that restoring an older full backup can replace data changed after that backup, especially on an active store.

Is there anything I need to change for the security fixes?

The release describes backend hardening across sign-in, password reset, two-factor authentication, activity logging and protection against repeated sign-in attempts; it does not specify a new toggle that users must turn on. You should still enable two-factor authentication for your own account, use individual workspace memberships rather than shared logins, and periodically remove access and API tokens that are no longer needed.

Wrapping up

This month's MagicWP updates are about making WordPress operations easier to delegate, automate and audit. Workspaces and roles decide who can do the work. API tokens decide what a tool can do. MCP makes permitted actions available from an AI assistant. The Updates view shows where maintenance is needed, while kept backups give you deliberate restore points before consequential changes.

If you manage several sites, start with the access model rather than the automation. Give each person their own workspace membership, restrict their site access, and create narrowly scoped tokens. Then use the new Updates view to plan maintenance and take a kept backup before a change you may need to reverse. You can explore these tools in the MagicWP dashboard, or review MagicWP's managed WordPress hosting if you are considering bringing more sites onto the platform.