Skip to main content
Glama

wp_deactivate_plugin

Deactivate a WordPress plugin with a dry-run preview first. Avoid taking site functions offline by checking impacts before applying changes.

Instructions

Deactivate one plugin: this can take site functionality OFFLINE immediately.

DEACTIVATING A LIVE PLUGIN TAKES WHATEVER IT PROVIDES OFFLINE the instant it lands - forms stop submitting, caching stops serving, security rules stop applying, and page builders stop rendering their layouts (a Divi/Elementor page can come back as raw shortcodes). Check what the plugin does before calling this, and prefer staging. Deactivating wp-ops-connect is REFUSED outright: it is the control-plane plugin this tool reaches the site through, so deactivating it would sever this tool's own connection to the site and nothing here could re-activate it. plugin may be a slug ('akismet'), a plugin file ('akismet/akismet') or its .php path; a slug matching two installed plugins is refused with the candidates rather than guessed. A plugin that is already inactive comes back as a no-op, not an error. DEFAULTS TO dry_run=true (returns a preview naming the plugin, its current status and what would change; changes nothing). Pass dry_run=false to apply - the change is verified by re-reading the plugin's status. Requires the REST transport. Prod writes require allow_prod=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pluginYes
dry_runNo
installYes
allow_prodNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.4.0

TDQS

A4.3/5.0
Behavior5/5

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

The description is exceptionally transparent about side effects, including immediate downtime, refusal to deactivate wp-ops-connect, no-op behavior for already-inactive plugins, dry-run default, verification after applying, and the prod write gate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense but repetitive, especially the all-caps warning about deactivating a live plugin that restates the opening sentence. It could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a safety-critical mutation, the description covers the necessary context: destructive effects, protected plugin, dry-run default, prod guard, verification, transport requirement, and return behavior. It is sufficient for an agent to use the tool responsibly.

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?

The description explains plugin formats, dry_run, and allow_prod in detail. However, the required 'install' parameter is not described at all, leaving a significant gap for agents deciding what value to pass.

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?

The description opens with a clear verb-object statement: 'Deactivate one plugin.' It also explains the consequence (taking functionality offline), making the tool's purpose unmistakable and distinct from activation or listing tools.

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?

It provides strong guidance: use dry_run first, prefer staging, pass dry_run=false to apply, and require allow_prod=true for prod writes. It does not explicitly contrast with wp_activate_plugin, but the inverse relationship is obvious from the name and sibling context.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ad02/wp-ops-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server