ByteCoreStack – MCP Connector for AI Tools

Nejčastější dotazy

Is ByteCoreStack – MCP Connector for AI Tools free?

Yes, the plugin is completely free with no premium tiers, license keys, usage caps, or feature paywalls — every tool listed in this readme is included.

I have Wordfence, All In One WP Security, or another security plugin — do I need to change anything before connecting?

Possibly, yes — check this before you report a connection failure as a bug. Security plugins commonly ship a firewall setting that restricts or disables the WordPress REST API for anyone who isn’t logged into wp-admin. This plugin’s MCP/OAuth endpoints are intentionally reachable without a WordPress login — they authenticate the AI client themselves via OAuth 2.0 Bearer tokens, not a WordPress session — so that kind of blanket „REST API requires login“ setting is the wrong gate for them.

As of version 1.2.1, this plugin automatically exempts its own routes from that specific kind of lockdown, so most users won’t need to do anything. But if a connection still fails after updating:

1. In your security plugin’s firewall settings, look for a „restrict/disable the REST API for logged-out users“ (or similarly worded) toggle and turn it off, or add an allowlist entry for this plugin’s URLs instead.
2. Allowlist these paths specifically: /.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, /authorize, /token, /register, and /wp-json/bcs-mcp/*.
3. Make sure the HTTP DELETE method isn’t blocked for /wp-json/bcs-mcp/* — some firewalls block it by default (used for MCP session cleanup).
4. Run ByteCoreStack – MCP Connector for AI Tools → Diagnostics → Test Connection — it detects active security plugins and gives you a specific, current status for each check rather than a generic pass/fail.

Two important exceptions this plugin cannot fix on its own — but will now tell you about automatically (as of 1.2.1) via a dismissible notice on the Plugins screen and this plugin’s own screens:

• Some hosting environments (particularly nginx-based hosts and some CDNs) block access to any dot-prefixed path — like .well-known/, .env, or .git — at the web server level, before the request ever reaches WordPress or PHP. If Diagnostics or the admin notice reports that the discovery endpoint’s response „never reached WordPress,“ that’s this case: no WordPress or security-plugin setting can fix it, because it’s not being blocked by WordPress or the plugin — it’s blocked by the server/CDN infrastructure itself. You’ll need to ask your hosting provider (or your CDN, e.g. Cloudflare, Sucuri) to explicitly allow /.well-known/* through, since OAuth (RFC 8414) requires that path to be reachable.

  SiteGround specifically is the most commonly reported case of this. SiteGround’s nginx reserves the entire /.well-known/ prefix for their own SSL certificate (ACME) validation and returns a 404 for anything else under it — fleet-wide, and per multiple independent reports SiteGround support has declined to adjust this per-site, so a support ticket may not resolve it. You can confirm you’re on SiteGround by checking the response headers at https://yoursite.com/.well-known/oauth-authorization-server for X-CDN-C: static (SiteGround’s free CDN tier signature). If that’s your situation, the two working paths are:

  1. Put Cloudflare (free tier works) in front of your site, and add a Cloudflare Worker or Page Rule that intercepts /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource specifically and serves/proxies them before the request ever reaches SiteGround’s nginx. This is the workaround other SiteGround-hosted sites in this situation have used successfully.
  2. Ask SiteGround support anyway to allowlist those two specific paths for your domain — low odds based on other reports, but it costs nothing to ask.
• Some hosts redirect POST /register to /register/ with an HTTP 301 (a generic trailing-slash canonicalization rule). OAuth clients don’t follow redirects on POST requests, so registration silently dies before it ever reaches this plugin — even when .well-known/ discovery works perfectly fine. This is also a web-server config issue, not a WordPress setting; ask your host to exempt /register, /token, and /authorize from trailing-slash redirects.

My host blocks /.well-known/ and won’t fix it (e.g. SiteGround) — can I manually add an OAuth Client ID in my AI client to work around it?

Maybe, and it’s worth trying, but understand what it does and doesn’t fix before you spend time on it. This plugin has no admin screen for pre-creating a Client ID/Secret — the only way to get one is to call this plugin’s own /register endpoint directly (the same endpoint your AI client would normally call automatically):

curl -X POST https://yoursite.com/register -H "Content-Type: application/json" -d '{"client_name": "Claude", "redirect_uris": ["https://claude.ai/api/mcp/auth_callback"], "token_endpoint_auth_method": "client_secret_post", "grant_types": ["authorization_code", "refresh_token"]}'

The JSON response contains client_id and client_secret — paste both into your AI client’s connector settings.

The catch: supplying a Client ID only skips the registration step. Your AI client still needs to know where /authorize and /token live, and it normally learns that by reading /.well-known/oauth-authorization-server — the exact document that’s blocked in this scenario. A Client ID alone doesn’t tell it where to send the user for consent or where to exchange the authorization code. Before generating one, check whether your AI client’s connector settings also have fields to manually specify the authorization and token endpoint URLs (https://yoursite.com/authorize and https://yoursite.com/token) alongside the Client ID/Secret. If those fields don’t exist, this workaround won’t fully solve a blocked .well-known/ path — you’ll need the Cloudflare-in-front-of-your-host fix described in the previous FAQ entry instead.

Will updating to version 1.1.0 break my existing AI connection or settings?

No. Version 1.1.0 is a fully backward-compatible update: your existing OAuth connection, access tokens, Settings, and Activity Log history all carry over automatically — nothing is reset, revoked, or reconfigured. The plugin was renamed from „AI Connector – MCP for Claude, ChatGPT, Gemini & More“ to „ByteCoreStack – MCP Connector for AI Tools,“ but the plugin slug, database tables, and MCP URL are unchanged, so Claude, ChatGPT, Gemini, Cursor, and Windsurf all keep working without needing to reconnect. New tools simply appear the next time your AI client refreshes its tool list.

What is MCP (Model Context Protocol)?

MCP is an open standard, originally created by Anthropic, that lets AI assistants like Claude and ChatGPT securely connect to external tools and data sources using a structured, authenticated protocol instead of free-text copy-paste. This plugin implements a full MCP server inside WordPress so any MCP-compatible AI client can read and manage your site’s content directly.

What’s the best MCP server for WordPress?

There are a few MCP servers for WordPress, and the right one depends on what you need. ByteCoreStack – MCP Connector for AI Tools’s focus is breadth of verified tools (316+ across 26 categories), real OAuth 2.0 with PKCE instead of a shared API key, and zero telemetry — every action is capability-checked and recorded in your own database rather than sent anywhere else. If you’re comparing options, look closely at tool coverage, how authentication actually works, and what happens to your data; ByteCoreStack – MCP Connector for AI Tools is built to hold up well on all three.

Which AI clients are supported?

Any client that implements the MCP 2025-11-25 Streamable HTTP transport. Tested and confirmed working with Claude.ai, Claude Desktop, Claude Code, ChatGPT, Cursor (0.45+), and Windsurf. Gemini uses the same standard protocol and is expected to work via Google AI Studio’s MCP integrations. Editors and IDEs with general-purpose MCP client support — VS Code, Continue, Cline, Zed, JetBrains — and API tools like Postman also connect successfully. Older client versions that use the legacy SSE transport are supported via the /sse endpoint.

Can an AI agent manage my entire WordPress site?

It can call any of the 316+ MCP tools this plugin exposes — content, WooCommerce, SEO, media, comments, users, backups, CRM, and more — but always scoped to what the authorizing WordPress user is allowed to do. No MCP tool creates new WordPress users, and role changes require the promote_users capability specifically. Think of it as an AI assistant with exactly the permissions of whoever connected it, not an unsupervised admin.

How do I connect Claude.ai to my WordPress site?

Go to Claude.ai → Settings → Integrations → Add integration → Custom MCP. Paste your MCP URL (https://yoursite.com/wp-json/bcs-mcp/v1/mcp) and follow the OAuth authorization flow. Claude handles client registration and token management automatically.

How do I connect ChatGPT?

In ChatGPT: Settings → Connectors → Add connector → MCP Server. Paste your MCP URL and complete the OAuth flow. Your site must be publicly accessible (not localhost) and on HTTPS.

How do I connect Claude Desktop?

Add the following to your claude_desktop_config.json file under mcpServers:

"wordpress": { "url": "https://yoursite.com/wp-json/bcs-mcp/v1/mcp", "transport": "http" }

Restart Claude Desktop and authorize via the OAuth consent page that opens in your browser.

How do I connect Cursor?

In Cursor: Settings → MCP → Add New Server → select type HTTP → paste your MCP URL. Cursor uses the Streamable HTTP transport and sessions tracked via the Mcp-Session-Id header. Ensure your WordPress site is on HTTPS.

How do I connect Windsurf?

Open Windsurf’s MCP settings and add a new server with your MCP URL. Recent Windsurf versions use Streamable HTTP; older versions connect via the legacy SSE endpoint at /sse. Both are supported automatically.

Does this work with WooCommerce?

Yes. 36 tools covering products, variations, attributes, coupons, orders, refunds, customers, shipping zones, tax rates, payment gateways, store statistics, subscriptions, and bookings activate automatically once WooCommerce (and WooCommerce Subscriptions / Bookings, where relevant) is detected — no extra configuration required.

Does this work with Elementor, ACF, or Gravity Forms?

Yes, all three are supported. Tools for each only become active when the respective plugin is installed and active, and the AI client only ever sees the tools whose dependencies are actually satisfied on your site.

Does this work with backup and CRM plugins?

Yes. UpdraftPlus tools let an AI client list backups, trigger a new backup, and check job status. FluentCRM tools let it list contacts, create or update a contact, and list email campaigns. Both integrations activate automatically when the respective plugin is detected — no extra setup required.

Does this work with BuddyPress or The Events Calendar?

Yes. BuddyPress tools cover members, extended profile fields, the activity stream, groups, group members, and friend connections. The Events Calendar tools cover full event CRUD plus venues, organizers, and event categories. Both activate automatically when the respective plugin is detected — no extra configuration required.

Which SEO plugins are supported?

Yoast SEO, Rank Math, All in One SEO, SEOPress, Slim SEO, and The SEO Framework. The plugin detects whichever one is active and reads/writes its native storage directly — per-post title, meta description, focus keyword, and noindex status, plus site-wide title separator and homepage title/description.

My AI client shows fewer than 316+ tools — is that a bug?

No, that’s expected. 316+ is the plugin’s total tool count across every supported integration. The list your AI client actually sees is filtered down to only the tools that will work on your specific site — so anything gated behind a plugin you don’t have active (WooCommerce, ACF, Elementor, a supported SEO plugin, BuddyPress, The Events Calendar, and so on) simply isn’t advertised. A fresh WordPress install with none of those companion plugins active will see roughly 124 core tools; each supported plugin you activate adds its tools to the list automatically. To see the full 316+, install and activate every supported integration.

Can I add my own custom tools?

Yes. Use bcs_mcp_register_tool() or the bcs_mcp_tools filter from any plugin or your theme’s functions.php. See the Other Notes tab for a code example.

Can AI delete or change things without my permission?

Every tool call is checked against real WordPress capabilities before it runs — an AI client can never do more than the authorizing user is allowed to do. Destructive actions are logged in the Activity Log, and you can revoke access instantly from Settings → Reset OAuth State.

Can AI create new WordPress users or admin accounts?

No, and there is no setting to turn this on. No MCP tool in this plugin can create a WordPress user under any circumstance — new accounts must always be created through wp-admin by a human. Role changes are still possible through wp_assign_user_role, but only for a token authorized by a user with the promote_users capability.

Can I restrict which IPs can connect?

Yes. Add an IP allowlist (single IPs or CIDR ranges) in Settings, and the MCP endpoint will reject any request from outside that list.

Is there rate limiting to prevent abuse?

Yes. Every request to the /mcp endpoint is limited to 60 requests per minute per IP address, enforced automatically with no configuration needed — requests over that limit get an HTTP 429 response instead of reaching your database. Dynamic Client Registration (the endpoint AI clients use to register themselves) has its own separate limit of 10 registrations per IP per minute.

Can I use this for WordPress AI automation and workflows?

Yes. Because ByteCoreStack – MCP Connector for AI Tools exposes real WordPress actions as MCP tools instead of just answering questions, your AI assistant can chain several steps together in one request — draft a post, generate a featured image, assign categories, and publish, for example. Each step still runs through the same permission checks and Activity Log as if you’d done it by hand in wp-admin.

Does this plugin collect any user data or telemetry?

No external telemetry of any kind. The Activity Log does record each tool call’s parameters and result locally, in your own WordPress database, so you can audit and debug what your AI client has done — values that look like passwords, tokens, or secrets are redacted before they’re written, and large content fields are truncated. None of this data is ever sent anywhere outside your own server, and the plugin includes zero analytics or tracking code.

Will this slow down my WordPress site?

No. The MCP server only runs when an AI client actively makes a request to the /mcp endpoint — there is no background polling, no front-end script, and no impact on normal page load times for your visitors.

Does this work on WordPress multisite?

Yes, per-site. Each site on the network gets its own settings, its own MCP URL, and its own Activity Log. There is no shared or cross-site tool access. The wp_get_multisite_info tool lets a connected AI client check network status and list network sites when multisite is enabled.

What happens if I uninstall the plugin?

A clean uninstall removes every database table the plugin created (logs, OAuth tokens, OAuth clients, authorization codes), every plugin option, and every transient it set. No orphaned data is left behind in your database.

I restored my site from a backup and my AI client can’t reconnect. What do I do?

Database restores can leave your AI client holding OAuth credentials that no longer match what’s stored on the (restored) site. Go to ByteCoreStack – MCP Connector for AI Tools → Settings → Reset OAuth State to clear all stored tokens and client registrations, then remove and re-add the connector in your AI client to trigger a fresh authorization flow.

I see „Couldn’t register with sign-in service“ in Claude

Claude shows this when it can’t reach /register or the /.well-known/oauth-authorization-server discovery endpoint it depends on. There are two distinct causes with different fixes:

1. OAuth rewrite rules haven’t been flushed. Log in to wp-admin — the plugin auto-flushes on the first admin page load after each update. If the error persists, go to Settings → Permalinks and click Save Changes.
2. Your web server or CDN is blocking /.well-known/* before it ever reaches WordPress. This is a different problem than #1, and no WordPress or plugin setting can fix it. Many nginx-based hosts ship a blanket rule blocking any dot-prefixed path (meant to block .env/.git/.htaccess exposure) that also catches .well-known/, which OAuth (RFC 8414) requires to be reachable. You can tell the two apart: visit https://yoursite.com/.well-known/oauth-authorization-server directly in a browser — if you get your site’s normal 404 page, it’s #1; if you get a bare, unstyled 404 with no site branding at all (or the connection just times out), it’s #2. For #2, run Diagnostics → Test Connection — as of 1.2.1 it detects this specific case and tells you plainly. The fix has to happen at the server/CDN level: ask your host or CDN provider (e.g. Cloudflare) to explicitly allow /.well-known/* through their firewall/dotfile-blocking rule.

Cursor says it can’t establish a session

Ensure your WordPress site is on HTTPS and publicly accessible. Cursor requires the Mcp-Session-Id header in the server’s initialize response — this plugin sends it correctly. If you’re behind a caching plugin or CDN, make sure /wp-json/bcs-mcp/* is excluded from caching.

My site uses nginx. Will SSE work?

Yes. The plugin sends X-Accel-Buffering: no on SSE responses to prevent nginx from buffering the stream. No additional nginx configuration is required.

My site is on HTTP (not HTTPS). Will this work?

OAuth 2.0 requires HTTPS for security, and most AI clients will refuse to connect to non-HTTPS endpoints. A valid SSL certificate is strongly recommended. For local development with localhost, HTTP is allowed by the OAuth redirect URI validator.

How do I disconnect an AI client?

Go to ByteCoreStack – MCP Connector for AI Tools → Settings → Reset OAuth State. This revokes all tokens and clears all registered clients. Any connected AI client will need to re-authorize.

I see „This connector has no tools available“ the first time I connect, but disconnecting and reconnecting fixes it. Is this a bug in the plugin?

No — this is a confirmed Claude Desktop client bug, not a server-side issue. Anthropic’s own GitHub tracker documents it (issue #60222 and related reports #5826, #22299, #23736, #14807, #38343): the first tools/list call after connecting a Streamable HTTP + OAuth connector can fail or return empty in Claude Desktop specifically, and the affected server’s own logs show zero incoming traffic during the failure — proving the request never left the client. The same connection works without issue through Claude Code CLI and Claude.ai web the whole time. Anthropic closed the issue as „not planned,“ so there’s no fix timeline, and nothing on the server side can prevent it since it happens before any request reaches this plugin.

The workaround is exactly what fixes it for you: disconnect and reconnect the connector, which re-runs initialize/tools/list and typically restores the tool list. If a tool call ever seems to hang or silently no-op right after reconnecting, try it once more — the same report notes the very first call can occasionally still fail once before settling.

My connection broke after a plugin or theme update. Where do I start troubleshooting?

Update to the latest version of ByteCoreStack – MCP Connector for AI Tools first — most connection issues are fixed in the next release. If the problem persists: (1) temporarily deactivate other plugins to rule out a conflict, (2) check that your caching plugin or CDN excludes /wp-json/bcs-mcp/*, (3) reset OAuth state from Settings and reconnect, (4) check the Activity Log for the specific error status on the failing tool call.

I have Wordfence, All In One WP Security, or another security plugin — my AI client can’t connect. What do I do?

See „I have Wordfence, All In One WP Security, or another security plugin — do I need to change anything before connecting?“ near the top of this FAQ for the full walkthrough (what this plugin already handles automatically, what to allowlist manually, and the separate server/CDN-level .well-known blocking case that no plugin setting can fix).