ModelGain Agent Readiness Audit is a local, read-only diagnostic layer for WordPress sites that need to be inspected or operated by AI agents.
It answers five practical questions:
The plugin produces evidence-based findings instead of automatically changing the site. Every finding has a stable ID, domain, maturity, severity, status, evidence, explanation, remediation guidance, reference, and affected surface.
Choose the profile that matches the intended agent:
Rules that do not apply to the selected profile are marked Not Applicable and do not reduce the profile score.
The plugin itself supports WordPress 6.6 and newer. The native WordPress Abilities API was added in WordPress 6.9, so applicable Act/Manage findings correctly report that capability as unavailable on older WordPress versions rather than pretending the API exists.
The readiness score is separate from evidence confidence.
This prevents a network limitation or missing evidence from being misreported as a site defect.
The audit does not:
Network probes are limited to the site’s own exact origin. Redirect following is disabled and response size and timeout are bounded.
On WordPress versions that provide the Abilities API, the audit inspects registered ability metadata and samples anonymous permission behavior only when WordPress can normalize and validate a default/no-input sample first. If a valid sample cannot be established, the result is Unknown rather than guessed. It does not execute third-party abilities.
When the official WordPress MCP Adapter is present, the audit reports locally observable integration evidence. The plugin does not install or operate an MCP server.
The plugin also registers three private, manage_options-gated abilities for its own audit/report workflow on compatible WordPress versions. They are not exposed publicly to MCP.
The audit can report supplemental llms.txt and WebMCP signals, but does not treat either as a mandatory web or WordPress standard. Their absence does not create a scored readiness defect.
The latest full report and up to five compact historical summaries are stored locally in WordPress options.
You can:
WP-CLI examples:
wp modelgain agent-readiness audit --profile=read --format=table
wp modelgain agent-readiness audit --profile=act --format=json
wp modelgain agent-readiness audit --profile=manage --format=markdown
Site Health shows a summary of the latest stored report. Opening Site Health does not trigger a new network audit.
The core exposes extension points for policy packs, reporting, and future commercial add-ons without requiring a fork:
modelgain_agent_readiness_http_args adjusts bounded same-origin request settings. Core GET-method, credential, body, redirect, no-streaming, TLS-verification, timeout, response-size, and origin protections are reapplied after this filter.modelgain_agent_readiness_facts extends collected evidence before rule evaluation.modelgain_agent_readiness_findings extends or deliberately replaces evaluated findings.modelgain_agent_readiness_score_cap adjusts the policy/safety score cap.modelgain_agent_readiness_report filters the final report before local persistence.modelgain_agent_readiness_history_limit adjusts compact local history retention, bounded by the core.modelgain_agent_readiness_audit_completed fires after a report has been stored.Extensions are responsible for preserving stable finding IDs, evidence semantics, least-privilege behavior, and the core privacy boundary.
ModelGain Agent Readiness Audit does not send telemetry or data to a ModelGain service.
The audit can make bounded HTTP GET requests to the same origin configured as the site’s WordPress home URL. These requests do not include WordPress authentication cookies, Authorization headers, URL-embedded credentials, request bodies, or customer data. The plugin does not follow redirects.
For abilities explicitly marked public, the audit may invoke their permission callback under an anonymous WordPress user context after a default/no-input sample has passed the ability’s own input normalization and validation. Permission callbacks are inspected only; third-party execute callbacks are never run.