Woodpresser
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WOODPRESSER_SITE | No | The site name used to select which site configuration to use when multiple sites live side by side. | |
| WOODPRESSER_USER | Yes | The WordPress username. One of the three required credentials (site URL, username, Application Password). | |
| WOODPRESSER_MODES | No | Comma-separated list of modes to enable: core, php, elementor. Tools from a mode you did not enable are not registered. | |
| WOODPRESSER_CONFIG | No | Path to the configuration file (overrides the default ~/.woodpresser/config.json). | |
| WOODPRESSER_SITE_URL | Yes | The site URL of the WordPress site. One of the three required credentials (site URL, username, Application Password). | |
| WOODPRESSER_BRIDGE_FILE | No | Path to the bridge plugin file. | |
| WOODPRESSER_APP_PASSWORD | Yes | A WordPress Application Password used for Basic auth. One of the three required credentials (site URL, username, Application Password). | |
| WOODPRESSER_BRIDGE_TOKEN | No | The token used to authenticate against the companion bridge plugin (compared with hash_equals on the server). Can also be pinned in wp-config.php via WOODPRESSER_TOKEN. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| wp_site_infoA | Identify the connected site: name, description, URL, REST namespaces, the authenticated user and their capabilities, plus bridge/Elementor/plugin versions. Start here when you inherit a project. |
| wp_health_checkA | Diagnose connectivity in layers: REST reachable, credentials accepted, bridge claimed, Elementor present, permalinks, and debug log size. Use before blaming the code. |
| wp_content_listA | List content with filters. Returns compact rows by default (no full content). Use wp_content_get for the body. |
| wp_content_getB | Fetch a single item by ID or slug, including raw and rendered content plus open Graph-ish fields. |
| wp_content_createC | Create content. Returns the new ID and link. Supports meta, taxonomy terms and page templates. |
| wp_content_updateB | Patch an existing item. Only supplied fields change. For a full Elementor rewrite use wp_el_set instead. |
| wp_content_deleteA | Moves to trash by default. force=true bypasses trash forever and requires confirm:"delete". |
| wp_media_listC | List attachments with optional MIME filter and search. |
| wp_media_uploadB | Upload a local file to the media library. Provide path, or url to sideload a remote file. |
| wp_terms_listC | List categories, tags or any public taxonomy. |
| wp_term_createC | Create a category or tag. |
| wp_users_listC | List users with roles. Requires administrator credentials. |
| wp_plugins_listA | List installed plugins with status and available updates. |
| wp_plugin_actionA | Activate, deactivate, install (from wordpress.org by slug) or delete a plugin. Deletion requires confirm:"delete". Activating an untrusted plugin is a security decision. |
| wp_themes_listA | List installed themes and which one is active. |
| wp_theme_activateA | Switch the active theme. Changing themes on a live site is high-impact; prefer a staging copy. |
| wp_settings_getA | Read the REST-exposed site settings (title, description, timezone, permalinks, front page). |
| wp_settings_setB | Update REST-exposed settings. Arbitrary options need wp_php_run or wp_db_query. |
| wp_searchB | Search across posts, pages and media in one call. Use this to locate content before editing it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
Most tools map cleanly to a resource+action pair (content CRUD, media, terms, plugins, themes, settings), so selection is usually obvious. Minor overlaps exist: wp_search vs wp_content_list both locate content, and wp_site_info vs wp_settings_get both expose title/description, which could cause a misselection. Descriptions do enough disambiguating work to keep this mostly clean.
A consistent wp_ + resource + action convention runs through nearly all tools (wp_content_get, wp_media_upload, wp_plugin_action, wp_settings_set). Deviations are small: wp_terms_list is plural while wp_term_create is singular, and a few names are noun-only (wp_site_info, wp_health_check, wp_search). Still readable and predictable overall.
19 tools is on the heavy side but each covers a distinct slice of WordPress administration (content, media, terms, users, plugins, themes, settings, diagnostics, search). No obvious filler tools; the count is driven by genuine domain breadth rather than redundancy.
Content has full CRUD, but media and taxonomy are half-finished: no wp_media_get/delete and no wp_term_update/delete, leaving dead ends. Worse, descriptions reference tools that do not exist (wp_el_set, wp_php_run, wp_db_query), which will send an agent chasing phantom operations, especially for the Elementor workflow the server advertises.