Reference

Inputs and outputs

Keep website references, Ability IDs, and parameters separate.

An MCP tool's outer arguments and an Ability's own parameters are different contracts. Read both before execution.

Website reference

Site-scoped tools take site_id. Use the identifier returned by list_websites, or the URL/domain of that same authorized website. A recognizable domain does not grant access to an unapproved website.

Ability ID

Use the full namespaced ability_id returned by list_abilities. For example, morawp/wordpress-core-get-post names a WordPress Ability; describe_ability names an MCP tool.

describe_ability takes this identifier in ability_name; executors take it in ability_id.

Example arguments for describe_ability:

JSON
{
  "site_id": "example.com",
  "ability_name": "morawp/wordpress-core-get-post"
}

example.com is a placeholder. Replace it with the authorized website reference returned by discovery.

Parameters

An executor receives the Ability inputs inside parameters. Follow the current inputSchema for required fields, types, accepted values, and identifiers. Do not substitute a title or URL for a numeric post ID, or invent field names based on a different release.

Read dryRunnable before adding dry_run to a write or dangerous executor. The read executor has no dry_run argument. An unsupported preview is not permission to repeat a mutation without it.

Results

Success data is specific to the Ability. Content may include HTML or builder data rather than a rendered page. Read the current outputSchema; a generic object schema does not promise a particular set of fields.

Failures can include structured execution and retry information. Keep the original code and inspect Errors. Do not turn a tool failure into a success summary.

See Agent workflow for the complete sequence.

MoraWP documentation