{"id":346076,"date":"2026-09-07T15:36:18","date_gmt":"2026-09-07T15:36:18","guid":{"rendered":"https:\/\/wordpress.org\/plugins\/saddle\/"},"modified":"2026-09-07T15:35:45","modified_gmt":"2026-09-07T15:35:45","slug":"saddle","status":"publish","type":"plugin","link":"https:\/\/tw.wordpress.org\/plugins\/saddle\/","author":8610910,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"1.0.0","stable_tag":"1.0.0","tested":"7.1","requires":"6.9","requires_php":"7.4","requires_plugins":null,"header_name":"Saddle \u2013 Control Your Site with AI (MCP Server)","header_author":"PlugPress","header_description":"Self-hosted MCP server for WordPress. Tiered, default-safe, approval-gated access to posts, pages, and media for AI agents \u2014 with no third-party credential custody.","assets_banners_color":"111116","last_updated":"2026-09-07 15:35:45","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"https:\/\/plugpress.co\/saddle\/","header_author_uri":"https:\/\/plugpress.co","rating":0,"author_block_rating":0,"active_installs":0,"downloads":34,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"1.0.0":{"tag":"1.0.0","author":"badhonrocks","date":"2026-09-07 15:35:45","revision":3685205}},"upgrade_notice":[],"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3685205,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3685205,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256},"icon.svg":{"filename":"icon.svg","revision":3685205,"resolution":false,"location":"assets","locale":false}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3685205,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3685205,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.0"],"block_files":[],"assets_screenshots":[],"screenshots":{"1":"Access levels \u2014 choose how much your AI can do, and see exactly which tools each level allows.","2":"Connecting an app \u2014 name a connection and issue its credential without leaving the dashboard.","3":"Activity \u2014 a day-grouped record of everything agents changed, and everything that was blocked.","4":"Guidance \u2014 the exact context every agent receives, your own instructions, and your installed Skills."}},"plugin_section":[],"plugin_tags":[15643,2353,569,216196,242115],"plugin_category":[],"plugin_contributors":[203414],"plugin_business_model":[],"class_list":["post-346076","plugin","type-plugin","status-publish","hentry","plugin_tags-agents","plugin_tags-ai","plugin_tags-automation","plugin_tags-chatgpt","plugin_tags-mcp","plugin_contributors-badhonrocks","plugin_committers-badhonrocks"],"banners":{"banner":"https:\/\/ps.w.org\/saddle\/assets\/banner-772x250.png?rev=3685205","banner_2x":"https:\/\/ps.w.org\/saddle\/assets\/banner-1544x500.png?rev=3685205","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":"https:\/\/ps.w.org\/saddle\/assets\/icon.svg?rev=3685205","icon":"https:\/\/ps.w.org\/saddle\/assets\/icon.svg?rev=3685205","icon_2x":false,"generated":false},"screenshots":[],"raw_content":"<!--section=description-->\n<p>Saddle turns your WordPress site into a <strong>Model Context Protocol (MCP) server<\/strong>. AI apps you already use \u2014 Claude, Cursor, VS Code, and others \u2014 connect to your site and help with real work: reading and writing posts and pages, managing media, and designing pages with your theme's own styles.<\/p>\n\n<p>Everything runs on your own site. There is no account to create and no cloud service in the middle: your content, your credentials and every tool call stay in your WordPress. Agents sign in with WordPress core's <strong>Application Passwords<\/strong>, and you decide how much they are allowed to do.<\/p>\n\n<h4>How it stays safe<\/h4>\n\n<p>Saddle is built around three rules:<\/p>\n\n<ol>\n<li><strong>Your credentials and content stay on your site.<\/strong> Saddle has no relay, proxy, or backend of its own. Authentication is WordPress core's Application Passwords \u2014 Saddle never sees or stores a separate password, and your tool-call traffic never touches a server we operate.<\/li>\n<li><strong>New installs start read-only.<\/strong> Out of the box, agents can look but not change anything. Writing and site management are levels <em>you<\/em> turn on. They are never on by default.<\/li>\n<li><strong>Deleting or overwriting always asks first.<\/strong> A destructive action takes two calls: the first returns a preview and a single-use confirmation token and changes nothing; only a second call with that token executes. Tokens expire after 15 minutes. An agent \u2014 even a misbehaving one \u2014 cannot delete anything in a single step.<\/li>\n<\/ol>\n\n<h4>What your AI can do<\/h4>\n\n<p>All tools are served from one authenticated endpoint on your site (<code>\/wp-json\/saddle\/v1\/mcp<\/code>). Each tool declares the access level it needs, so a read-only connection can only ever read.<\/p>\n\n<ul>\n<li><strong>Content<\/strong> \u2014 list, read, create, update, and delete posts and pages (deletes trash by default and always confirm first); manage media, including upload from a URL; categories and tags; search; site info.<\/li>\n<li><strong>Page design<\/strong> \u2014 build and edit real Gutenberg blocks that stay editable in the editor, read block schemas and your theme's design tokens, and insert patterns. Agents design <em>with<\/em> your theme instead of pasting raw HTML, and page-builder layouts are protected from accidental overwrites.<\/li>\n<li><p><strong>Site management<\/strong> (separate opt-in level) \u2014 read and change common Settings screen options (site title, permalinks, reading and discussion settings), activate\/deactivate plugins, switch themes, flush the cache.<\/p>\n\n<p><strong>Note:<\/strong> everything here runs through WordPress's own functions. Saddle contains no shell commands, no <code>eval()<\/code>, and no arbitrary code execution \u2014 anywhere. Values are validated before saving, and sensitive settings (site URL, security keys, user roles, admin email) can never be touched.<\/p><\/li>\n<li><strong>Guidance &amp; memory<\/strong> \u2014 install Skills (plain <code>.md<\/code> playbook files that teach your AI how you like things done), and let each new session start knowing what changed on the site recently, from Saddle's own activity log.<\/li>\n<\/ul>\n\n<h4>What you see and control<\/h4>\n\n<ul>\n<li><strong>Access levels<\/strong> \u2014 pick Read, Read &amp; write, or Managing the site, and see exactly which tools each level allows. Any individual tool can be switched off.<\/li>\n<li><strong>Activity<\/strong> \u2014 a day-by-day record of everything agents changed and every attempt that was blocked. Reads are not logged.<\/li>\n<li><strong>Guidance<\/strong> \u2014 the exact context every agent receives, plus your own instructions and Skills.<\/li>\n<li><strong>Pause<\/strong> \u2014 one switch that instantly blocks every tool call, without losing your settings.<\/li>\n<\/ul>\n\n<h4>How agents connect<\/h4>\n\n<p>Go to <strong>Saddle \u2192 Connections<\/strong>, name a connection, and approve it. WordPress core issues an Application Password for it, and you paste the shown settings into your AI app. Revoking a connection invalidates its credential immediately.<\/p>\n\n<p><strong>Note:<\/strong> a Saddle-issued credential only works on Saddle's own endpoint. It cannot be used against the rest of the REST API or XML-RPC.<\/p>\n\n<h4>Sign-in for apps that can't paste a key (optional, off by default)<\/h4>\n\n<p>A few apps \u2014 ChatGPT's custom connectors among them \u2014 give you nowhere to paste a sign-in key. For those, Saddle can run a standard <strong>OAuth 2.1 sign-in<\/strong> on your own site: the app sends you to an approval screen in your WordPress admin, you see who is asking and what they want, and you decide.<\/p>\n\n<p>This is <strong>off until you turn it on<\/strong>, on the Settings screen. It runs entirely inside your WordPress \u2014 there is no PlugPress server involved at any point, exactly as with Application Passwords. Only administrators can approve a connection, and an approval can never grant more than your chosen access level: if the site is set to read-only, an approved app gets read-only. You can see and revoke approved apps from the Connections screen at any time.<\/p>\n\n<p>Turning it on publishes the small set of addresses the OAuth standard requires so apps can find and complete the sign-in. With it off \u2014 the default \u2014 none of them exist.<\/p>\n\n<h4>No bundled libraries<\/h4>\n\n<p>Saddle speaks MCP itself. It ships no third-party library, and every function, class, option and hook it defines is prefixed <code>saddle<\/code> \/ <code>Saddle_<\/code> \/ <code>SADDLE_<\/code>.<\/p>\n\n<p>If the separate <strong>MCP Adapter<\/strong> plugin happens to be active on the same site, Saddle detects it and uses it instead. That is optional and nothing depends on it \u2014 the endpoint, the tools and the safety model are identical either way.<\/p>\n\n<h4>Source code<\/h4>\n\n<p>The admin screen is a React app. Its full human-readable source ships inside this plugin in <code>admin\/src\/<\/code>; the compiled bundle in <code>admin\/build\/<\/code> is produced from it with the official <code>@wordpress\/scripts<\/code> toolchain.<\/p>\n\n<h4>Saddle Pro<\/h4>\n\n<p>Saddle Pro is a separate, optional add-on that adds page-builder-native editing (Divi first). This free plugin is complete on its own \u2014 nothing in it is locked, limited, or nagging you to upgrade.<\/p>\n\n<h3>External services<\/h3>\n\n<p>Saddle sends <strong>no<\/strong> analytics, telemetry, or usage data anywhere, and no content or credentials ever leave your site. Its MCP endpoint is <em>inbound<\/em> \u2014 agents call your site, not the other way round.<\/p>\n\n<p><strong>The version on WordPress.org makes no outbound request at all.<\/strong> If you installed Saddle from plugpress.co instead, that copy checks for its own updates: it sends the plugin name and the version number you have, to one fixed address, at most once every six hours, and only when WordPress runs an update check. No site address, no content, no account, nothing about you. It is the same thing WordPress does for every plugin you install from WordPress.org, pointed at us instead.<\/p>\n\n<p>Apart from that, four things make an outbound request, and each one is started by you:<\/p>\n\n<ol>\n<li><strong>Upload from URL.<\/strong> If you ask an agent to add a file to the media library by URL, WordPress's own HTTP API downloads that one URL to your server \u2014 the same mechanism core's \"insert from URL\" uses. Only the host in the URL you supplied is contacted.<\/li>\n<li><strong>Endpoint self-checks.<\/strong> The connection checker sends requests to <em>your own site<\/em> \u2014 its REST URL, and, when OAuth sign-in is on, its <code>\/.well-known\/<\/code> discovery address \u2014 to confirm those endpoints are reachable. Nothing leaves your server.<\/li>\n<li><p><strong>Unsplash (optional, off until you add a key).<\/strong> If you enter your own Unsplash API key on the Integrations screen, the <code>unsplash-search<\/code> and <code>unsplash-import<\/code> tools call the Unsplash API (<code>api.unsplash.com<\/code>, <code>images.unsplash.com<\/code>) directly from your site, sending only your search keywords or a photo id. With no key saved, no request is ever made. Unsplash API Guidelines: https:\/\/help.unsplash.com\/en\/articles\/2511245-unsplash-api-guidelines \u2014 API Terms: https:\/\/unsplash.com\/api-terms \u2014 privacy policy: https:\/\/unsplash.com\/privacy<\/p>\n\n<p><strong>Attribution:<\/strong> a photo imported this way is saved with a caption crediting the photographer, containing links to their Unsplash profile and to unsplash.com. The Unsplash API Terms require this credit, so it is written for you. Because it is the image's caption, it is visible wherever your theme displays captions \u2014 including on the public side of your site. It is an ordinary caption: edit or clear it in the Media library whenever you like, or pass your own caption when importing. No other external link is ever added to your site, and nothing links back to the plugin author.<\/p><\/li>\n<li><p><strong>Checking an app's identity (optional, off unless you turn on OAuth sign-in).<\/strong> ChatGPT can't be given a sign-in key by hand, so Saddle can let apps sign in through an approval screen instead. Some apps identify themselves with a web address that serves a small description of the app. If one does, Saddle fetches that address \u2014 and only that address, chosen by the app, never by us \u2014 to confirm it vouches for the app, so the approval screen can tell you whether the app was verified or merely self-described. Nothing about your site is sent; it is a plain read. The request is HTTPS-only, follows no redirects, times out in five seconds, is capped at 64 KB, and the answer is cached. With OAuth sign-in off \u2014 the default \u2014 this never happens.<\/p><\/li>\n<\/ol>\n\n<h3>Privacy<\/h3>\n\n<ul>\n<li>Saddle stores only its own settings (access level, tool toggles, your instructions, Skills, memory entries), its activity log, and short-lived confirmation tokens that expire after 15 minutes.<\/li>\n<li>If you turn on OAuth sign-in, Saddle also stores the apps you approved and their sign-in tokens. Tokens are never kept in readable form \u2014 only a one-way fingerprint, so a database backup contains nothing anyone could sign in with. Disconnecting an app deletes its tokens immediately, and turning OAuth sign-in back off deletes all of them.<\/li>\n<li>No personal data is sent off-site.<\/li>\n<li>Uninstalling deletes all of the above. Application Passwords are left for you to revoke yourself (Users \u2192 Profile), since WordPress core owns them.<\/li>\n<\/ul>\n\n<!--section=installation-->\n<ol>\n<li>Install and activate the plugin. Saddle needs WordPress 6.9+ (for the core Abilities API) and PHP 7.4+.<\/li>\n<li>Open <strong>Saddle<\/strong> in the admin menu. New installs start at the <strong>Read<\/strong> level.<\/li>\n<li>Go to <strong>Connections<\/strong>, name a connection (for example \"Claude\"), and approve it. Copy the settings it shows into your AI app.<\/li>\n<li>When you want agents to do more than read, raise the level on the <strong>Permissions<\/strong> screen. Deletes and overwrites will still ask for confirmation every time.<\/li>\n<\/ol>\n\n<!--section=faq-->\n<dl>\n<dt id=\"does%20my%20content%20or%20my%20password%20go%20through%20your%20servers%3F\"><h3>Does my content or my password go through your servers?<\/h3><\/dt>\n<dd><p>No. Your content and your password never leave your WordPress install, and no telemetry is sent anywhere. Sign-in is WordPress core's own Application Passwords. The WordPress.org copy makes no outbound request at all; the copy from plugpress.co checks for its own updates, sending only the plugin name and version number.<\/p><\/dd>\n<dt id=\"can%20an%20agent%20delete%20something%20without%20asking%3F\"><h3>Can an agent delete something without asking?<\/h3><\/dt>\n<dd><p>No. Every delete or destructive overwrite takes two calls: a preview first, then a confirmation with a single-use token that expires in 15 minutes. One call can never destroy anything.<\/p><\/dd>\n<dt id=\"what%20stops%20an%20agent%20from%20doing%20more%20than%20i%20allowed%3F\"><h3>What stops an agent from doing more than I allowed?<\/h3><\/dt>\n<dd><p>Every tool is bound to an access level, and new installs start at Read. Calls above the current level are refused and logged. You can also switch off individual tools, or hit Pause to block everything at once.<\/p><\/dd>\n<dt id=\"does%20a%20connected%20app%20get%20full%20access%20to%20my%20site%3F\"><h3>Does a connected app get full access to my site?<\/h3><\/dt>\n<dd><p>No. Its credential only works on Saddle's endpoint \u2014 not the rest of the REST API, not XML-RPC. Revoke the connection and the credential dies with it.<\/p><\/dd>\n<dt id=\"do%20i%20need%20an%20account%20or%20subscription%3F\"><h3>Do I need an account or subscription?<\/h3><\/dt>\n<dd><p>No. Saddle is free and entirely self-hosted. There is nothing to sign up for.<\/p><\/dd>\n<dt id=\"does%20it%20run%20shell%20commands%20or%20arbitrary%20code%3F\"><h3>Does it run shell commands or arbitrary code?<\/h3><\/dt>\n<dd><p>Never. Every operation goes through WordPress's own PHP functions. There is no shell access, no <code>eval()<\/code>, and no way to add either through a tool call.<\/p><\/dd>\n<dt id=\"do%20i%20need%20the%20mcp%20adapter%20plugin%20as%20well%3F\"><h3>Do I need the MCP Adapter plugin as well?<\/h3><\/dt>\n<dd><p>No. Saddle speaks MCP on its own, and installing anything else changes nothing about what your AI app can do \u2014 same address, same tools, same access levels and approvals.<\/p>\n\n<p>If you happen to have the separate MCP Adapter plugin active, Saddle notices and uses it. That is the only difference, and it is optional.<\/p><\/dd>\n\n<\/dl>\n\n<!--section=changelog-->\n<h4>1.0.0<\/h4>\n\n<ul>\n<li>Initial public release.<\/li>\n<li>Saddle's screens have a look of their own now \u2014 a pink accent on a warm, near-white background, squarer corners and flatter surfaces. About 85% of it is still black, white and grey; the colour is saved for the few things worth pointing at.<\/li>\n<li>The sidebar is one plain list instead of three labelled sections, and two items say what they do rather than what they are called: Guidance is now Instructions, and Connections is now Apps. Your bookmarks and links still work.<\/li>\n<li>The Dashboard opens with a sentence telling you what your AI can do right now, instead of four boxes of numbers. The counts moved to one quiet line underneath, and the box that used to show a dash when there was nothing to report is gone.<\/li>\n<li>Removed the Cookbook screen.<\/li>\n<li>Security: read tools now check whether the connected account is actually allowed to see each item, not just that it is signed in. A connection made with a low-permission WordPress account could previously read any draft, private or password-protected post, any media item's details and any post's revision history \u2014 and could list and search all of it \u2014 even though the account could never see any of it in wp-admin. Nothing changes for the usual setup, where you connect as an administrator.<\/li>\n<li>Security: the list of recent changes \u2014 both the one an assistant can ask for and the one it reads when it connects \u2014 now hides entries about items the connected account cannot see. It was naming the titles of drafts and private posts to accounts that could never open them. Entries about something that has since been deleted stay visible to accounts that can delete content, so you do not lose that history.<\/li>\n<li>Fixed: on sites where another plugin checks who is signed in very early in the request \u2014 several SEO plugins do \u2014 every ChatGPT request crashed before Saddle could examine its token, so the connection failed with a sign-in error forever while the same build worked elsewhere. The token check now works no matter how early in the request it runs.<\/li>\n<li>Fixed: the connection check could report that sign-ins were working on a server that was actually blocking half of them. Apps you connect with a pasted key send one kind of sign-in header and apps that sign in through Saddle \u2014 ChatGPT is the one that can only connect that way \u2014 send another, and some servers pass the first and drop the second. The check now tests both, says which one is being blocked, and offers the same one-click fix, which always covered both.<\/li>\n<li>Connection details and health now shows how each request signed in, so \"the key was rejected\" and \"no key ever arrived\" stop looking identical. They are the same error message and they need opposite fixes \u2014 one is reconnecting the app, the other is a word with your host.<\/li>\n<li>Fixed: the request recorder was logging its own screen refreshing, which pushed the requests you were trying to capture out of the list within about two minutes. It now records only real app traffic, and keeps four times as much of it.<\/li>\n<li>Fixed: on sites that also run the separate MCP Adapter plugin, an app could finish connecting and then report that the site has no actions it can use. The piece that prevents that was missing from the plugin package, so the fix for it had never actually reached anyone. It now ships.<\/li>\n<li>Connection details and health now reports what it knows on every site, not only on sites running the separate MCP Adapter plugin. It previously opened with \"No app has connected yet\" no matter what had happened, which made the request recorder underneath it look broken \u2014 and that recorder is the thing that shows whether a connected app's requests are arriving and what they got back.<\/li>\n<li>The guidance an assistant reads when it connects is now one document with one set of headings, however many PlugPress plugins are adding to it. Previously each plugin appended in its own style \u2014 one added a heading two levels down, another a bare sentence with no heading at all \u2014 and it read like four notes stapled together.<\/li>\n<li>Removed a second web address the plugin was serving without saying so. Saddle publishes one address for AI apps; a bundled library was quietly adding another with weaker checks around it. Nothing documented ever pointed at it, and your access levels and confirmations applied there too \u2014 but it should not have existed, and now it doesn't.<\/li>\n<li>Permissions now tells you how many tools your connected apps are actually offered at the level you pick, how many are being held back, and that already-connected apps keep the old list until you refresh or reopen them.<\/li>\n<li>Fixed: an app that signs in through Saddle instead of using a pasted key \u2014 ChatGPT is the one that does \u2014 was always granted read-only access, whatever you had set on the Permissions screen, and nothing anywhere could change it afterwards. It would happily read your site and then be unable to save a single thing, and reconnecting made no difference. You now choose the access level on the approval screen, and you can change it later for an app that is already connected.<\/li>\n<li>Permissions now names any connected app that is sitting below the level you have chosen, instead of leaving you to work out why an app you granted full access still refuses to write anything.<\/li>\n<li>Fixed: on hosts that rewrite request bodies, saving your access level could report success and quietly change nothing.<\/li>\n<li>New: user directory read tools (list-users, get-user) \u2014 read-only, capability-gated, with personal details visible only to accounts that can manage users.<\/li>\n<li>New: first-party integration wrappers \u2014 abilities from PlugPress plugins (Waggle) surface as saddle\/* tools behind Saddle's full safety model (access levels, pause, per-tool switches, two-step confirmation, activity log).<\/li>\n<li>Security: confirmation tokens are now bound to the user who previewed the action, and wrapped destructive tools bind their full argument set into the token \u2014 a confirmation can never change what was previewed.<\/li>\n<li>Security: issued credentials are recognized by an internal marker instead of their display name, so renaming a key can no longer widen its access.<\/li>\n<li>Security: optional domain enforcement \u2014 write access can auto-suspend when the site's domain changes (cloned or migrated database) until you re-confirm it.<\/li>\n<li>Improved: denial explanations now mirror the enforced checks exactly (including missing-capability denials); the activity log keeps separate caps for changes and denials so denials can never crowd out change history; failed confirmed destructive actions are logged too.<\/li>\n<li>Internal: one shared integration engine, unified builder detection, and a stricter validation contract for page-tree profiles.<\/li>\n<li>Fixed: some connected apps signed in, reported the connection as healthy, and then said the site had no actions they could use \u2014 while the same site worked perfectly from another app. Saddle was answering one step of the connection handshake in a way the stricter apps refuse, so they stopped before ever asking what tools exist. Saddle now answers that step, and the two others it was getting wrong, exactly as the Model Context Protocol requires.<\/li>\n<li>Connected apps are now offered only the tools your access level and switches actually allow. A read-only site no longer advertises tools that would be refused on every call \u2014 the assistant is told how many are being held back and that only you can unlock them, so it can point you at the setting instead of reporting that your site cannot do it. Raising the access level widens the list again; reconnect the app if it caches what it was told at sign-in.<\/li>\n<li>Fixed: a destructive tool from a connected PlugPress plugin could be confirmed with different details than the preview showed. The confirmation now covers everything the preview showed, not just which item it was about.<\/li>\n<li>A refused call caused by the WordPress account being short a permission now says so, instead of pointing at Saddle settings that would not have changed anything.<\/li>\n<li>An assistant now starts a session already knowing your palette, what wraps your pages, and how many ready-made patterns your theme has \u2014 and is pointed at the single call that fetches the rest, instead of the four or five it used to make.<\/li>\n<li>Repeated edits to the same page no longer fill the \"recent changes\" an assistant sees with the same line over and over; a run of them reads as one entry with a count.<\/li>\n<li>The bundled build-a-page playbook now ships on classic themes too, not only block themes \u2014 a classic site editing its pages in the block editor was the one case that got no guidance at all. It adapts its \"go look at the site first\" step to what your theme actually has.<\/li>\n<li>A second bundled playbook, fix-page: how to work a page-verification report down to nothing, which findings to fix first, and why block positions move under you after a structural change.<\/li>\n<li>See the whole site, not just one page: list and read block templates and template parts, read the global styles the owner set, and list their saved patterns.<\/li>\n<li>Set up a design system on a block theme: bootstrap-design-system now writes the palette, type scale and spacing into your global styles, so it appears in Appearance &gt; Editor &gt; Styles and stays yours to edit. Existing values are never overwritten.<\/li>\n<li>Orient in one call: context-bundle returns the design system, the blocks worth using, the theme's patterns, the site's templates and the section recipes together, instead of five separate calls per session.<\/li>\n<li>A bundled build-page playbook on block themes: the order to work in, the rules the plugin enforces, and what separates a designed page from a generated one.<\/li>\n<li>MCP server on your own site: content tools (posts, pages, media, taxonomies, search), Gutenberg block design tools with schema validation and theme design tokens, opt-in site management (settings, plugins, themes, cache), Skills, memory, and an activity log.<\/li>\n<li>Safety model: three access levels defaulting to read-only, per-tool switches, two-step confirmation on every destructive action, a master pause switch, and credentials confined to Saddle's endpoint.<\/li>\n<li>Optional Unsplash integration (bring your own API key): search and import stock photos with automatic photographer attribution.<\/li>\n<li>Design quality tools: page verification with a scored report, design lint, section recipes, and a design-system reader\/seeder.<\/li>\n<li>Works on hosts whose security layer strips custom request headers: the dashboard sends its sign-in token in the address as well as the header, and reports plainly when a host is blocking something it cannot work around.<\/li>\n<li>Optional OAuth 2.1 sign-in (off by default) for apps that can't be given a sign-in key by hand, such as ChatGPT connectors \u2014 self-hosted, administrator-approved, and never able to grant more than the access level you chose.<\/li>\n<li>Fixed: some connected apps \u2014 ChatGPT connectors in particular \u2014 signed in successfully but then reported that the site had no actions they could use. Saddle now serves apps that don't hold on to a session between requests, and no longer turns away an app for naming a protocol revision it hadn't seen. Apps that do hold a session are unaffected, and no access level or approval step changes.<\/li>\n<li>Tools now tell connected apps what they do before they run: each carries a readable name and flags for whether it only reads, whether it can destroy anything, and whether repeating it is safe.<\/li>\n<li>A refused tool call now returns its reason to the app as a readable answer rather than a protocol error, so the assistant can tell you which control to change instead of reporting a generic failure.<\/li>\n<li>The list of plugins active on your site, and your theme's name, are now shared with an AI assistant only at the Admin access level \u2014 matching the access level already required to list them as a tool. The connection handshake also respects the pause switch.<\/li>\n<li>Client traffic: a new panel under Connections \u2192 Connection details &amp; health records what a connected app asked for and what it got back, so \"it says it can't see any tools\" can be answered without guesswork. Off by default, stops on its own after an hour, and records no keys or content.<\/li>\n<li>Fixed: some connected apps \u2014 ChatGPT connectors in particular \u2014 signed in successfully but then reported that the site had no actions they could use. Saddle now serves apps that don't hold on to a session between requests, and no longer turns away an app for naming a protocol revision it hadn't seen. Apps that do hold a session are unaffected, and no access level or approval step changes.<\/li>\n<\/ul>","raw_excerpt":"Connect Claude, Cursor, and other AI agents to WordPress. Structured tools, safe-by-default permissions, approval gates for destructive actions.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/346076","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=346076"}],"author":[{"embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/badhonrocks"}],"wp:attachment":[{"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=346076"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=346076"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=346076"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=346076"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=346076"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=346076"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}