A good workflow names the site, action and expected result. These examples use available REST tools; they do not promise compatibility with every WordPress plugin.
“Use my Studio site. Call site_status, then wordpress_read /wp/v2/posts with status=draft, per_page=10 and page=1. Return the post IDs and titles. Make no changes.” Confirm the returned site identity before using the draft list.
When changes are allowed, call wordpress_request with method POST, route /wp/v2/posts, and params containing title, content and status=draft. Read /wp/v2/posts/RETURNED_ID afterward. Publishing requires a separate explicit instruction and the user’s publish capability.
Use discover_routes and identify the plugin’s namespace and supported methods. Test a read endpoint first. Dashboard controls without REST routes need another supported integration; do not infer an API from the dashboard appearance.
Specify the exact item and whether it should move to trash or be permanently deleted. Native endpoint permissions still apply. A tool’s destructive hint is information for the client, not a server-side approval dialog or automatic backup.