Rectus Content Access for MCP

No service operated by the plugin author is required. MCP requests are handled by WordPress through the bundled official MCP Adapter library. When an OAuth client uses an HTTPS URL as its client ID, Rectus Content Access for MCP retrieves public client metadata from that client-provided URL as described below.

During OAuth authorization, a connecting client may provide an HTTPS metadata URL as its client ID. Rectus Content Access for MCP then sends a server-side GET request to that exact URL with an Accept: application/json header. The response is limited to 64 KB and valid metadata is cached for one hour. No WordPress content, passwords, OAuth codes, or tokens are sent. The destination is selected and operated by the connecting MCP client, not by the plugin author, so the destination operator's terms and privacy policy apply.

No. The server-side plugin runs in PHP. An MCP client may have its own local runtime requirements, depending on the client.

No. The user signs in on the WordPress site and approves the connection in the browser. The MCP client receives short-lived OAuth tokens instead of the WordPress password.

Open Settings, Rectus Content Access for MCP and revoke the connection in the OAuth connections table. MCP clients may also clear or revoke their saved authorization.

Yes. Authorize the connection as a user without editing rights, a subscriber by default. That account can list posts, read a post with its content and public custom fields, read the terms assigned to it, list the enabled post types, and read the site information. Every create, update, edit, delete, media, menu, template, and CSS operation is refused, as is reading a draft or a private post, because WordPress itself limits those to the users allowed to see them. The media library cannot be listed either, since that needs the upload capability. On WordPress 7.1 or later the connection is offered only those five read abilities. The rest are hidden from ability discovery rather than listed and refused on use.

Codex and Claude Code should call the media upload ticket tool with the local image filename, byte size, MIME type, and attachment metadata. The tool returns a plugin REST endpoint and a short-lived, one-time token. The client then sends the image bytes directly as multipart form data. The image does not enter the model context, and no Application Password or second WordPress login is required. The ticket is valid for five minutes, is bound to the authorized WordPress user and expected file metadata, and is stored only as a SHA-256 hash. Repeating a completed request with the same ticket returns the existing attachment instead of creating a duplicate. MCP clients that cannot perform the direct HTTP upload may continue to use the Base64 media upload tool. Files already present in the WordPress uploads/mcp-inbox directory may use the media import tool without transferring image bytes through MCP.

Use the media list tool to search the WordPress media library and obtain the exact attachment ID, filename, and file-state SHA-256. To change the physical filename, call media rename with those values, a new filename, and confirm set to true. The extension and upload directory stay unchanged. Local original files, generated sizes, edit backups, and attachment metadata are renamed together. To delete media, call the media delete tool with the selected ID, matching filename, and confirm set to true. WordPress checks the authorized user's delete permission for the selected attachment. Renaming changes the public media URL. Deletion is permanent and removes the attachment and its generated files. Existing links to that media in post content are not rewritten, so clients should show the selected ID and filename to the user before confirming either operation.

Yes. Navigation menu abilities list and read classic menus, create and update menu metadata, add and edit ordered hierarchical items, delete childless items or whole menus with confirmation, and assign or clear registered theme locations. Mutations require the SHA-256 returned by the latest menu read, and all operations require the authorized user's edit_theme_options capability. To build or rework a large menu, navigation-menu-item-batch creates, updates, and deletes up to 100 items in one call. Every operation is checked before sequential saving starts. A later WordPress or reorder failure can leave earlier operations applied and returns their results with a new checksum, so read the menu again before retrying. Items created in the batch can be parents of later ones, and the response does not repeat every item unless requested.

Yes. Post text and Additional CSS keep WordPress revisions, and other changes are kept in the change history described below. post-revision-list lists the revisions of a post, post-revision-get reads one, and post-revision-restore brings back its title, content, and excerpt. Other data a revision holds is not restored, so a revision whose revisioned custom fields, such as footnotes, differ from the post is refused; restore that one in WordPress. Before post-update, post-edit, or a restore replaces the text of a post, the current text is saved as a revision, so even the text a post was created with can be restored. Revisions require the right to edit the post, and restoring a published post also requires publishing rights. A restore requires the current field checksums from post-get, so a post changed after it was read is not overwritten. When the site keeps no revisions, post-revision-list reports revisions_enabled as false. Additional CSS has its own revisions, described under the CSS question. For terms, classic menus and their theme locations, widgets, media details, page template files, block templates, global styles, and Navigation block navigations, the state before each change made through MCP is kept in a change history. change-list lists the changes with whether each can be undone, change-get shows the state before the change next to the current state, and change-restore puts the earlier state back after confirm: true. A restore is refused when the object has changed since, so later changes are undone first, newest first. A deleted term or menu is created again with a new ID, and the posts a deleted term was assigned to get it back. The restore is itself recorded and can be undone. Unlike the activity log, the change history stores values such as widget text or template markup, so reading and restoring an entry requires the capability the change itself needed. Entries are removed after 30 days, and the rectus_mcp_content_change_retention_days filter changes the period. States larger than 2 MB are not kept.

media-list returns the title, alternative text, caption, description, and meta_sha256 of each item. Pass up to 100 items with their meta_sha256 to media-update to change any of those four fields. Every item is checked before sequential saving starts. A later conflict or WordPress failure can leave earlier items changed and returns them in a partial error, so list the media again before retrying. Text the user may not save is refused rather than altered. Files and existing links in content are not changed.

Yes, when the SEO plugin keeps them in custom fields and an administrator allows their keys. Fields whose keys begin with an underscore are hidden from MCP. List the keys one per line under Protected custom fields in the settings, such as _yoast_wpseo_title and _yoast_wpseo_metadesc for Yoast SEO. Only users who can edit a post can then read or change those fields through post-get, post-create, and post-update. Keys that WordPress uses itself, such as those beginning with _wp_ or _edit_, are never opened. Rank Math fields have no leading underscore and are available already. All in One SEO keeps its data in its own database tables and is not supported. WordPress treats custom field keys without a leading underscore as public metadata, and readable posts return them through MCP. Do not store secrets or personal data in a public custom field; use a protected key and grant access only when it is intended.

Every successful change made through MCP, every partially completed batch, and every direct media upload: the time, WordPress user, client, operation, target, and the names of the fields given. Values such as post content are never stored. Only administrators can view the log. A failed database write fires the rectus_mcp_content_log_write_failed action. Entries older than 90 days are removed daily, and the rectus_mcp_content_log_retention_days filter changes the period. Uninstalling the plugin removes the log.

Yes. post-text-search finds exact, case-sensitive text, such as an old URL, in the posts the user can edit, and returns where and how often it occurs with the field checksums, without the full text. After the list has been shown to the user, post-edit-batch applies post-edit to up to 50 posts in one call, and post-update-batch applies post-update, for example to add a category. Each post-update item also requires the latest modified_gmt. Every item is checked before sequential saving starts. A later conflict or WordPress failure can leave earlier posts changed and returns them in a partial error, so read the posts again before retrying. The text each post had is kept as a revision.

post-duplicate copies one post into a new draft with its content, excerpt, parent, order, page template, terms, featured image, and the custom fields MCP can read. Custom fields hidden from MCP, including hidden ACF field references, are not copied. post-create and post-update accept menu_order for post types with page attributes, such as page, and post-get and post-list return it.

On a classic theme with widget areas, widget-list lists every area, including inactive widgets, with each widget's settings, and widget-update changes settings of one widget after matching its checksum. The widget sanitizes the values as Appearance > Widgets does, and a value it would alter is refused. Widgets are not added, moved, or removed. This requires the edit_theme_options capability. comment-list lists comments by status without email or IP addresses, and comment-moderate approves, holds, marks as spam, or trashes up to 100 comments after checking each comment's current status. Comments are never deleted permanently. This requires the moderate_comments capability.

Yes. block-template-list and block-template-get read the templates and template parts, such as the header and footer, and block-template-update changes their block markup, title, or description after matching the checksum from the latest read, either with the whole markup or with exact string edits. A template still read from the theme file gets its own site version, as saving in the Site Editor does; theme files are never written, and block-template-revert returns to the theme file. global-styles-get and global-styles-update read and replace the site's own styles and settings in theme.json format, and block-navigation-list, block-navigation-get, and block-navigation-update do the same for the navigations of the Navigation block. These abilities call the WordPress REST endpoints the Site Editor uses, so WordPress applies its own permission checks and sanitizing. A save that WordPress changes, for example by removing markup the user may not save, is reported. They require the edit_theme_options capability.

Yes, unless an administrator turns it off under the plugin settings. After a change made through MCP, a changed post clears its own pages, and a changed menu, widget, template, style, or term clears the whole site, once when the request ends. LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache, WP Fastest Cache, Cache Enabler, SiteGround Speed Optimizer, WP-Optimize, Breeze, Nginx Helper, and Hummingbird are supported through their own public functions. cache-purge clears selected posts, or the whole site for users with edit_theme_options, on request. Other caches can listen to the rectus_mcp_content_cache_purged action or be added with the rectus_mcp_content_cache_providers filter.

When MCP changes the slug, parent page, or anything else that changes the address of a published post, the old address answers with a 301 redirect to the current one, and so do the old addresses of its published child pages. When MCP renames a media file, the old addresses of the file and its generated sizes redirect to the renamed files, and media-rename lists the posts that still link to the old address, with the strings to pass to post-edit-batch. Redirects follow the post, so a later change does not create a chain, and an old address redirects only while nothing else uses it and the post stays published. redirect-list lists the redirects of the posts the user can edit, and redirect-delete removes one. Changes made outside MCP are not recorded. Media files redirect only when the web server passes requests for missing files to WordPress, as the standard WordPress rewrite rules do. Redirects can be turned off under the plugin settings, and uninstalling the plugin removes them.

site-health-get runs the Site Health checks that do not contact other servers and returns each result as plain text; checks that need a request are listed as not run. It requires the view_site_health_checks capability. error-log-get reads up to the last 500 lines of the PHP error log, the WP_DEBUG_LOG file or the error_log file of PHP, optionally only lines containing given text. It is off until an administrator allows it under the plugin settings, because the log can contain server paths and details of other plugins, and it is limited to administrators, or network administrators on multisite. The values of the database password and secret keys, and Bearer tokens, are masked.

Post delete moves an enabled post, page, or custom post type entry to the WordPress trash. It requires the exact ID, post type, modified time from a prior read, and confirm set to true. It never permanently deletes content and refuses the operation on sites where the trash is disabled.

Pass slug to post-list for an exact slug lookup. The separate search field uses WordPress content search. Post-create accepts an optional slug and returns the actual stored value. To change a slug, first call post-get, then pass its current slug as expected_slug and the new value as slug to post-update. A stale current value is rejected. A value that WordPress would silently suffix, such as adding -2 because another post already uses it, is also rejected with the suggested value in the error data. WordPress does not keep a published post without a slug. Passing an empty slug to post-update resets the manual value: published content regenerates the slug from its current title, while a draft may remain empty until publication. To delete the post itself and release its active slug, use post-delete. Its response reports the slug before trashing and the stored trashed slug.

Yes. The term list tool searches existing terms and returns their IDs, names, slugs, descriptions, parents, usage counts, and an editable-state SHA-256. Term create can add a category, tag, or custom taxonomy term, including an optional slug, description, and parent for hierarchical taxonomies. Term update can change those fields after matching the latest state checksum. Term delete permanently removes the selected term and may remove or reassign existing post relationships according to WordPress rules. It therefore requires the exact ID, taxonomy, latest state checksum, and confirm set to true. WordPress-protected default terms cannot be deleted. Every operation remains limited to taxonomies attached to an enabled post type and to the authorized user's native taxonomy capabilities.

Rectus Content Access for MCP derives the client configuration name from the site's domain and subdirectory path. For example, rectus.co.jp becomes wordpress-rectus-co-jp, while example.com/site-a becomes wordpress-example-com-site-a. This prevents different WordPress sites from overwriting each other's MCP client configuration.

Codex App and Codex CLI share MCP configuration. After the add command saves the server, Codex App may open the authorization screen automatically. Approve that screen once. Run codex mcp login only when authorization does not start; running both flows at the same time can create a duplicate OAuth connection.

Run the displayed claude mcp add command, then run claude mcp login. The login command opens the browser authorization screen directly, so there is no need to start Claude Code and run /mcp manually.

The OAuth discovery URLs under /.well-known/ are served through WordPress. Server rules that handle /.well-known/ before WordPress break new authorizations while issued tokens keep refreshing. Rectus Content Access for MCP reports this state in Site Health and in the Discovery metadata row on the settings screen. With plain permalinks, WordPress removes its rewrite rules from .htaccess, so on Apache these URLs need a rule that passes them to index.php, such as the standard WordPress rewrite rules.

Yes. For a site at https://example.com/magazine, the standard authorization server metadata URL is https://example.com/.well-known/oauth-authorization-server/magazine. The web server must pass this exact URL to that site's WordPress front controller while preserving the original request URI. Rules inside /magazine/ alone cannot handle requests outside that directory. The plugin does not modify domain-root server configuration automatically. The plugin also serves /magazine/.well-known/openid-configuration, which clients following the current MCP discovery order try after the standard URL, and keeps the existing /magazine/.well-known/oauth-authorization-server URL. A site at the domain root does not serve /.well-known/openid-configuration, leaving that URL to OpenID Connect provider plugins. The settings screen and Site Health check the standard URL. When only the OpenID configuration URL responds, Site Health reports a recommended improvement instead of a critical issue, because clients that use only the standard URL still cannot authorize. In a subdirectory multisite network installed at the domain root, the standard URL of a site such as https://example.com/site2 reaches the main site without a server rule. The main site answers it for that site when this plugin is active on the main site, either on both sites or network-wide.

Yes. Native MCP clients may select an available loopback port when authorization starts. Rectus Content Access for MCP follows RFC 8252 by allowing the port to differ for localhost, 127.0.0.1, and ::1 redirect URIs while still requiring the scheme, host, path, and query to match. All other redirect URIs require an exact match.

Yes, by the same rule WordPress applies to the block and classic editors. Content from a user who holds the unfiltered_html capability, which on a single site means an administrator, is stored as written and left to the content_save_pre filters that wp_insert_post() applies, so nothing is removed that the editors would have kept. Content from every other user is filtered with wp_kses_post(), which strips script elements, event handler attributes, and anything else outside the allowed list. Rectus Content Access for MCP additionally allows schema.org microdata attributes there, because WordPress core omits them and structured data lives in the post content. An MCP connection therefore never grants more reach than the approving WordPress user already had in the editor.

Rectus Content Access for MCP lists non-built-in post types that have a WordPress editing screen and support a title, editor, or excerpt. Administrators must explicitly enable each post type.

Yes. The post-get, post-create, and post-update tools expose public custom fields through the custom_fields object. Values may be strings, numbers, booleans, arrays, or objects; pass null during create or update to delete a field. When post-get returns a stored custom field, custom_field_definitions returns its label, type, description, required setting, available choices, and whether the definition came from registered WordPress meta, ACF, or unregistered post meta. Fields without a stored value are omitted. For safety, WordPress-protected meta keys, including keys beginning with an underscore, are not exposed or writable unless an administrator lists them as protected custom fields in the settings. Existing public ACF value rows are therefore available, but hidden ACF field-reference metadata is not created or changed. Plugin-specific validation, new field-reference setup, or side effects that only run through a plugin's own form or API are not emulated.

Yes. post-block-list parses stored content into a flat list with zero-based nested paths, a content SHA-256, and one SHA-256 per block. post-block-edit performs one replace_text, replace, insert_before, insert_after, or delete action. Both fingerprints must match, and the database is read again immediately before saving. To avoid silently restructuring content, edits are refused for non-canonical or freeform content, unregistered blocks, synchronized patterns, and locked blocks or post type templates. Replacement and insertion markup must contain exactly one canonical registered block. Text replacement is limited to one exact match in a leaf block. Nested insertion and deletion preserve the parent's inner block map, and the stored content is verified after saving.

Yes. The page-template-list, page-template-get, page-template-create, page-template-update, and page-template-delete tools manage only root-level page-*.php files with a Template Name header in the active theme. They cannot read or modify arbitrary theme PHP files such as functions.php. Only users with WordPress theme-editing permission can use these tools. Updates and deletions require the SHA-256 returned by a prior read or list, so a changed template is never overwritten or deleted silently. Deletion also requires confirm: true and is refused while the template remains assigned to a non-trashed page. The post-get result includes page_template. Pass a managed template filename to the page_template field of post-create or post-update to assign it to a page, or pass default to clear the assignment.

Yes, through Additional CSS under Appearance > Customize. custom-css-get reads it with its SHA-256, custom-css-update replaces it, custom-css-edit replaces exact strings the way post-edit does, and custom-css-delete empties it when confirm: true is supplied. Theme files are never changed, and CSS containing a closing style tag is refused. The CSS that a change replaces stays in the WordPress revisions, which custom-css-revision-list, custom-css-revision-get, and custom-css-revision-restore list, read, and bring back. When the site keeps no revisions, custom-css-get reports revisions_enabled as false and replaced CSS cannot be restored. Changes require the SHA-256 from the latest read, and every CSS operation requires both edit_theme_options and edit_css, which on a single site only administrators hold. On a block theme WordPress still prints this CSS, but the Site Editor edits separate CSS in the global styles, so CSS saved through MCP does not appear there. custom-css-get and site-info-get report is_block_theme so a client can tell the user.

English source strings are included. After publication on WordPress.org, community translations are provided through translate.wordpress.org and delivered as WordPress language packs.