Skip to main content
Glama
Sign In
Official Porkbun MCP Server

Official Porkbun MCP Server

by oborseth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Wordpress Request

wordpress_request
Destructive

Edit WordPress site pages, posts, menus, categories, comments, and settings by running a single REST API call, with no password or extra setup required.

Instructions

EDIT A CLOUD FOR WORDPRESS SITE'S CONTENT: pages, posts, menus, categories, comments, site title and anything else in the WordPress REST API. This is the tool to use when the user asks to change what is on their WordPress site. It runs one REST call inside the site, so no password or extra setup is needed. path is the REST route without /wp-json, e.g.:

  • list pages: GET /wp/v2/pages with query {"_fields": "id,title,link,status"}

  • read a page to edit it: GET /wp/v2/pages/12 with query {"context": "edit"} (content.raw is the block markup to change)

  • update it: POST /wp/v2/pages/12 with body {"content": "..."} (send the whole new content, keeping the block comments)

  • new post: POST /wp/v2/posts with body {"title": "...", "content": "...", "status": "draft"} (draft first, publish when the user says so)

  • menus: /wp/v2/navigation, /wp/v2/menu-items; search: GET /wp/v2/search?search=...

  • widgets (classic themes, e.g. a footer): GET /wp/v2/sidebars first for the real widget-area ids, then POST /wp/v2/widgets with that sidebar id. Without a valid sidebar, WordPress still answers 201 but parks the widget in Inactive widgets, so check the sidebar afterwards. Block themes have no widget areas: edit the footer template part (/wp/v2/template-parts) instead. It acts as the porkbun-agent WordPress editor by default (pages, posts, media, comments). Site settings (title, tagline, homepage), plugins, themes and users need as_administrator: true with acknowledge_full_access: true; ask the user first. Use _fields and per_page to keep answers small. Show the user what will change before overwriting a page, and offer create_wordpress_backup before big edits. Images: upload with wordpress_upload_media, then use its id or url. WordPress's own errors come back as WP_REST_ERROR with httpStatus and its message.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>",
      "path": "<path>"
    },
    "name": "wordpress_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoJSON body for POST/PUT/PATCH.
pathYesREST route, e.g. `/wp/v2/pages` or `/wp/v2/posts/42`. No query string: use `query`.
embedNoInclude linked resources (_embed), e.g. the featured image.
queryNoQuery parameters, e.g. {"per_page": 10, "context": "edit", "_fields": "id,title"}.
domainYesThe domain of the Cloud for WordPress site, e.g. `example.com`.
methodNoHTTP method (default GET). POST updates an existing item when the path has its id.
dry_runNoFor writes: check the request without sending it to WordPress.
as_administratorNoAct as the site administrator (settings, plugins, themes, users). Needs acknowledge_full_access.
acknowledge_full_accessNoConfirms the user agreed to administrator-level changes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.62.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, but the description adds behavior the annotations cannot express: no password/setup needed, default identity is the porkbun-agent editor while admin scope is gated behind an explicit acknowledgment flag, WordPress errors surface as WP_REST_ERROR with httpStatus and message, and the sidebar trap where a 201 response can silently park a widget in Inactive widgets. That is unusually rich disclosure of side effects and verification steps.

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?

Purpose is front-loaded in the first two sentences, followed by tight bulleted examples that scan well. It is long, and the widget paragraph is dense, but nearly every sentence carries operational information rather than filler.

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 nine-parameter tool that proxies arbitrary REST routes with no output schema, the description supplies the missing scaffolding: permission tiers and the consent gate, example call shapes, error format, widget/template-part caveat, and a safe-edit workflow. An agent could invoke this correctly without further context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns an upgrade by teaching path format (route without /wp-json, no query string — use `query`), the meaning of `context: edit` to get content.raw block markup, method semantics (POST updates when the path carries an id), and the purpose of _fields/per_page. Only `dry_run` and `embed` go unmentioned in prose.

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?

Opening line names a specific action (edit site content) plus the resource scope (pages, posts, menus, categories, comments, site title, and anything else in the WP REST API), and it explicitly frames the trigger: 'This is the tool to use when the user asks to change what is on their WordPress site.' That cleanly separates it from read-oriented or specialized siblings such as wordpress_upload_media and create_wordpress_backup.

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 states when to use it, how to escalate (site settings, plugins, themes, users require as_administrator + acknowledge_full_access, and 'ask the user first'), and routes the agent to alternatives: wordpress_upload_media for images, create_wordpress_backup before big edits, draft-before-publish for posts. The widget-vs-template-part branch gives a concrete decision rule for a common failure mode.

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

Deploy Server

Other Tools