WordPress MCP बनाम Headless CMS MCP: कौन सा AI Agents के लिए सही है?

WordPress MCP के पास अब एक official route है: Abilities API, जो WordPress 6.9 में आया, और साथ ही MCP Adapter जो abilities को tools में बदलता है जिन्हें एक agent call कर सकता है। अच्छा। Headless CMSs इस बिंदु पर पहले पहुंचे, अपने पहले-party servers के साथ, जबकि git-आधारित साइटें इसी गड़बड़ी का ज्यादातर हिस्सा बचाती हैं हर agent edit को production में पहुंचने से पहले एक pull request के माध्यम से मजबूर करके। इनमें से कोई भी stack डिफ़ॉल्ट रूप से सुरक्षित नहीं है। असली फर्क यह है कि सुरक्षा कहां रहती है: box में, या आप इसके चारों ओर जो काम करते हैं। यह पोस्ट stacks की तुलना करता है न कि plugin बनाम plugin, फिर आपको एक scorecard और 2027 तक agent-run sites कहां रहते हैं इस पर एक सावधान विचार देता है।

MCP क्या बदलता है: आपकी साइट को एक agent मिलता है जो लिख सकता है

Read-only MCP एक बेहतर-व्यवहार किया गया search box है। एक agent posts fetch करता है, उन्हें summarise करता है और gaps को spot करता है, और अगर वह काम गलत करता है, तो साइट को damage नहीं होता। कुछ नहीं टूटता।

Write access अलग है। एक बार जब server create, update, publish और delete tools को expose करता है, तो agent आपकी साइट का एक working user बन जाता है, अपने token की हर अधिकार के साथ। यह 3am पर एक pricing page को rewrite कर सकता है। यह एक ऐसे draft को publish कर सकता है जिसे किसी ने approve नहीं किया, और यह रास्ते में जो text पढ़ता है उससे mistake की ओर push किया जा सकता है। इसके बारे में जल्द ही अधिक।

इसलिए CMS choice मुख्य रूप से editors और templates के बारे में होना बंद करता है। यह एक permissions question बन जाता है, और चार sub-questions ज्यादातर कठिन काम करते हैं।

1. आप कितनी सूक्ष्मता से यह दायरा बना सकते हैं कि agent को क्या करने की अनुमति है?
2. क्या यह draft में रह सकता है, या हर write live हो जाता है?
3. क्या एक audit trail है, और क्या आप rollback कर सकते हैं?
4. क्या एक human परिणाम को public के सामने देख सकता है?

यह अब कोई niche worry नहीं है। UK AISI ने publicly released MCP tools एक साल में लगभग 5,000 से 177,000 तक बढ़ते हुए गिने, downloads 80,000 से 14 million तक गए। यह trust करने के लिए, या refuse करने के लिए बहुत सारे servers हैं। अगर आप उस call को करने के लिए एक routine चाहते हैं, तो मैंने एक vetting Claude Code skills, plugins और MCP servers में लिखा, और MCP servers को production में चलाने की व्यापक तस्वीर MCP servers production stack post में है।

WordPress, official route: Abilities API और MCP Adapter

Abilities API WordPress 6.9 में आया। यह core, themes और plugins को एक मानक तरीका देता है कि वे क्या कर सकते हैं, इसे declare करने का, input schemas और permission callbacks के साथ जुड़ा हुआ। MCP Adapter उस परत के ऊपर बैठता है। इसे MCP integration के लिए official WordPress package के रूप में described किया गया है, WordPress GitHub organisation के अंतर्गत रहता है, और AI Building Blocks for WordPress initiative के लिए संबंधित है। इसका काम संकीर्ण लेकिन महत्वपूर्ण है: abilities को MCP tools, resources और prompts के रूप में उजागर करें।

README क्या documents करता है:

• HTTP और STDIO transports, साथ ही एक McpTransportInterface custom protocols के लिए। Clients WP-CLI के माध्यम से STDIO पर connect करते हैं, या एक HTTP client को /wp-json/mcp/mcp-adapter-default-server पर point करते हैं।
• यह एक विशेषता है जिसे यह granular permissions कहता है: प्रत्येक सर्वर के लिए transport authentication और प्रत्येक ability के लिए permission checks।
• Abilities डिफ़ॉल्ट रूप से निजी हैं। meta.public (या meta.mcp.public) को true पर सेट करने से एक को सार्वजनिक किया जाता है।
• डिफ़ॉल्ट सर्वर तीन meta-tools देता है: mcp-adapter/discover-abilities, mcp-adapter/get-ability-info और mcp-adapter/execute-ability।
• McpErrorHandlerInterface और McpObservabilityHandlerInterface के माध्यम से pluggable error handling और observability।

डिफ़ॉल्ट रूप से निजी होना सही सोच है। कोई भी ability जिसे किसी ने public के रूप में चिह्नित नहीं किया, agent तक नहीं पहुंच सकती, भले ही prompt कितना भी चतुर हो। अब देखें कि उस सूची में क्या अनुपस्थित है: कोई draft-only agent role नहीं, कोई built-in approval step नहीं, कोई audit log नहीं। Observability hooks इसे बनाने के लिए एक जगह हैं। ये एक तैयार audit trail नहीं हैं।

Draft control abilities के अंदर रहती है। किसी को उन्हें लिखना है। एक third-party plugin, MS WordPress Abilities, उस काम का आकार काफी अच्छी तरह दिखाता है। यह 29 abilities को register करता है (26 custom, साथ ही तीन core ones जो MCP visibility में opted हैं) और एक two-step staged update देता है, preview-post-update फिर apply-post-update, जबकि patch-post-content को कोई staging की जरूरत नहीं है। समझदारीपूर्ण डिजाइन। यह अभी भी उस लेखक की पसंद है, WordPress की नहीं। उसी README के अनुसार, core और official AI plugin केवल कुछ abilities को box के बाहर भेजते हैं।

यह अभी भी settle हो रहा है। 18 मार्च 2026 को खोला गया एक issue इंगित करता है कि adapter README अभी भी Abilities API की जरूरत के बारे में बात कर रहा था, जबकि यह core में merge हो गई थी (issue 150)। 24 जून 2026 को एक contributor ने वहां टिप्पणी की कि नई core और site abilities AI plugin और Abilities API में होनी चाहिए, adapter पर नहीं, और कि कई adapter docs अभी भी पुरानी model सिखाते हैं arbitrary abilities को register करने और mcp.public को सेट करने की। फिर, 5 फरवरी 2026 को, एक WordPress AI maintainer ने कहा कि उसे Abilities API या MCP support को implement करने वाले plugins का कोई directory नहीं पता (discussion 204)। Plumbing official है। Safe, useful abilities का catalogue पतला बना हुआ है।

WordPress, plugin route: बहुत सारी पसंद, एक पतला security record

दूसरा WordPress route एक plugin है जो अपना खुद का MCP server भेजता है। नाम जो vendor comparison pages पर दिखाई देते हैं उनमें Easy MCP AI, WPVibe, Novamira, Royal MCP, miniOrange Secure MCP Server और AI Engine शामिल हैं। मैं यहां इन्हें एक category के रूप में handle कर रहा हूं। कोई रैंकिंग नहीं। मैं उनके feature claims को तथ्य के रूप में दोहरा भी नहीं रहा हूं। एक सावधानी मायने रखती है: लोकप्रिय comparison pages plugin vendors द्वारा run किए जाते हैं जो खुद को list करते हैं, इसलिए उन्हें table के साथ marketing के रूप में पढ़ें।

यह category जो देता है वह है speed। Plugin install करें, अपनी AI client में token paste करें, और आपको posts, media और अक्सर users और settings के लिए tools मिल जाते हैं। इसकी कीमत है trust। आप एक third-party author को एक endpoint दे रहे हैं जो WordPress user के रूप में act कर सकता है, एक PHP site पर जिसके पीछे एक पूरा admin area है।

एक plugin के लिए एकमात्र public security record जिसका मैं यहां हवाला दे रहा हूं, AI Engine के पास है:

• CVE-2025-11749। 3.1.3 तक के versions में, No-Auth URL option enabled होने पर, MCP bearer token site के public REST routes के माध्यम से leak हो गया। Unauthenticated attackers MCP endpoint को authenticate कर सकते थे और administrator accounts बना सकते थे। 3.1.4 में fixed, और 5 नवंबर 2025 को NVD को published किया गया (SentinelOne की write-up, जो leak को /mcp/v1/ endpoint पर रखती है और कहती है कि कोई verified public exploit code confirm नहीं हुआ है)।
• CVE-2026-8719। 17 मई 2026 को published, high (CVSS 8.8) rated। Version 3.4.9 में MCP OAuth bearer-token path ने administrator capability को check नहीं किया, इसलिए एक valid token वाला subscriber-level user admin-level MCP tools तक पहुंच सकता था और एक administrator बन सकता था (GitHub advisory)।
• एक लंबी सूची। WPScan कई और को list करता है, जिनमें multisite पर एक MCP user tools account takeover (3.6.1 में fixed) और CSRF के माध्यम से administrator account creation (3.6.6 में fixed) शामिल है।

इसके बारे में fair बनो कि यह क्या साबित करता है। यह एक plugin है। लोकप्रिय plugins scrutiny आकर्षित करते हैं, जो partly इस कारण है कि इस plugin का एक record है, और दूसरी जगह एक empty record safety का सबूत नहीं है। फिर भी, pattern मायने रखता है। दोनों headline bugs MCP door पर authorization failures हैं, ठीक जहां एक agent अपनी power प्राप्त करता है। उस part को याद रखें।

Headless CMS MCP servers: Sanity, Strapi, Contentful और Payload

Headless platforms ने अपने MCP servers को data model के चारों ओर बनाया। PHP admin के चारों ओर नहीं। वह difference documentation में दिखता है।

Sanity

Sanity https://mcp.sanity.io पर एक hosted server run करता है Streamable HTTP पर, OAuth डिफ़ॉल्ट रूप से और token auth एक विकल्प के रूप में। Agents GROQ queries run कर सकते हैं, releases manage कर सकते हैं और documents को आपके schema की जानकारी के साथ patch कर सकते हैं। Setup है npx sanity@latest mcp configure। पुराना local @sanity/mcp-server package deprecated है। यह current route है।

Docs draft-first writing का वर्णन करता है: create_documents drafts बनाता है जब तक कि आप releaseId pass न करें, patch_documents draft या release version में save करता है, और published content को कभी directly modify नहीं किया जाता। Publishing एक अलग tool है। प्रत्येक document के लिए patches एक single transaction के रूप में apply होते हैं। एक personal token आपकी role share करता है और आपको revision history में changes से link करता है, जबकि Authorization header में सेट किया गया token अपनी खुद की role और scope के within act करता है। दो catches हैं। Server development और project administration (schema deployment, datasets, CORS origins) को भी expose करता है, इसलिए token को carefully scope करें। और create_release कुछ भी schedule नहीं करता, जो Studio या HTTP Actions API में होना चाहिए।

Strapi

Strapi का MCP सर्वर बिल्ट-इन है और आपके अपने इंस्टेंस के अंदर चलता है। यह पहली बार v5.47.0 में दिखाई दिया और v5.49.0 में सामान्य उपलब्धता तक पहुँचा (Strapi blog, 3 सितंबर 2026)। डिफ़ॉल्ट रूप से यह बंद है: server.mcp.enabled false है। यह admin API tokens के साथ प्रमाणित होता है और प्रत्येक content type के लिए find, create, update, publish और unpublish tools को expose करता है। एक token कभी भी अपने मालिक की अनुमतियों से अधिक नहीं हो सकता, और मालिक को निष्क्रिय करने से यह रद्द हो जाता है। यह content types नहीं बनाता या मीडिया अपलोड नहीं करता; वे अभी भी REST API के माध्यम से जाते हैं (Strapi)।

Contentful और Payload

Contentful एक आधिकारिक ओपन-सोर्स MCP सर्वर प्रकाशित करता है (MIT लाइसेंस, npm package @contentful/mcp-server) जो agents को entries और assets को प्रबंधित करने, content types को अपडेट करने और tagging और migrations जैसी नौकरियों को स्वचालित करने देता है। इसे एक management access token और एक space ID की आवश्यकता है (Contentful)। एक अलग community सर्वर मौजूद है और आधिकारिक सर्वर की ओर इंगित करता है। Payload एक standalone सर्वर के बजाय एक आधिकारिक plugin के माध्यम से MCP जोड़ता है। Payload पर मैं यहाँ इससे आगे नहीं जाऊँगा।

यदि आप व्यापक रूप से Sanity को WordPress के विरुद्ध तौल रहे हैं, तो Sanity vs WordPress for enterprise गैर-MCP पक्ष को कवर करता है। निर्णय के उस हिस्से के लिए वहाँ शुरू करें।

Git-based Jamstack: pull request ही सुरक्षा जाल है

तीसरे पैटर्न के पास कोई CMS सर्वर नहीं है। Content, repo में Markdown, MDX या typed JSON के रूप में रहता है, और साइट Astro या Next.js है। एक coding agent फाइलें edit करता है। यह एक pull request खोलता है, host एक preview deploy बनाता है, और एक इंसान merge करने से पहले diff को पढ़ता है। Vercel और Netlify दोनों git-based deployment और preview deploys करते हैं, जो इस पैटर्न को host से चाहिए।

यह pull-request loop असामान्य नहीं है। Next.js दस्तावेज़ करता है कि यह AI coding agents को कैसे सपोर्ट करता है, और एक Microsoft Azure Static Web Apps tutorial मानक wiring दिखाता है: एक GitHub Actions workflow जो pull request opened, synchronize, reopened और closed पर trigger होती है, preview को tear down करने के लिए एक अलग job के साथ। यह सामान्य delivery machinery है। यह अपील का हिस्सा है।

यह agents के लिए क्यों उपयुक्त है यह सरल है। हर बदलाव एक reviewable diff है। कोई भी चीज़ production तक तब तक नहीं पहुँचती जब तक कोई इंसान merge न करे। Rollback एक git revert है। public site static output है, इसलिए कोई admin login नहीं है जिस तक एक चोरी किया गया agent token पहुँच सके।

लागतें असली हैं, हालाँकि। गैर-तकनीकी editors को friction मिलता है, क्योंकि git उनका tool नहीं है। यहाँ कुछ भी एक दस्तावेज़ MCP सर्वर नहीं है जिसके पास एक security record हो; agent एक coding agent है जिसके पास repo access है, इसलिए आपका exposure इसके git token का scope है और जो कुछ भी इसका shell छू सकता है। Supply-chain hygiene अभी भी लागू होता है। मैंने इसे Next.js, Astro और Nuxt security in 2026 में कवर किया।

किसी भी stack पर MCP जोखिम, और जो नियंत्रण उन्हें कम करते हैं

NSA ने जून 2026 में MCP security पर एक Cybersecurity Information Sheet प्रकाशित किया, और Microsoft ने 2026 में MCP security की स्थिति के बारे में लिखा। शब्दावली को छोड़ दें और चार जोखिम लगातार वापस आते हैं।

• Inherited permissions। Agent अपने MCP सर्वर की credentials जो कुछ भी कर सकता है कर सकता है। एक admin token का मतलब एक admin agent है।
• Tool poisoning। Tool descriptions को model द्वारा पढ़ा जाता है, इसलिए एक malicious या compromised सर्वर उनमें निर्देश छिपा सकता है। यही कारण है कि third-party सर्वर install करने से पहले एक review के योग्य हैं।
• Prompt injection। Content जो agent पढ़ता है (एक comment, एक scraped page, एक support ticket जिसे draft में paste किया गया हो) निर्देश ले जा सकता है। Agent अपने स्वयं के write access के साथ उनका पालन कर सकता है।
• अत्यधिक विशेषाधिकार वाले टोकन। सुविधा लोगों को एक व्यापक टोकन सौंपने के लिए प्रेरित करती है। ऐसा मत करो।

नियंत्रण सुस्त हैं। ये काम करते हैं। एजेंट को न्यूनतम-विशेषाधिकार टोकन दो, केवल-पढ़ने या केवल-ड्राफ्ट स्कोप को प्राथमिकता दो, और प्रकाशित और हटाने के सामने मानव अनुमोदन रखो। ऑडिट लॉग रखो जिन्हें तुम वास्तव में पढ़ोगे। जब कोई भी चला जाए तो टोकन घुमाओ। इनमें से कोई भी स्टैक-विशिष्ट नहीं है, और यही बात है। स्टैक केवल यह तय करता है कि तुम्हारे लिए कितना काम पहले से ही पूरा हो गया है।

एजेंट-तैयारी स्कोरकार्ड

यहाँ तुलना एक जगह है। रेटिंग प्रलेखित विशेषताओं और सार्वजनिक रिकॉर्ड से आती है, स्रोत ऊपर नाम दिए गए हैं। इस तालिका के लिए किसी ने इन स्टैकों को परीक्षण सूट के माध्यम से नहीं चलाया। इसे प्रलेखित तुलना के रूप में मानो, प्रयोगशाला परिणाम नहीं।

शक्तिशाली का अर्थ है प्रलेखन इसे डिफ़ॉल्ट रूप से कवर करता है। आंशिक का अर्थ है प्रलेखित लेकिन अधूरा, या केवल एक छोटे रिकॉर्ड द्वारा समर्थित। सेटअप पर निर्भर करता है का अर्थ है स्टैक यह तय नहीं करता। तुम्हारा कॉन्फ़िगरेशन। कमजोर का अर्थ है प्रलेखित समस्याएँ।

संक्षेप में प्रत्येक रेटिंग क्यों।

WordPress + Adapter। अनुमतियाँ शक्तिशाली हैं क्योंकि हर क्षमता अपनी जाँच के साथ आती है और क्षमताएँ निजी होती हैं जब तक वे सार्वजनिक के रूप में चिह्नित न हों। ड्राफ्ट नियंत्रण उन क्षमताओं पर निर्भर करता है जो तुम स्थापित करते हो, जैसा कि चरणबद्ध-अपडेट उदाहरण ने दिखाया। ऑडिट आंशिक है: अवलोकनीयता इंटरफेस मौजूद हैं, लेकिन एक देशी ऑडिट लॉग नहीं है। प्रमाणीकरण आंशिक है, प्रति-सर्वर परिवहन प्रमाणीकरण उच्च स्तर पर प्रलेखित है। रिकॉर्ड आंशिक है क्योंकि पैकेज युवा है और इसका दस्तावेज़ स्पष्ट रूप से पलायन-मध्य है।

WordPress प्लगइन। एक श्रेणी के पार कुछ भी एकसमान नहीं है, इसलिए अधिकांश कक्ष प्लगइन पर निर्भर करते हैं। रिकॉर्ड कमजोर है जहाँ प्रलेखित है: ऊपर दिए गए AI Engine प्रविष्टियाँ, और केवल वही। वह अंतर मायने रखता है।

Sanity। भूमिका-स्कोप किए गए टोकन, ड्राफ्ट-डिफ़ॉल्ट लिखता है, रिलीज़ और संशोधन इतिहास शक्तिशाली रेटिंग अर्जित करता है। पूर्वावलोकन आंशिक है क्योंकि एक रिलीज़ एक मंचन अवधारणा है, लेकिन MCP सर्वर रिलीज़ को शेड्यूल या प्रकाशित नहीं कर सकता। रिकॉर्ड आंशिक है छोटेपन के अर्थ में। बुरा नहीं।

Strapi। प्रति-सामग्री-प्रकार उपकरण और मालिक-बाउंड टोकन अनुमतियों और प्रमाणीकरण पर शक्तिशाली हैं। प्रकाशित और अप्रकाशित अलग उपकरण हैं, और सर्वर बंद रहता है जब तक तुम इसे चालू न करो। ऑडिट और पूर्वावलोकन इस बात पर निर्भर करते हैं कि तुम अपना उदाहरण कैसे चलाते हो। स्व-होस्टिंग का अर्थ है पैचिंग तुम्हारी है।

Contentful. आधिकारिक सर्वर को एक प्रबंधन टोकन और स्पेस ID की जरूरत है, जो व्यापक पहुँच का संकेत देता है, इसलिए मैं अनुमतियों और प्रमाणीकरण को आंशिक मानता हूँ। ड्राफ़्ट हैंडलिंग, ऑडिट और पूर्वावलोकन इस बात पर निर्भर करते हैं कि आप स्पेस और भूमिकाओं को कैसे कॉन्फ़िगर करते हैं। महत्वपूर्ण काम उस कॉन्फ़िगरेशन में है।

Payload. एक आधिकारिक प्लगइन मौजूद है। इसके अलावा, मेरे पास आकलन करने के लिए कोई प्राथमिक दस्तावेज़ नहीं है, इसलिए हर सेल सेटअप पर निर्भर करता है। यह एक ऐसा अंतराल है जिसे मैं सत्यापित नहीं कर सकता। यह निर्णय नहीं है।

Git-based Jamstack. चार कॉलम में मजबूत है क्योंकि पैटर्न स्वयं उन्हें प्रदान करता है: शाखा-स्तरीय रेपो अनुमतियाँ, प्रकाशन गेट के रूप में पुल रिक्वेस्ट, git इतिहास और रिवर्ट, पूर्वावलोकन तैनाती। प्रमाणीकरण कोडिंग एजेंट और उसके git टोकन पर निर्भर करता है। रिकॉर्ड आंशिक है क्योंकि हमलों के लिए कोई CMS व्यवस्थापक सतह नहीं है। एजेंट टूलिंग अभी भी सब कुछ की तरह ही MCP जोखिम रखती है।

आज कैसे चुनें, स्थिति के अनुसार

आपके पास एक मौजूदा WordPress संपत्ति है

जहाँ हो वहीं रहें और सख्त रहें। आधिकारिक एडेप्टर का उपयोग करें, केवल उन क्षमताओं को सार्वजनिक के रूप में चिह्नित करें जिनकी आपको जरूरत है, और ऐसी क्षमताएँ लिखें या चुनें जो परिवर्तनों को लागू करने से पहले स्टेज करें। व्यापक टोकन वाला एक तीसरे पक्ष का प्लगइन इस पूरी तुलना में सबसे जोखिमपूर्ण सेटअप है। यदि आप पहले फ्रंट एंड से WordPress को ढीला करना चाहते हैं, तो headless WordPress विकास एक मध्य पथ है।

आप एक नया निर्माण शुरू कर रहे हैं

यदि एजेंट इसे चलाने में मदद करेंगे, तो headless या git-based से शुरू करें। Sanity या Strapi आपको ड्राफ़्ट और स्कोप्ड टोकन बॉक्स से बाहर देते हैं। रेपो में Astro या Next.js आपको diffs और पूर्वावलोकन देते हैं। यह नए काम के लिए एक मजबूत डिफ़ॉल्ट है।

आपकी सामग्री टीम बड़ी है, या गैर-तकनीकी है

संपादकों की एक टीम जो एक दृश्य इंटरफेस में रहती है, पुल रिक्वेस्ट का आनंद नहीं लेगी। एक उचित संपादन स्टूडियो के साथ headless उन्हें बेहतर सूट करता है, बशर्ते एजेंट ड्राफ़्ट तक सीमित हो। WordPress के संपादक यहाँ वास्तव में अच्छे हैं। यह इसके पक्ष में एक बिंदु है।

आपके पास अनुपालन की जरूरतें हैं

पूछें कि ऑडिट ट्रेल कहाँ रहता है और उसका मालिक कौन है। Git इतिहास एक मजबूत जवाब है। Sanity का संशोधन इतिहास एक और है। WordPress के लिए, आप स्वयं लॉगिंग बना रहे होंगे। Self-hosted विकल्प (Strapi, WordPress) डेटा को आपके बुनियादी ढाँचे में रखते हैं लेकिन पैचिंग को आप पर डालते हैं, जबकि एक होस्ट किया गया सर्वर वह बोझ विक्रेता को स्थानांतरित करता है।

2027 में: AI-चलित साइटों के लिए Jamstack बेहतर घर क्यों हो सकता है

यह खंड राय है, खोज नहीं है, और मैं इसे हल्के ढंग से रखता हूँ।

क्यों Jamstack आगे निकल सकता है। सामग्री संरचित और टाइप किया गया है। हर एजेंट परिवर्तन एक diff हो सकता है जिसकी एक इंसान समीक्षा करता है। पूर्वावलोकन तैनाती लाइव होने से पहले परिणाम दिखाते हैं। रोलबैक एक git revert है। सार्वजनिक साइट के पास चोरी किए गए एजेंट टोकन के लिए पहुँचने के लिए कोई व्यवस्थापक सतह नहीं है। एजेंट फाइलें संपादित करने में अच्छे हैं और विश्वास किए जाने में बुरे हैं, और यह सेटअप ठीक उसी संयोजन के लिए बनाया गया है।

क्यों WordPress नहीं हार सकता। इसका सबसे बड़ा स्थापन आधार और प्रतिभा पूल है। Abilities API अब कोर में है, इसके साथ एक आधिकारिक एडेप्टर है। प्लगइन विक्रेता तेजी से पुनरावृत्ति करते हैं। तेजी से पुनरावृत्ति बहुत कुछ ठीक करती है, भले ही इसने ऊपर CVEs बनाए हों।

WordPress को क्या चाहिए। कोर में MCP, डिफ़ॉल्ट रूप से क्षमताओं के लिए मैप की गई क्षमताओं के साथ। केवल ड्राफ़्ट एजेंट भूमिकाएँ। एक नेटिव ऑडिट लॉग। MCP प्लगइन के लिए एक बेहतर सुरक्षा रिकॉर्ड। यह एक छोटी सूची है, और इसमें से कुछ भी असंभव नहीं है।

यदि उस दृष्टिकोण ने आपको एक चाल तौलने के लिए प्रेरित किया, तो WordPress को छोड़ने के लिए गाइड शुरू करने के लिए जहाँ है।

व्यावहारिक रेखा: एक नई साइट के लिए जो एजेंट चलाने में मदद करेंगे, Jamstack या headless से शुरू करें। एक मौजूदा WordPress संपत्ति के लिए, एक व्यापक तीसरे पक्ष के प्लगइन के बजाय न्यूनतम-विशेषाधिकार क्षमताओं के साथ आधिकारिक एडेप्टर का उपयोग करें। यहाँ उबाऊ रहें।

FAQ

क्या मैं WordPress MCP को read-only मोड में चला सकता हूँ?

सिद्धांत में, हाँ। क्षमताएँ डिफ़ॉल्ट रूप से निजी हैं, इसलिए केवल उन क्षमताओं को उजागर करें जो डेटा पढ़ते हैं और कुछ भी जो लिखता है उसे अपंजीकृत या अचिह्नित छोड़ दें। एडेप्टर के पास एक एकल read-only स्विच नहीं है। अनुशासन उन क्षमताओं में बैठता है जिन्हें आप पंजीकृत करते हैं।

कौन सी AI क्लाइंट जुड़ सकती हैं?

WordPress के लिए, कुछ भी जो HTTP या STDIO पर MCP बोलता है (WP-CLI के माध्यम से)। Sanity का दस्तावेज़ Claude Code, Cursor, VS Code, Lovable, Replit और v0 को संगत क्लाइंट के रूप में सूचीबद्ध करता है, और वहाँ OAuth सत्र आमतौर पर 7 दिन बाद समाप्त हो जाते हैं। क्लाइंट पसंद कठिन हिस्सा नहीं है।

होस्ट की गई MCP सर्वर self-hosted से अधिक सुरक्षित है?

यह एक जोखिम को दूसरे से बदल देता है। Sanity जैसा होस्ट किया गया सर्वर पैचिंग को विक्रेता तक ले जाता है, लेकिन आप उनके स्कोपिंग और अपनी टोकन हाइजीन पर निर्भर हैं। Strapi जैसा सर्वर आपके इंस्टेंस के अंदर सब कुछ आपके इंफ्रास्ट्रक्चर में रखता है। अपडेट आपका काम है।

क्या मुझे अपना खुद का MCP सर्वर बनाना चाहिए?

केवल तब अगर आपको ऐसे उपकरणों का एक संकीर्ण सेट चाहिए जो आधिकारिक लोग नहीं देते हैं। तीन उपकरणों वाला एक छोटा, उद्देश्य-निर्मित सर्वर एक विस्तृत सर्वर की तुलना में समझने में आसान है। Supabase और TypeScript के साथ MCP सर्वर बनाने की एक वॉकथ्रू है। सतह को छोटा रखें।

सबसे तीव्र सावधानी सबसे सुस्त है: एक एजेंट अपनी टोकन जो कुछ भी कर सकता है उसे विरासत में पाता है, और इस तुलना में एकमात्र सार्वजनिक MCP सुरक्षा रिकॉर्ड एक WordPress प्लगइन की CVE की सूची है, जो स्टैक चुनने से पहले टोकन को स्कोप करने का कारण है। ऊपर दिए गए रेटिंग परीक्षण से नहीं, दस्तावेज़ और सार्वजनिक सलाह से आते हैं। स्टैक चुनाव को अनुमति मॉडल के लिए माध्यमिक मानें।