Handsome Hosting

Order a WordPress site

create_wordpress

Destructive

Order a WordPress site: a fresh install (mode new) or a server ready to receive an existing WordPress site (mode move). No upload and no pre-flight: the platform installs WordPress itself. Returns actionId and approveUrl (also mailed to the person; one hour): they see the order and pay with one click; nothing is charged without it. domain works as for a new project. Once paid, a new site installs and goes live by itself; a move server waits for the person to move the old site with the migration details. A partner account can instead have the client pay for a new site: payer client with clientEmail; the client gets a signup and payment link by mail and pays the regular price in their own account, and the answer carries inviteId. An active partner with servers for client sites (services of kind host) can put the new site on one: hostId with the host's id puts it there for the site fee alone (the answer's mode is on-host and names the server's fit), hostId new buys a server of its own; left out, the site goes where the website's order form would put it. A full server refuses.

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": {
      "name": "<name>",
      "mode": "<mode>"
    },
    "name": "create_wordpress"
  }
}

Input Schema

Name	Required	Description
`mode`	Yes	new: a fresh WordPress; move: a server ready to receive an existing WordPress site the person moves here with our plugin
`name`	Yes	the site name shown on the dashboard
`payer`	No	who pays for a new site: self (default, the person approves and pays) or client (a partner sends the client a signup and payment link; mode new only)
`domain`	No	a full name: one found available (offered on the approval page, added with one click, never charged without it), or one the account already holds (heldDomains), which rides the order for free and points at the new server after its first deploy
`hostId`	No	partner hosts only: the id of one of the account's services of kind host, or new for a server of its own; left out, the best-fitting host with room, else a new server
`mailboxes`	No	optional: the mailbox names at the site's domain the person chose, up to five, such as info or sales; [] for none; left out, info is set up
`clientEmail`	No	payer client only: the client's address

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	No
`error`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

addedInput schema / properties / mailboxes

Added value: +{
+  "description": "optional: the mailbox names at the site's domain the person chose, up to five, such as info or sales; [] for none; left out, info is set up",
+  "items": {
+    "maxLength": 64,
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / clientEmail / description

Previous value: -"payer client only: the client's address, read back to the person before the call"New value: +"payer client only: the client's address"

changedInput schema / properties / domain / description

Previous value: -"a full name: one the builder found available with search_domain (offered on the approval page, added with one click, never charged without it), or one the account already holds (list_services heldDomains), which rides the order for free and points at the new server after its first deploy"New value: +"a full name: one found available (offered on the approval page, added with one click, never charged without it), or one the account already holds (heldDomains), which rides the order for free and points at the new server after its first deploy"

changedInput schema / properties / hostId / description

Previous value: -"partner hosts only: a host's id from list_services (kind host), or new for a server of its own; left out, the best-fitting host with room, else a new server"New value: +"partner hosts only: the id of one of the account's services of kind host, or new for a server of its own; left out, the best-fitting host with room, else a new server"

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations it discloses the full cost/approval flow: returns actionId and approveUrl, nothing is charged without one-click approval, the link expires in one hour, and it describes host-selection and 'a full server refuses' behavior. This is rich context the annotations alone cannot convey.

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 purpose is front-loaded, but the body is a dense run-on of semicolon-clause fragments that is hard to parse. Nearly every clause carries information, but the lack of structure and sentence breaks costs readability.

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?

Even though an output schema exists, the description still names key return values (actionId, approveUrl, inviteId, mode on-host) and covers payment, approval, partner, and host scenarios. For a 7-parameter provisioning tool, an agent has everything needed to invoke it correctly.

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, but the description adds genuine flow-level meaning: hostId 'new' buys a dedicated server, omission routes to the website order form, and payer=client requires clientEmail. It reinforces rather than contradicts the schema.

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+resource ('Order a WordPress site') and immediately distinguishes the two modes (new install vs move server). An agent can tell exactly what this tool provisions without reading the schema.

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 clearly explains when to use mode new vs move, when to set payer=client vs self, and how hostId resolves. It lacks explicit routing to siblings like wp_migration or create_project, so it stops short of full alternative guidance, but the scenario conditions are strong.

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

All Handsome Hosting tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?