# WordPress tool failed

> Find the cause of WORDPRESS_MORAWP_TOOL_FAILED and decide what to do before retrying.

`WORDPRESS_MORAWP_TOOL_FAILED` means WordPress or the MoraWP Plugin returned a
tool failure. It is a category of error, not the underlying diagnosis. The code
alone does not tell you whether an identifier was wrong, an Integration rejected
the request, or a WordPress operation failed.

<warning>

For an action that can change your website, an error does not prove that nothing
changed. Check WordPress before repeating the action. A second attempt could
create duplicate content or repeat a partial change.

</warning>

## 1. Keep the error details

Ask your Agent for the tool response from the failed call, including the
message, Ability name, target website, and any request identifier. Note the
time and the installed MoraWP Plugin and relevant Integration versions.

Use **Activity** to identify the corresponding execution. Include additional
WordPress error details only when the response actually provides them; some
failures return a generic message.

Do not share tokens, credentials, authorization headers, or private page content
when asking for help.

## 2. Check what actually happened

For a **read**, open the requested item in WordPress. Confirm that it exists on
the same website and that you used the correct identifier and item type.

For a **change**, inspect the specific result: the post's current values, created
items, affected settings, or relevant files. If you cannot establish the state,
stop further changes and ask the website administrator to investigate.

Structured Agent responses may include `mayHaveExecuted`, `outcomeKnown`, and
`retrySafe`. A known failure response is not a guarantee that a multi-step
operation left the website unchanged. Do not override `retrySafe: false` by
automatically repeating the call.

## 3. Discover the current Ability

Ask the Agent to inspect the site's current inventory and the selected Ability's
input schema before changing the request:

```text
Inspect the failed MoraWP request without repeating it. Use
morawp_list_abilities to find the Ability on this website, then call
morawp_get_ability_info for its current input schema. Compare the failed
parameters with that schema and explain the WordPress error if the response
includes one. Do not run a write or remove dry_run automatically.
```

These are MCP tools, not Ability IDs. Call them directly rather than passing
their names to `morawp_execute_ability`.

### Reading a post or page

For a failed `morawp/wordpress-core-get-post` request, obtain the identifier
from the same website's post or page list. A WordPress ID from another website,
a URL, or a title is not interchangeable with the identifier required by the
current schema.

### Reading Elementor content

For `morawp/page-builders-elementor-get-content` or
`morawp/page-builders-elementor-get-schema`, confirm that Elementor is installed
and detected on that website. For content reads, verify the selected item is
the Elementor document you intended to inspect. Use the discovered schema;
do not substitute a remembered parameter name from a different release.

### Running PHP or WP-CLI

For PHP or WP-CLI failures, inspect the actual code or command and its returned
error. These tools can affect the website. Ask an administrator to check the
environment or operation rather than running another broad command to guess
the cause.

## 4. Retry only after checking

For a read, correct the confirmed input or compatibility problem and retry that
specific request. For a change, first establish what completed and what remains,
then agree on the next action with the person responsible for the website.

Updating the MoraWP Plugin may resolve a confirmed compatibility problem, but
this generic error alone does not prove that an update is the fix. After an
update, discover the site's Abilities again.

**Success check:** the intended read returns the correct item, or the intended
change is verified in WordPress. An Agent's summary alone is not that check.

## Errors with a different next step

<table>
<thead>
  <tr>
    <th>
      Code
    </th>
    
    <th>
      Meaning and next step
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        AGENT_ABILITY_MODE_DENIED
      </code>
    </td>
    
    <td>
      The Ability is outside this Agent's access mode. Review access in MoraWP; do not retry unchanged.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        MCP_DRY_RUN_UNSUPPORTED
      </code>
    </td>
    
    <td>
      The Ability does not support a dry run. Do not silently remove <code>
        dry_run
      </code>
      
       from a change; review the operation first.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        MORAWP_PLUGIN_INCOMPATIBLE
      </code>
    </td>
    
    <td>
      The installed plugin does not meet the Ability's version requirement. Follow the version in the response and update before rediscovery.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        MCP_ABILITY_NOT_FOUND
      </code>
    </td>
    
    <td>
      Discover the site's current inventory and use the returned namespaced Ability ID.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        WORDPRESS_EXECUTION_OUTCOME_UNKNOWN
      </code>
    </td>
    
    <td>
      MoraWP cannot confirm the result of a dispatched change. Inspect the website before any retry.
    </td>
  </tr>
</tbody>
</table>

## When to ask for help

If a valid read still fails, prepare the website, time, Ability ID, request
identifier if available, plugin and Integration versions, and the non-sensitive
error message. If a change may have partially completed, include what you
verified in WordPress and pause further attempts until its state is understood.

Review [Activity and AI Actions](/guides/activity) to understand why a dispatched
attempt can count even when WordPress returns an error.