These prompts work with any connected assistant. Complete your first task first, then replace <project-id> and other placeholders with your actual values. Each workflow lists the API-key scopes it needs; the key must also have access to the selected project.

Investigate an error

Scopes: projects:read.

Investigate HTTP 500 errors on Agiler project <project-id> between <start time and timezone> and <end time and timezone>. Check the project status and inspect relevant request and application logs. Summarize recurring errors, include timestamps, and distinguish evidence from possible causes. Propose next steps without changing the site.

The assistant can use projects_get and logs_list, narrowing the time range and search filters as needed. If logs are incomplete, the report should say so. Redact credentials and personal data before sharing excerpts outside the conversation.

Review usage

Scopes: projects:read.

Review usage for Agiler project <project-id> for <date range and timezone>. Summarize requests, bandwidth, compute, and storage. Identify the busiest intervals and compare them with the preceding period if data is available. Explain any gaps. Do not change the project.

The assistant uses usage_get for supported metrics and time buckets. Treat the output as an operational review; use billing statements for actual billed charges.

Inspect WordPress plugins

Scopes: projects:read, projects.wp:execute.

On Agiler project <project-id>, use WP-CLI to list plugins with their versions, activation status, and available updates. Report the findings without installing, updating, activating, or deleting anything.

The assistant can call wp_run with plugin list --format=json. The execution scope permits changes too, so keep the request limited to inspection. See Managing WordPress with AI for maintenance workflows.

Review a file change before applying it

Scopes: projects:read for inspection; add projects.files:write and projects.backups:write before applying a change with a backup.

Read <file-path> on Agiler project <project-id> and propose a change to <desired behavior>. Explain the proposed diff and how to verify it. Do not write the file until I approve the change.

Once you have reviewed the proposed change:

Create a backup of project <project-id> and confirm it completes. Then apply the approved change to <file-path>, using its current ETag to protect against concurrent edits. If the file has changed since review, stop and show me the new diff. Read the result back and report verification results.

The relevant tools are files_get, files_write, backups_create, and backups_list. A file write through MCP changes the hosted file; it does not create a local commit. HTTP 412 means the file changed and needs another review.

Check backup readiness

Scopes: projects:read; add projects.backups:write to create a backup.

Review the backup policy and recent backups for Agiler project <project-id>. Tell me whether a recent completed backup is available. Do not restore or delete anything.

Before an approved maintenance task, follow up with:

Create a backup for project <project-id>. Check its progress and report the identifier and creation time once it completes. Do not start maintenance if the backup fails or is still pending.

Creating a backup and restoring one are separate actions. Review Restore a backup before recovery work.

Read a database summary

Scopes: projects:read, projects.sql:execute.

For Agiler project <project-id>, inspect the database schema with read-only SQL and summarize counts of published posts by post type. Discover the actual table prefix rather than assuming wp_. Set read_only to true for every statement and do not modify data.

The assistant should use sql_run with read_only: true and aggregate results where possible. For longer operations, use async: true and poll sql_get with the returned statement identifier. See troubleshooting if the client times out.

Make recurring work consistent

Save the project identifier, approval expectations, and verification steps in project instructions. Keep task-specific details in the conversation and credentials in the client’s configuration.