Title: Webmastery Site Toolkit for MCP Author: Daniel Boring Published: 10 Juli 2026 Last modified: 14 Oktober 2026 --- Cari plugin ![](https://ps.w.org/webmastery-site-toolkit-for-mcp/assets/banner-772x250.png?rev =3603125) ![](https://ps.w.org/webmastery-site-toolkit-for-mcp/assets/icon-256x256.png?rev =3603125) # Webmastery Site Toolkit for MCP Oleh [Daniel Boring](https://profiles.wordpress.org/deboring/) [Unduh](https://downloads.wordpress.org/plugin/webmastery-site-toolkit-for-mcp.3.0.0.zip) * [Detail](https://id.wordpress.org/plugins/webmastery-site-toolkit-for-mcp/#description) * [Ulasan](https://id.wordpress.org/plugins/webmastery-site-toolkit-for-mcp/#reviews) * [Instalasi](https://id.wordpress.org/plugins/webmastery-site-toolkit-for-mcp/#installation) * [Pengembangan](https://id.wordpress.org/plugins/webmastery-site-toolkit-for-mcp/#developers) [Bantuan](https://wordpress.org/support/plugin/webmastery-site-toolkit-for-mcp/) ## Deskripsi Webmastery Site Toolkit for MCP adds **70+ permission-aware abilities across 16 areas** that AI agents and MCP clients can call through the official [MCP Adapter](https://wordpress.org/plugins/mcp-adapter/) plugin. It works with popular MCP clients including Claude, ChatGPT, GitHub Copilot, and Gemini. The MCP Adapter provides the transport layer. This plugin provides the site-management vocabulary: posts, pages, media, comments, taxonomy, custom post types, post meta, content hygiene, SEO checks, public webmaster verification, Google Site Kit diagnostics, site info, health, security, users, plugins, database, performance, and backup status. Core editorial workflows work well with a dedicated Editor service account. Sensitive workflows such as plugin management, user auditing, site health, database health, backup status, performance status, and security audits require a separate Administrator service account. Highlights: * Create, update, list, restore, trash, bulk publish, and bulk trash posts and pages. * Inspect Gutenberg blocks and patch one targeted block or content section in posts, pages, and eligible custom post types instead of rewriting the full content. * Manage categories, tags, comments, media metadata, featured images, and public image URL uploads. * Discover eligible public custom post types and use generated CRUD abilities for each one. * Read, update, and delete safe post meta, including supported Yoast SEO and SEOPress metadata fields. * Run content hygiene checks for orphaned media, missing featured images, and stuck scheduled posts. * Inspect safe site and current-user context, with runtime environment details reserved for Administrator accounts. * Audit plugins, administrator accounts, backups, performance settings, database bloat, site health, and security posture. * Analyze SEO metadata and public Google/Bing webmaster verification proof. * Inspect Google Site Kit setup, modules, current-user permissions, and same-site PageSpeed summaries without exposing OAuth credentials or changing Site Kit settings. All abilities enforce WordPress capability checks. If the connected account cannot perform the equivalent WordPress action, the ability fails instead of bypassing WordPress permissions. List abilities for posts, pages, custom post types, media, and SEO scores also filter each returned object before exposing full details, so private, trashed, draft, pending, and scheduled content follows WordPress object/ status permissions. 3.0.0 is a breaking upgrade from 2.6.0. Update clients for bounded pagination, summary defaults, strict inputs, separate metadata writes, destructive confirmation/previews, canonical errors and database identifier privacy before upgrading. Affected successful records add untrusted_fields markers without rewriting stored values, HTML or block markup. These hints are not prompt-injection prevention; see the migration and agent- safety FAQ below. For full setup instructions, ability tables, and the deeper security model, visit: https://www.virtuallyboring.com/webmastery-site-toolkit-for-mcp/ ## Tangkapan Layar [[ [[ ## Instalasi 1. Install and activate the [MCP Adapter](https://wordpress.org/plugins/mcp-adapter/) plugin first. 2. Install **Webmastery Site Toolkit for MCP** from **Plugins > Add New** by searching for the plugin name, or upload the plugin zip from **Plugins > Add New > Upload Plugin**. 3. Activate **Webmastery Site Toolkit for MCP** from the WordPress Plugins screen. 4. Create a dedicated WordPress user for your MCP client. Use Editor for day-to-day content work. 5. Create an application password for that user from the WordPress user profile screen. 6. Configure your MCP client with the site endpoint, username, and application password. 7. Ask your MCP client to call `mcp-adapter-discover-abilities` and confirm the `webmastery- site-toolkit-for-mcp/*` abilities appear. ## Tanya Jawab ### Has released 2.6.0 been checked against MCP Adapter 0.7.0? Yes. The unchanged 2.6.0 production ZIP passed isolated local HTTP checks against Adapter 0.6.1 and 0.7.0 on WordPress 7.1.2/PHP 8.2 and WordPress 6.9/PHP 8.1. All 75 native-install abilities were discovered and projected as individual tools. Representative reads, draft writes, permission denials and errors passed, including the 2026-07- 28 sessionless protocol. These checks do not cover every callback or optional provider. No live or staging site was used. This historical result is separate from 3.0.0 release-package validation. Assessment: https://github.com/DanielBoring/webmastery-site-toolkit-for-mcp/blob/ main/docs/mcp-adapter-0.7-assessment.md ### Was the pre-release 3.0 snapshot tested with the new Adapter? An independent production ZIP from main commit 115b577bf59e4d3c33b0ccc78d9317e09efab3e1 passed focused isolated protocol tests against Adapter 0.6.1 and 0.7.0 on WordPress 7.1.2/PHP 8.2 and WordPress 6.9/genuine PHP 8.0.30. Those tests cover the 85-ability fixture inventory, canonical errors, strict inputs, bounded reads, permissions and bulk destructive safeguards. That historical package carried the 2.6.0 version header. It does not certify the separately versioned 3.0.0 package or every callback; no dependency-baseline promotion is implied. The assessment records release-package validation separately. ### What changes for clients upgrading to 3.0.0? Failures now use success:false and an error object with code, reason, message, and object-shaped details. Seven categories replace mixed codes; precise legacy reasons move to reason. MCP Adapter 0.6.1 tool errors carry this JSON in one text block with isError:true; structuredContent is omitted on HTTP (internally null). Error normalization preserves successful payloads and gateway success wrapping; separate metadata projections and additive untrusted_fields markers change success contracts as described below. Bulk summaries are non-atomic; inspect every item even when the batch succeeds. Provider diagnostics are redacted without bypassing capability checks. WordPress 6.9 / PHP 8.0 minimums are unchanged. Metadata/SEO reads now enforce effective object/key authorization; migration never grants capabilities. Migration matrix and examples: https://github.com/DanielBoring/webmastery-site-toolkit- for-mcp/blob/main/docs/3.0-migration.md Permanent media/category/tag deletion and both bulk post operations now require the exact JSON boolean confirm:true, including bulk previews. Bulk requests accept at most 100 raw IDs and process duplicates once; dry_run:true reports would-act successes without mutation. These explicitly documented changes add a preview marker and media in_use boolean to successful responses. Post/page/custom-post-type, media, orphan-media, and score lists now return candidate windows with items, page, per_page, and next_page instead of exact total/total_pages. Continue until next_page is null, including after empty or short windows. Existing roles and object/key permissions still apply; per_page caps candidates at 100, not visible results. Post/page/custom-post-type and revision lists default to fields:”summary”, which omits content only. Request fields:”full” for unchanged stored content. Excerpts and other values are unchanged; get/write responses stay full. These are not transactional snapshots or constant-time database queries, and summary payloads have no universal byte limit. Orphan-reference queries are batched over bounded candidates; scan errors still block forced media deletion. Authorized records include untrusted_fields, an array of field names relative to that record. Summary output never marks omitted content. Markers preserve stored values and nested maps; they do not sanitize data, grant capabilities, prove human approval, or guarantee prompt-injection prevention. Compact trash results and errors remain unmarked. Pagination whose offset or successor cannot fit a PHP integer is rejected before querying. Candidate/priming SQL failures return an error, not an empty end-of-list. Fresh SQL failures invalidate the current site’s post-query cache generation to prevent cached false empty results; normal successful-query caching is unchanged. Failures are retained even when later native priming reads clear the last database error. The check adds no queries and preserves zero-query cache hits with stale errors. ### Which AI clients and MCP hosts work with this? Any MCP client that can reach your site through the MCP Adapter works. This includes Claude (Desktop and Code), ChatGPT, GitHub Copilot, Gemini CLI, Windsurf, and Codex. Most local clients connect through the `@automattic/mcp-wordpress-remote` bridge. ### Does this work without the MCP Adapter plugin? No. This plugin extends the MCP Adapter plugin and depends on it for MCP transport and ability registration. ### Does this work on WordPress.com? It requires a WordPress site where custom plugins can be installed. Self-hosted WordPress and managed hosts that allow custom plugins should work. WordPress.com Free, Personal, and Premium plans do not allow custom plugin installation. ### Which WordPress role should my agent use? Use a dedicated Editor account for normal content workflows: posts, pages, taxonomy, comments, media, revisions, content blocks, and content hygiene. Comment updates, approval, trash, and spam actions require both moderate_comments and edit_comment for the specific comment. A custom moderator role also needs the mapped edit permissions for the comment’s post; owning a post alone does not remove the moderate_comments requirement. Missing-comment failures uniformly use not_found code and reason. Invalid or nonpositive IDs cannot fall back to a global comment or silently select another ID. Listing and reply permissions are unchanged. Use a separate dedicated Administrator account only when you need Administrator- only workflows such as runtime environment details, plugin management, user access audits, site health, database health, performance status, backup status, security audits, or site-wide SEO overview. ### Why use a dedicated account? A dedicated account limits the agent to the role you choose, makes activity easier to attribute, and lets you revoke access by deleting the application password or user. ### Do I need Yoast SEO or SEOPress? No. Structural SEO checks still work without either plugin. Yoast-specific metadata and score abilities require Yoast SEO. SEOPress-specific metadata inspection and writes require SEOPress. ### Do I need Google Site Kit? Only for the optional Site Kit status, module, permission, and PageSpeed abilities. The integration is a read-only compatibility adapter over Site Kit’s internal REST routes, which Google does not publish as a supported third-party API. It checks route availability at runtime and preserves Site Kit’s own setup, dashboard-sharing, and datapoint permissions. Module, permission, and PageSpeed abilities require the WordPress read capability before any upstream work, plus the exact Site Kit route’s permission check. Missing providers, routes, or callable permission checks deny access. Read alone is not sufficient; a Subscriber is allowed only when Site Kit also authorizes that user. Status retains its separate manage_options requirement. The official Site Kit 1.187.0 routes were inspected without Google data calls on a disposable installation. Module-list and permission routes require Site Kit splash or dashboard access; this version’s PageSpeed route resolves to Site Kit setup or post-insights access. Effective checks also depend on setup, authentication, sharing, and network state. This does not establish compatibility for every historical version or grant ordinary Subscribers dashboard access. See the repository README for exact capability names and version-specific sources. PageSpeed requests are limited to URLs on the current site and are processed by Google’s PageSpeed service through Site Kit. Responses omit OAuth scopes and proxy details, module owner identities, screenshots, third-party entity lists, and full Lighthouse payloads. ### Can Subscribers check public webmaster verification? Yes. The webmaster verification check requires `read` and checks public homepage meta tags, Bing XML, DNS TXT, robots.txt, and sitemap reachability without Google or Bing API credentials. It does not confirm account ownership. WordPress-only Site Kit installation and activation details require `activate_plugins`; other callers receive neither private projection, and their summary counts only public checks. Public results, including failures and unknowns, are cached for 60 seconds per site, home URL, and result schema. Warm calls reuse HTTP/DNS results; privileged plugin state is inspected separately on each call and never stored in the public cache. Concurrent cold misses or early cache eviction can repeat requests, so this is not a strict rate limit. ### Are write operations safe? Write operations go through WordPress APIs and capability checks. Posts, pages, and custom post type items move to trash rather than being permanently deleted. Media deletion is permanent. Block and partial-content patching can use hashes so stale or ambiguous edits fail safely. In 3.0, permanent media/term deletion and both bulk operations require confirm:true. Bulk dry_run:true performs the same eligibility checks without writes, including when trash is disabled, and adds data.dry_run:true. Strings and numbers cannot substitute for boolean safety flags. Batch success does not mean every item succeeded; inspect successes and failures. Media deletion checks known featured-image and literal content URL/GUID references; a hit requires force:true. Permission and reference-query failures still deny forced deletion. The successful in_use flag describes known references, not universal non- use: external sites, custom storage, transformed URLs, and concurrent edits can be missed. These interlocks neither grant capabilities nor prove human approval; clients still need independent authorization for the exact action and IDs. Publishing, scheduling, or marking content private requires the relevant WordPress publish capability. User login/email fields and author login names are not exposed to lower-privilege list responses. ### How are standalone metadata permissions enforced? The standalone get-post-meta and update-post-meta abilities require edit_post_meta for the actual object and key; delete-post-meta requires delete_post_meta. All three also require edit_post and preserve the existing protected-key eligibility rules. Upserts include absent and unchanged values, and deletions check authorization even when the key is absent. Explicit denied reads return forbidden; listings omit denied keys. Requiring edit permission for reads is a conservative plugin policy, not a general WordPress read-meta capability. Global/subtype registrations and effective WordPress capability filters are respected, including explicit primitive grants from providers. The compatibility default for genuinely unregistered supported SEO keys does not bypass those filters. Successful response shapes are unchanged. In 3.0, post/page/custom-post-type create and general update reject metadata containers and all SEO aliases before writes, even when empty or null. Create a draft without metadata, write each exact key through update-post-meta, verify the results, and then publish with a plain update. These separate calls are not atomic; keep the draft unpublished if any write fails. Separate SEO inspection and analysis omit denied fields and report unavailable_fields; they never read a denied key. Analysis skips unevaluable checks, and score pagination includes only authorized objects and score keys. Generated Yoast head output is unavailable; URL-only head requests return unsupported. This conservative read policy requires effective edit_post and edit_post_meta, not just permission to see the public page. SEO overview samples at most 100 published posts/pages ordered by ID. Missing counts and up to 20 IDs per field refer only to authorized sampled observations; observed_count is that field’s authorized denominator, not a sitewide count. Zero observations are no evidence, not an all-clear. See the repository’s 3.0 migration guide for every removed alias and its exact metadata key. ### Can metadata and media text contain backslashes? Yes. Standalone post metadata and media titles, captions, and alt text preserve backslashes through WordPress storage. Use normal JSON escaping, not an extra WordPress slashing layer. Existing text, HTML, and SEO-provider sanitization still applies; responses reflect sanitized stored values. Use update-post-meta with an exact key: public keys also support JSON-compatible arrays and objects; supported protected SEO keys retain scalar normalization. ### What are the rules for page and custom post type parents? A positive parent must exist, have the same hierarchical post type, and be editable by the connected account. A requested parent cannot create a cycle or lead into an existing cyclic hierarchy. Invalid or unauthorized assignments fail before any of the request’s content, status, metadata, or taxonomy changes are saved. Set parent to 0 to detach an item. Omit parent to leave it unchanged on update. Reassigning the same parent still requires permission to edit that parent, but not every ancestor. Custom post types use their registered edit capability and WordPress capability filters. In 3.0, built-in posts and nonhierarchical custom post types reject any supplied parent field, including zero or null. Omit it on those types. Pages and hierarchical custom post types retain detach-to-zero and omitted-parent behavior, with the existing authorization and cycle checks. ### Are ability inputs strict? 3.0 closes fixed-property input objects and validates types, exact enums, required fields, numeric bounds, and array items before raw permission or execute callbacks. Unknown keys, numeric strings used as IDs, coerced booleans, and unadvertised null values are refused. Omit optional values to retain defaults. Input-free abilities accept omitted input or an empty object. Registered execution retains core input validation and then applies strict types before permissions, so numeric-string IDs and boolean-like flags report invalid_input rather than permission denial. Direct destructive preflight reasons and real capability denials are unchanged. Core normalization and lifecycle hooks remain active. Registered permission preflight honors a declared object-root default for omitted or null input, including empty database-health requests normalized by the Adapter. It does not replay normalization filters, grant capabilities, expose table names, coerce non-null inputs, or default nested null values. Directly invoked raw callbacks keep their existing strict checks. Standalone metadata JSON values and dynamic registered-taxonomy maps remain open where intended; existing metadata and taxonomy authorization still applies. WordPress handles other schema keywords such as URI formats. Output schemas are deferred to avoid constraining legitimate provider/error response shapes. No capabilities or external services are added. ### How are image URL uploads limited? Image URL uploads require upload_files and, when attaching to a post or page, edit_post for that object. The existing WordPress maximum upload size is enforced during streaming, with at most one extra sentinel byte in the temporary file and cancellation of oversized responses. Actual file size, allowed image MIME, HTTP integrity checks, and basic PNG/JPEG/GIF headers are checked before attachment creation. Generic HTTP Content- Type headers alone do not reject valid images. Invalid, zero, or overflowing configured limits fail explicitly. WordPress safe HTTP redirects, TLS checks, and Content-MD5 verification remain in use. The plugin also checks resolved IPv4/IPv6 answers and DNS aliases for the initial URL and redirect targets. Private/local addresses and failed, cyclic, or excessive alias resolution are rejected. IPv6 literals and AAAA-only hosts remain unsupported. Core’s same-site exception does not bypass the plugin’s private-address checks. These checks do not pin DNS or eliminate the race between DNS validation and connection. The byte limit is per response, not a total network or CPU budget: socket buffering and compressed decoding can exceed it before cancellation, while temporary file bytes stay bounded. Core transport differences for compressed/chunked images remain. Additional image formats enabled by WordPress filters still use core MIME handling. ### How are scheduled dates validated? Posts, pages, and custom post types require a nonempty scheduled_date when creating or newly requesting future status. The date must be valid and at least 60 seconds ahead when validated. Malformed calendar/time values, missing dates, and dates too close to now fail before content, metadata, or terms are written. Errors use success: false, code invalid_input, and reason invalid_scheduled_date, missing_scheduled_date, or scheduled_date_too_soon. An edit to an already-scheduled item may omit the date to retain its valid stored local/GMT dates; its GMT date must still meet the cutoff. Near-now/overdue schedules require a new safe date or an explicit nonfuture status. Changing the site timezone does not cause stored dates to be rewritten or rejected solely because they no longer match the current timezone. Prefer ISO 8601 with Z or an explicit offset and a comfortably future time. A normal clock tick between validation and WordPress’s later check can cross the 60-second boundary; this is not an atomic status guarantee. WordPress and other plugins still control persistence hooks and cron execution. Legacy relative dates and offset-less parsing remain supported. Offset-less values normally mean UTC, not site-local time. Named-timezone DST folds/gaps retain PHP’s resolution; explicit offsets preserve their instant. A valid date supplied for other statuses still sets date arguments under normal WordPress rules, including the existing zero-GMT draft/pending update reset and publish-to-future conversion. ### Who can create, update, or delete categories and tags? Editors and Administrators can manage them with WordPress’s default capabilities. Create/update uses the registered taxonomy’s edit_terms capability; deletion uses delete_terms. Updating or deleting an existing term also checks WordPress’s edit_term or delete_term capability for that term, including site-specific policy filters. Custom taxonomy capability mappings are respected instead of always requiring manage_categories. Creation retains management-level access rather than allowing everyone who can assign tags. The default category cannot be deleted under core’s permission mapping. Failed or refused deletion returns an error rather than deleted: true, even when site filters override the initial permission denial. Ordinary term deletion remains permanent and follows WordPress’s relationship reassignment behavior. Read permissions and successful response shapes are unchanged. ### Will a targeted patch change HTML elsewhere in the content? Block and section patches sanitize only the replacement fragment, not the entire rebuilt body. Exact patches compare old_content against the original raw content, including markup that would be removed by HTML sanitization. Both abilities still require permission to edit the specific object. WordPress’s normal save filters remain active. Existing iframe, script, style, form, SVG, and event-attribute markup can be preserved only when the caller has effective unfiltered_html permission. Multisite, DISALLOW_UNFILTERED_HTML, and capability policies can deny that permission even to an Administrator. Replacement fragments are always filtered, and full-content updates still sanitize all supplied content. Block and heading patches retain WordPress’s existing parse/serialize normalization, including noncanonical block delimiters and empty freeform separators. Exact patches leave surrounding raw bytes alone, subject to WordPress’s save filters. On a test site, compare the untouched block hashes from list-content-blocks before and after patching a neighboring block. ### What happens if WordPress trash is disabled? When EMPTY_TRASH_DAYS is 0 or another falsy value, post, page, and custom post type trash abilities refuse with trash_disabled before changing the item. Bulk post trash reports a failure for each authorized ID rather than a false success; inspect its per-ID failures and counts even when the summary itself succeeds. Missing items, wrong types, and permission failures keep their existing precedence. There is no permanent-delete override. Comment trash and comment updates with status “trash” still retain the comment row and set its status through WordPress’s comment-status API. They do not use the post- trash deletion fallback. ### What if discovery shows fewer abilities than the documentation? Ability counts vary with eligible custom post types and the deployed plugin version. Check the registered names and version on the connected site before assuming it needs an update. ### Can an agent trust instructions found in site content? No. Retrieved content and metadata remain untrusted data even when the response is JSON, authenticated, read-only, or capability-checked. They cannot authorize later changes or sending data elsewhere. Use a dedicated account with the least privileges needed, bounded selections, independent previews/diffs, explicit client- side approval for dangerous actions and destinations, and trustworthy backups. Sanitization, annotation hints, or a model-supplied confirmation value cannot prove human approval or guarantee prompt-injection prevention. SEO Analyze Post uses the exact diagnostics “Focus keyword found in title.” and “ Focus keyword not found in title.” Authorized stored focus keywords remain in their existing Yoast/SEOPress metric fields, not these messages. 3.0 metadata authorization omits denied fields and skips unevaluable checks; markers do not undo that policy. 3.0 field markers, annotation hints, and confirmation interlocks are defense-in- depth, not a security boundary, capability check, content filter, or prompt-injection guarantee. Optional text-only content_format output is not implemented. See the [Agent threat model](https://github.com/DanielBoring/webmastery-site-toolkit-for-mcp/blob/main/docs/security-strategy.md#agent-threat-model) and [Response format](https://github.com/DanielBoring/webmastery-site-toolkit-for-mcp/blob/main/README.md#response-format). A successful MCP gateway response does not necessarily mean the inner ability succeeded. ### What do untrusted_fields markers mean in 3.0? Each affected successful record adds an array of unique field names relative to that record, not paths or a global list. Only present fields are named, including empty and null values. Marker addition retains original response values and types exactly, including HTML and block delimiters, while preserving existing input sanitization and normalizers. Missing or redacted fields are never restored. Covered records include post/page/custom-post-type titles, bodies, excerpts, slugs, URLs and author display names; revision text and author display names; block names, text, HTML and attributes; comment text and author identity fields; media titles, captions, alt text, URLs and filenames; user profiles and privileged audit fields; authorized SEO metrics, provider metadata containers and score records; and sitemap URL/entries and robots URL records. Container markers leave nested maps unchanged. Canonical errors and diagnostic error subrecords have no markers. Unmarked content is not guaranteed trusted. Content-hygiene lists mark title and url on each orphaned-media and missing-featured- image item, and title, url and author_name on each stuck-scheduled item. Existing values, list ordering, authorizations, reference checks and query failures remain unchanged. Standalone get-post-meta marks meta on its containing data record. Standalone update- post-meta marks meta_key, previous_value and current_value on its data record. All nested stored maps remain unchanged, as do object/key authorization and protected- key eligibility. The existing comment normalizer emits author email/URL under its existing permissions; there is no new field-level privacy gate. The separate user list/get login/email privacy gate remains intact. Standalone delete-post-meta marks meta_key on its data record without changing delete authorization. patch-content-block marks content on its data record; patch-post- content marks present heading_text on data.target, with an empty untrusted_fields array for exact-match targets. The nested normalized post remains marked. SEO/site overview marks present url/entries on sitemap and url on robots_txt. Original values and types are unchanged. Permissions and privacy remain unchanged. Content and media retain their object/ status policies. Comment listing requires moderate_comments; replies require edit_posts plus parent edit_post; moderation requires moderate_comments plus edit_comment. Markers do not add comment email/URL redaction. User lookup requires list_users, with login/email only when edit_user for the target or edit_users permits them; user access audits require edit_users. SEO keys require effective object/key authorization, and unavailable_fields/unevaluable_checks remain intact. Generated Yoast head output stays unavailable, URL-only inspection stays unsupported, and no provider head calls are made. Markers accompany data through both gateway and individual tools. The default tools/ list advertises three gateway tools, not per-ability hints; use mcp-adapter-get- ability-info for the ability metadata. Compare actual Adapter readOnlyHint, destructiveHint and idempotentHint against registered readonly, destructive and idempotent values on individual tools. The assessment distinguishes measured pre-release annotation proof from release-package validation. For exact field names, examples and disposable-site verification, see the repository README’s “Untrusted result fields (3.0)” section. ### Where is the full documentation? The complete ability reference and client setup guide are maintained at: https:// www.virtuallyboring.com/webmastery-site-toolkit-for-mcp/ ### What do the security and database diagnostics reveal? Both abilities require manage_options. The security audit’s ssl finding checks the configured public home option, respecting normal option filters and WP_HOME: recognized HTTPS passes and HTTP fails. Missing/unsupported schemes or hosts, whitespace/control characters, malformed percent escapes, and invalid authority syntax warn as unknown. This local syntax guard preserves local names, Unicode/IDN forms, escaped components, and bracketed IPv6 (including escaped zone IDs) or IPvFuture literals. It is not a complete URL, DNS-name, or internationalized-name validator and imposes no address- routability policy. The MCP request scheme and admin-only TLS policy do not determine this finding. It does not verify certificates, reachability, redirects, or the final filtered front-end URL. Debug-log findings omit filesystem paths. Enabled logging warns that access is unverified, even when a neighboring .htaccess file exists or the location is outside wp-content; neither proves that web access is denied. Disabled logging still passes. Necessary logging need not be disabled merely because it is enabled. Database query failures retain the contextual database_health_query_failed reason without raw SQL/server error details, leaving WordPress’s own logging unchanged. In 3.0, table-size reports use core logical names (such as posts) and response-local opaque custom labels (such as custom_table_1), with an is_core_table boolean. The default reveals neither the configured prefix nor custom/plugin names. Labels are not stable across reports. Explicit include_table_names: true deliberately sends raw table identifiers to the model provider; it still requires manage_options. Only actual booleans are accepted, including in direct execution. Both modes retain counts, bytes, ordering, and current-prefix scope and never return passwords, SQL errors, or filesystem paths. ### How do I report a security vulnerability? Report suspected vulnerabilities privately at https://github.com/DanielBoring/webmastery- site-toolkit-for-mcp/security/advisories/new rather than in public issues or support threads. Include affected versions, the ability, the minimum required role, and reproduction steps on a test site. Do not include credentials or private site data. Security fixes target the latest stable release. Reports receive a best-effort response without a guaranteed deadline. See https://github.com/DanielBoring/webmastery-site- toolkit-for-mcp/security/policy for the full policy. ## Ulasan Belum ada ulasan untuk plugin ini. ## Kontributor & Pengembang “Webmastery Site Toolkit for MCP” adalah perangkat lunak open source. Berikut ini mereka yang sudah berkontribusi pada plugin ini. Kontributor * [ Daniel Boring ](https://profiles.wordpress.org/deboring/) [Terjemahkan “Webmastery Site Toolkit for MCP” dalam bahasa Anda.](https://translate.wordpress.org/projects/wp-plugins/webmastery-site-toolkit-for-mcp) ### Tertarik mengembangkan? [Lihat kode](https://plugins.trac.wordpress.org/browser/webmastery-site-toolkit-for-mcp/), periksa [repositori SVN ](https://plugins.svn.wordpress.org/webmastery-site-toolkit-for-mcp/), atau mendaftar ke [log pengembangan](https://plugins.trac.wordpress.org/log/webmastery-site-toolkit-for-mcp/) melalui [RSS](https://plugins.trac.wordpress.org/log/webmastery-site-toolkit-for-mcp/?limit=100&mode=stop_on_copy&format=rss). ## Log Perubahan #### Unreleased #### 3.0.0 * Retain candidate/cache-priming database failures across later successful native reads, without adding queries, exposing SQL diagnostics or rejecting stale warm- cache errors. * Replace unbounded list materialization with candidate windows and next_page continuation, including empty windows; remove exact filtered totals for content, media, orphan- media, and score lists. * Default content and revision lists to summary projection; explicit fields:”full” preserves stored content. Batch known media references without relaxing permission or database-failure safeguards. * Mark present untrusted fields on authorized records without changing stored values, types, markup or privacy omissions; summary projections never mark omitted content. These record-local hints are not prompt-injection prevention. * Close fixed-property input schemas and reject malformed types/enums before raw permission checks or execute callbacks; preserve explicit open maps and omitted defaults. * Validate strict types during registered input validation after core checks, preventing malformed scalar inputs from being misclassified as permission denials. * Preserve empty database-health requests at Adapter permission preflight by honoring the declared object-root default, without changing Administrator authorization, table-name privacy, or strict raw callback validation. * Reject unadvertised parent fields on posts and nonhierarchical custom post types, including zero, while retaining hierarchical detach and parent authorization. * Require exact confirmation for permanent media/term deletion and both bulk post operations; bound raw bulk requests to 100 IDs and add non-mutating eligibility previews. * Guard media deletion with shared known-reference checks; require explicit force for known usage, fail closed on scan errors, and report in_use on success without changing capabilities. * Reject combined metadata and SEO inputs in post/page/custom-post-type create and update before any mutation; migrate to draft creation, separate authorized key writes, then publication. * Authorize separate SEO reads per real object/key, omit denied fields, filter score pagination, remove opaque generated head output, and bound overview to authorized observations from a 100-post sample. * Standardize failures on canonical categories, precise reasons, safe messages and object-shaped details, including callback exceptions on WordPress 6.9. * Signal owned MCP failures consistently; error normalization preserves successful payloads and non-atomic bulk summaries and leaves foreign tools unchanged. * Redact database table identifiers by default for 3.0; add exact core classification and an explicit Administrator-only boolean opt-in for raw names, preserving diagnostic metrics and query scope. #### 2.6.0 * Add read-only Google Site Kit setup, module, current-user permission, and same- site PageSpeed abilities with Site Kit-native authorization and sensitive upstream fields removed. * Reject invalid or unauthorized page and custom post type parents before saving other changes; retain valid hierarchical parents, detach-to-zero, and omitted parents. * Validate custom post type update taxonomy registration and assign-terms permission before saving any requested changes, matching creation. * Keep stored SEO focus keywords in metric data rather than diagnostic messages, without changing provider selection, scores, permissions, or response fields. * Enforce key-level WordPress authorization for standalone post-meta reads, upserts, and deletes. Omit denied keys from listings; retain existing success shapes and protected-key eligibility. * This partial fix does not change metadata inside post/page create/update requests or separate SEO read paths; their authorization risks remain unresolved. * Comment updates, approval, trash, and spam now require permission to edit the specific comment as well as moderation permission. Missing-comment errors are unchanged; invalid IDs cannot select a global comment or a different target. * Report the configured public home URL scheme independently of the MCP request and admin-only TLS policy. * Warn on malformed percent escapes or authority syntax without rejecting valid local, internationalized, or IPv6 configurations. * Omit debug-log paths and warn when log access is unverified rather than claiming protection. * Omit raw database errors while retaining failure context; successful table reports still include prefixed table names. * Preserve backslashes in post/page metadata and media upload/update titles, captions, and alt text while retaining existing sanitization and permissions. * Enforce the existing image upload size limit during retrieval and cancel oversized responses; preserve safe HTTP, MIME, and integrity checks. * Check IPv6 DNS answers and aliases alongside IPv4 for image URLs and redirect targets, with consistent documentation-address rejection across PHP versions and without claiming complete DNS-rebinding protection. * Validate scheduled dates before post, page, or custom post type writes, preserving valid existing schedules and explicit-offset instants. * Prevent WordPress from discarding validated scheduling dates when updating drafts or pending items with zero GMT dates. * Respect taxonomy-specific create/update/delete capabilities and per-term update/ delete restrictions, including direct execution. * Report refused or failed term deletion as failure instead of claiming the default category was deleted. * Preserve unrelated stored HTML during targeted block and section patches without bypassing WordPress save filters. Match exact targets against raw content while continuing to sanitize replacement fragments. * Require WordPress read access in addition to Site Kit route permissions for module, permission, and PageSpeed abilities, including direct execution. Missing delegated permission callbacks now fail closed. * Prevent permanent deletion by post, page, custom post type, and bulk post trash abilities when WordPress trash is disabled. Return an explicit refusal without changing existing enabled-trash behavior. * Restrict webmaster verification’s WordPress-only Site Kit state to callers with plugin activation permission; retain public checks for Subscribers and Authors. * Cache public webmaster verification results for 60 seconds without sharing private plugin state or caller-specific summaries. * Update tested WordPress compatibility to 7.1; retain WordPress 6.9 and PHP 8.0 minimum requirements. * Document private vulnerability reporting, untrusted-content handling, and the distinction between ability results and MCP gateway responses. #### 2.5.0 * Expand targeted content patching to pages and public editor-enabled custom post types with object-level permissions and explicit unsupported-type errors. * Refresh the WordPress.org listing to lead with the 70+ permission-aware abilities across 16 areas and supported MCP clients. * Add an FAQ entry covering compatible AI clients and MCP hosts. * Update the WordPress.org tags to better describe MCP-powered content automation. #### 2.4.1 * Harden permission callbacks and per-object filtering for posts, pages, custom post types, media, SEO score lists, plugin activation/deactivation, and runtime environment details. * Remove plugin auto-update status from plugin responses to avoid Plugin Check updater-detection warnings. * Require publish capabilities for private/scheduled/published status changes and bulk publishing. * Reduce sensitive identity and fingerprinting fields in low-privilege responses. #### 2.4.0 * Add expanded Yoast SEO free metadata coverage for canonical URLs, breadcrumb titles, Schema.org page/article types, Open Graph and Twitter metadata, primary category, robots directives, inclusive-language score inspection, generated Yoast head inspection, and deeper sitemap index diagnostics. * Add first-class SEOPress free metadata coverage for titles, descriptions, target keywords, canonical URLs, Open Graph and Twitter/X metadata, primary category, robots directives, breadcrumb titles, read-only metadata inspection, and SEOPress- specific site overview diagnostics. #### 2.3.0 * Add public image URL uploads with URL safety checks, image MIME and upload-size enforcement, optional metadata, and optional featured-image assignment. * Add public Google/Bing webmaster verification checks without Google or Bing API credentials. * Add Administrator-only user access, plugin, database, performance, and backup audits. * Add content hygiene diagnostics for orphaned media, posts/pages missing featured images, and stuck scheduled posts. * Add bulk post trash and bulk draft-publish abilities with per-ID summaries. * Add eligible custom post type discovery and generated CRUD abilities. * Add safe site, current-user, and environment introspection abilities. * Add post meta read, update, and delete abilities with object-level permissions and protected-key safeguards. * Add revision listing and restore abilities for posts and pages. * Add category and tag get/update abilities. * Add comment reply and update abilities. * Add human-readable author fields to post and page responses. #### 2.2.0 * Add Yoast SEO score and readability score abilities. * Persist supported Yoast SEO protected meta keys from post and page create/update abilities. #### 2.1.0 * Add block inspection, single-block replacement, and safer partial post body edits. ## Meta * Versi **3.0.0** * Diperbarui **3 hari yang lalu** * Instalasi Aktif **10+** * Versi WordPress ** 6.9 atau yang terbaru ** * Diuji hingga **7.1.3** * Versi PHP ** 8.0 atau yang terbaru ** * Bahasa * [English (US)](https://wordpress.org/plugins/webmastery-site-toolkit-for-mcp/) * Tag * [AI](https://id.wordpress.org/plugins/tags/ai/)[automation](https://id.wordpress.org/plugins/tags/automation/) [Claude](https://id.wordpress.org/plugins/tags/claude/)[content management](https://id.wordpress.org/plugins/tags/content-management/) [mcp](https://id.wordpress.org/plugins/tags/mcp/) * [Tampilan lanjut](https://id.wordpress.org/plugins/webmastery-site-toolkit-for-mcp/advanced/) ## Rating No reviews have been submitted yet. [Your review](https://wordpress.org/support/plugin/webmastery-site-toolkit-for-mcp/reviews/#new-post) [Lihat semua ulasan](https://wordpress.org/support/plugin/webmastery-site-toolkit-for-mcp/reviews/) ## Kontributor * [ Daniel Boring ](https://profiles.wordpress.org/deboring/) ## Bantuan Ada yang ingin dikatakan? Butuh bantuan? [Lihat forum bantuan](https://wordpress.org/support/plugin/webmastery-site-toolkit-for-mcp/) ## Donasi Apakah Anda ingin mendukung pengembangan plugin ini? [ Donasi untuk plugin ini ](https://paypal.me/VirtuallyBoring)