Documentation

Getting Started

Open for Agents Core 0.3.49 is free and publicly available from WordPress.org. It requires no Open for Agents account, AI API key, paid licence, or hosted service.

Core publishes the WordPress content, eligible forms, and WooCommerce tools you review for compatible AI agents. Supported changes are enabled separately and require trusted approval of the exact action. The optional Assistant remains a separate add-on.

1. Install Open for Agents: AI Toolkit with MCP. Open the official WordPress.org listing, select Download, then upload and activate the ZIP from Plugins → Add Plugin in WordPress. You can also search for the formal plugin name from Add Plugin. The optional Open for Agents Assistant 0.1.11is a separate package and does not include hosted model access.
2. Enable Standard Tools. Turn on the built-in, deterministic, read-only baseline. This immediately adds get_site_info, list_post_types, get_navigation, list_posts, search_posts, get_post, and get_terms. On WooCommerce sites it also adds woo_search_products, woo_get_product, and woo_get_product_categories.
3. Review the baseline catalog. Standard Tools appears in the same effective catalog that will later hold any discovered capabilities. Confirm the built-in read-only tools you want available before you scan anything.
4. Validate before publishing. Review each capability for type, risk, confidence, and auth requirements. You can validate Standard Tools without running a scan. Use the Action Types Reference to interpret labels and flags.
5. Choose what to publish. Select public_minimal or public_standard for the public surface, then enable publishing and run diagnostics. Use private_full only inside an access-controlled environment; it exposes more metadata but does not authorize an agent to execute anything. Until public publishing is enabled, public endpoints return 404 by design. See Publication Tiers for tier-by-tier guidance.
6. Run an optional discovery scan later. Use Key Page Scan or Broader Discovery Scan when you want forms, AJAX routes, plugin-specific flows, selectors, and richer browser runtime bindings that are unique to your site.
7. Review integrations separately. For Contact Form 7 or WPForms Lite, confirm the provider detector, supported field schema, publication support, tested version, and limitations in the Integrations matrix. Tested form submission is limited to supported single-page forms, irreversible, disabled by default, and enabled per reviewed form—not for every form from a provider.

Publish for the first time

1. From Setup, enable Standard Tools and confirm the baseline capabilities appear in Review.
2. If WooCommerce is active, confirm product search, product lookup, and product category tools were added automatically.
3. If an established form provider is active, confirm only the intended forms were detected. Keep transactional execution off until each form's fields, notifications, redirects, and feeds have been reviewed.
4. In Review, confirm the built-in capabilities you want in scope and disable anything you do not plan to publish.
5. In settings, choose your public tier (usually public_standard for practical public utility, or public_minimal for discovery-only exposure). Keep private_full inside an access-controlled environment.
6. Open Publish and review Tier Preview counts. Confirm high-risk or auth-required capabilities are not in your chosen public tier.
7. Run diagnostics while publishing is still off. Expected behavior: public endpoints return 404 by design.
8. Enable publishing and run diagnostics again. Expected behavior: endpoint checks report OK, and your public map is available via the public URL in Publish.
9. Run a Key Page Scan or Broader Discovery Scan later when you want deeper site-specific discovery, then validate the newly discovered items before republishing.

Before you call the site ready

Setup, Review, Validate, and Publish describe one readiness state, not four independent checklists. Publishing can be active without being current, but it should not be presented as complete when the selected public catalog has changed, validation is stale or partial, or public diagnostics disagree with the configured state.

• A sampled validation run reports only the endpoints it exercised. It does not imply that every catalog tool passed.
• Catalog, tier, runtime, or host changes make the previous validation evidence stale until the affected checks run again.
• Treat publication as ready only when every selected public surface has current validation evidence and the public diagnostics agree.