Skip to main content
Glama
Sign In

turbopress

by de.turbopress.mcp
OverviewDiscussionsAdmin

Plugin oder Theme löschen

delete_wordpress_item
Destructive

Löscht EIN WordPress-Plugin oder -Theme, das INAKTIV ist (slug, siehe unten). Gelöscht wird ausschließlich, was nachweislich inaktiv ist; der Zustand wird frisch auf der Installation gelesen. IMMER verweigert, auch auf ausdrücklichen Wunsch: das aktive Theme und dessen übergeordnetes Theme (Parent); das letzte installierte Standard-Theme (Twenty …), solange das aktive Theme kein Standard-Theme ist; aktive und netzwerkweit aktive Plugins (erst mit set_wordpress_plugin_state deaktivieren, dann löschen); Must-Use-Plugins und Drop-ins; Plattform-Plugins (LiteSpeed Cache, Imunify, WP Toolkit, turbometrics, turbopress-…); WordPress-Multisite-Installationen insgesamt. Bei einer Verweigerung wird nichts gelöscht und kein Backup-Platz verbraucht. Vor dem Löschen wird ein Sicherheits-Backup erstellt; lässt es sich nicht erstellen oder nicht nachweisen, wird NICHTS gelöscht. Zurückholen lässt sich ein gelöschtes Plugin oder Theme nur über dieses Backup (restore_wordpress_backup, stellt aber die ganze Installation auf den Backup-Stand zurück) oder durch Neuinstallation — das Löschen selbst ist endgültig. Sag dem Kunden deshalb VOR dem Aufruf klar, dass das Löschen endgültig ist: Beim Chat-Zugang sieht der Kunde danach eine Bestätigungskarte, die Antwort ist dann nur eine Bestätigungsanfrage, nichts wurde gelöscht. Übergib IMMER der Slug (Ordnername, z. B. "hello-dolly"), nie den Anzeigenamen — er lässt sich aus dem Namen nicht ableiten. Die Slugs aller installierten Plugins und Themes (auch inaktiver) nennt get_wordpress_plugins; get_outdated_plugins nennt sie nur für Einträge mit offenem Update, scan_wordpress_vulnerabilities nennt Slugs von Plugins und Themes mit bekannten Schwachstellen (auch inaktiven, die man dann löschen will); ist der Slug nicht bekannt, zuerst get_wordpress_plugins aufrufen, statt zu raten. Nach dem Löschen wird auf der Installation NACHGELESEN: Erst wenn der Eintrag dort nicht mehr steht, gilt er als gelöscht. Lässt sich das nicht bestätigen, melde es als nicht bestätigt, nie als gelöscht. Nie "alle auf einmal", immer nur ein Element pro Aufruf.

Input Schema

NameRequiredDescriptionDefault
slugYesSlug (Ordnername) des Plugins oder Themes, z. B. "hello-dolly" — nicht der Anzeigename. Höchstens 100 Zeichen aus Buchstaben A–Z/a–z, Ziffern, Punkt, Bindestrich, Unterstrich; das erste Zeichen ist ein Buchstabe oder eine Ziffer, kein ".." und kein Schrägstrich. Der Slug muss auf der Installation vorhanden sein, sonst wird nichts gelöscht (Slug-Quelle: get_wordpress_plugins; siehe auch get_outdated_plugins).
domainYesDie Domain, z. B. example.de
site_urlNoBei mehreren WordPress-Installationen auf derselben Domain: welche gemeint ist
item_typeYesOb ein Plugin oder ein Theme gelöscht werden soll

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / slug / description
      Previous value: -"Slug (Ordnername) des Plugins oder Themes, z. B. \"hello-dolly\" — nicht der Anzeigename. Höchstens 100 Zeichen aus Buchstaben A–Z/a–z, Ziffern, Punkt, Bindestrich, Unterstrich; das erste Zeichen ist ein Buchstabe oder eine Ziffer, kein \"..\" und kein Schrägstrich. Der Slug muss auf der Installation vorhanden sein, sonst wird nichts gelöscht (siehe get_outdated_plugins; Slug sonst beim Kunden erfragen)."New value: +"Slug (Ordnername) des Plugins oder Themes, z. B. \"hello-dolly\" — nicht der Anzeigename. Höchstens 100 Zeichen aus Buchstaben A–Z/a–z, Ziffern, Punkt, Bindestrich, Unterstrich; das erste Zeichen ist ein Buchstabe oder eine Ziffer, kein \"..\" und kein Schrägstrich. Der Slug muss auf der Installation vorhanden sein, sonst wird nichts gelöscht (Slug-Quelle: get_wordpress_plugins; siehe auch get_outdated_plugins)."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds substantial context beyond them: a safety backup is created before deletion and nothing is deleted if it cannot be created or verified, refusals consume no backup quota, deletion is irreversible except via restore_wordpress_backup (which rolls back the whole installation), the chat-access confirmation-card flow, and post-delete verification by re-reading the installation.

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

Conciseness4/5

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

The hard constraint (inactive-only, single item) is front-loaded and every block covers a distinct concern. It is nonetheless long and repeats the irreversibility point twice ('das Löschen selbst ist endgültig' and the customer-warning sentence), which is defensible for a destructive tool but not maximally tight.

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 destructive, four-parameter tool with no output schema, the description covers preconditions, refusal cases, backup/restore path, human-in-the-loop confirmation, and how success is verified afterwards. Nothing an agent needs to call it safely 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 coverage is 100%, so the schema already carries the heavy lifting, including the slug pattern, the 'not the display name' rule and the get_wordpress_plugins slug source. The description reinforces the slug rule ('Übergib IMMER der Slug ... nie den Anzeigenamen') but adds no new semantics for domain, site_url or item_type, so the baseline 3 applies.

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 specific verb and resource ('Löscht EIN WordPress-Plugin oder -Theme, das INAKTIV ist') and immediately scopes the operation to exactly one element per call. It explicitly names the sibling that must be used first for the alternative case (set_wordpress_plugin_state) and distinguishes itself from get_wordpress_plugins / get_outdated_plugins / scan_wordpress_vulnerabilities by role.

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

Usage Guidelines5/5

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

It enumerates when the tool refuses (active theme and its parent, last default theme, active/network-active plugins, must-use plugins and drop-ins, platform plugins, multisite) and points to the correct preceding tool for the deactivation path. It also states the slug-discovery procedure ('ist der Slug nicht bekannt, zuerst get_wordpress_plugins aufrufen, statt zu raten') and the one-item-per-call rule.

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

All turbopress toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources