Documentation

Getting Started

Download Open for Agents Core 0.3.54 for free from WordPress.org. You do not need an Open for Agents account, AI API key, paid licence, or hosted service.

Already installed? Set up form preparation so an agent can fill a form for the visitor to check and send.

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 is 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.

Let an agent fill a form, then let the visitor send it

Core 0.3.54 supports owner-reviewed form preparation for WPForms Lite and Contact Form 7. A compatible WebMCP browser agent fills the selected form; the visitor checks or edits the answers and presses its normal Send or Submit button. No Open for Agents account, API key, or Assistant add-on is needed. Browser support for WebMCP is required; this does not make every browser assistant compatible.

1. Publish a page with one supported form. The selected form must appear exactly once on that published page. Start with a simple, single-page WPForms Lite or Contact Form 7 form.
2. Turn on browser access. In Open for Agents, open Browser & Assistant compatibility. Select Enable built-in WordPress tools and Enable the WebMCP browser runtime, then Save compatibility settings. Use Publish & verify to review and publish your public tools. Transactional tools are not required for preparation.
3. Choose the exact form and page. Return to Browser & Assistant compatibility and find Form preparation. Check the listed fields, required answers, limits, and choices. Select the intended form and page, then press Save and review form preparation.
4. Try filling without sending. Open that page with a compatible browser agent and ask it to fill the form. Check and correct its answers. Only the visitor should press Send or Submit; use the form provider's confirmation to check the outcome.

If the browser reports that its tool was cancelled after you pressed Send, check the form's confirmation before trying again. That browser message can appear after a successful submission; it does not mean nothing was sent. Do not resend solely because of it.

Changes to reviewed fields, limits, required answers, or choices pause preparation until you review and save again. Clear the form's checkbox and save to turn it off. Preparation supports only the two providers above. Uploads, payments, accounts, checkout, and other unsupported fields are excluded; see the integration limits.

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.