WordPress tool

The WordPress tool lets an agent manage a WordPress site over its REST API (/wp-json/wp/v2) — publish and edit posts and pages, upload media, manage categories and tags, moderate comments, and search. One configuration holds the site URL and credentials; the agent picks an action per call.

Configuration

Unlike the social/ESP tools, WordPress's API host is per-site, so the configuration carries a site URL alongside the credentials. One configuration = one site — add several configurations to manage several sites. The three fields:

• Site URL (required) — your site's home URL, e.g. https://yourdomain.com. Hania appends the REST path (/wp-json/wp/v2) automatically; pasting the full REST URL or a trailing slash also works. The site must have the WordPress REST API enabled (on by default in modern WordPress). Use HTTPS.
• Username (required) — the WordPress username (not the email, unless your site signs in by email) that owns the Application Password. The user's role determines what the agent can do — see below.
• Application Password (required) — a WordPress Application Password (not your login password). Stored encrypted and never shown again; on edit, leave it blank to keep the stored one. See how to create one.

Pick a role-appropriate account: an Administrator or Editor can publish, edit any post, upload media, manage categories, and moderate comments; an Author is limited to their own posts. Use a dedicated account with only the permissions you want the agent to have.

Create an Application Password

Application Passwords let an external app authenticate to your site without using your main password, and can be revoked any time without changing your login. (Built into WordPress 5.6+; the site must be served over HTTPS.)

On a self-hosted WordPress site:

1. Log in to your site's wp-admin dashboard as the user the agent will act as (an Administrator or Editor for full capability).
2. Go to Users → Profile (or Users → All Users → [the user] → Edit).
3. Scroll to the Application Passwords section near the bottom.
4. Type a name you'll recognize (e.g. Hania AI) in New Application Password Name and click Add New Application Password.
5. WordPress shows the generated password once, in six groups of four characters (e.g. abcd efgh ijkl mnop qrst uvwx). Copy it now — you can't view it again.
6. In Hania, paste your site URL, the username from step 1, and this Application Password. Paste it exactly as shown — the spaces are fine.

What it can do

23 actions, grouped. The agent chooses one per call:

• Posts — create_post (title + HTML content, optional status/excerpt/categories/tags/featured image), update_post, get_post, list_posts (filter by search/status/page), delete_post.
• Pages — create_page, update_page, get_page, list_pages, delete_page (same lifecycle for static pages).
• Media — upload_media (sideload a public image URL; returns an attachment id to use as a featured image), list_media, get_media, delete_media.
• Taxonomy — list_categories, create_category, list_tags, create_tag.
• Comments — list_comments, moderate_comment (approve / hold / spam / trash), reply_comment, delete_comment.
• Search — search (site-wide across content).

Behaviors & gotchas

• One site per configuration. The site URL is fixed per config; add more configurations for more sites (only the name must be unique per workspace).
• Media is uploaded from a URL, not a file. upload_media takes a public https image URL; Hania fetches it (through an SSRF safety gate, with a size cap) and uploads the bytes to the Media Library. Typical flow: find/generate an image URL → upload_media → use the returned id as the post's featured image.
• Delete is permanent. delete_* actions remove content permanently (WordPress media has no Trash, and this is applied uniformly). Pair with the classification flags below if you want a safety gate.
• Comments can't be added to drafts. A reply/comment requires a published post.
• Status values — posts/pages use publish or draft; comment moderation uses approved / hold / spam / trash.
• This is the content tool, not email — it doesn't send email; the SMTP/email tools are separate.
• Lists are summarized (id/title/link/date/status) to keep responses lean; full content comes from get_post / get_page.

Safety in autonomous runs

Like any tool, the WordPress tool carries a safety classification (mutating / destructive / sends-data-externally) that governs scheduled or triggered (autonomous) runs. It ships unclassified (fully allowed). Suggested settings, which you can override:

• Destructive — reasonable to enable: the tool can permanently delete posts, pages, media and comments, and publish content. With it on, the platform's destructive-action gate requires "Allow destructive actions in autonomous runs" on the bot (whole-tool gate).
• Mutating — reasonable to enable, since the tool writes; it keeps writes from being counted as no-progress in long autonomous runs.
• Sends data externally — leave off. The destination is your configured site, not an LLM-chosen URL, so the egress gate doesn't apply.

Interactive chat is never gated by these flags.

Connection & errors

All three fields are required, so a missing one is rejected at save. At runtime, WordPress errors surface with their real HTTP status — e.g. 401/403 for a bad or insufficient credential, or a 404 for a wrong id. A quick read (the agent reading the current user or listing posts) confirms the credential works.

Lifecycle & post-call use

• Never ends a session — it's a normal action tool.
• Post-call-hook eligible — it can run after a conversation (see Post-call hooks), e.g. "after the call, draft a recap post."