GetMCP

Love these questions — let me take them one by one. 🙂

1. No unlimited sites?
We deliberately capped the top tier at 200 activations. Unlimited + lifetime is the combination that kills lifetime deals — it invites seat reselling and makes support quality collapse for everyone who bought honestly. 200 sites is “unlimited” for any real agency, and it keeps this deal something we can support properly for years.

2. Why GetMCP when FlowMattic has MCP?
They’re built for different things. FlowMattic’s MCP server is tied to the integrations FlowMattic ships, and it’s for your personal use — your AI assistant working with your own connected apps and workflows. GetMCP has no such boundary: point it at any REST API and build MCP servers both for yourself and as an app developer for your users. Your SaaS customers, your agency clients — each gets their own MCP server URL, with its own auth (API keys, OAuth 2.1), per-client rate limits, call logs, PII redaction, and response shaping. In short: FlowMattic’s MCP is a feature for you; GetMCP makes MCP something you can ship to others. Plenty of people will happily run both.

3. Roadmap?
Good timing — we’re putting the finishing touches on a public roadmap right now, and it goes live within the next 24 hours. I’ll drop the link here as soon as it’s up, and you’ll be able to see what’s shipping next and vote on what matters to you. Meanwhile, judge us by the pace so far: 1.0 shipped the visual builder, four import formats and OAuth; 1.1–1.3 added the Chat Playground, JMESPath response pruning, PII redaction, and same-week support for the latest MCP spec (2026-07-28). The core promise doesn’t change: when the spec moves, GetMCP moves with it — and lifetime buyers get all of it.

4. How many tools tested per site?
The whole team hammered on this before launch, so I can’t give you one exact number — but here’s the scale: we created 40+ MCP servers in testing, totalling 350+ tools across them, and ran each server on different machines with roughly 10–15 MCP test runs per server. There’s no hard cap on tools — each one is a stored definition served on discovery, and each call is a single HTTP request. In practice the ceiling is the AI client’s context window, not GetMCP — which is exactly why the pruning and redaction features exist. Best practice: group tools into focused servers per product area rather than one giant catalog.

5. Hosting requirements?
If it runs WordPress, it runs GetMCP: WordPress 6.2+, PHP 8.0+, HTTPS. No Node, no containers, no external services — the MCP transport is plain HTTP served by your existing stack. We recommend a subdomain install (mcp.yourdomain.com) to keep it tidy. A modest VPS or decent shared hosting handles thousands of tool calls a day, since each call is just a lightweight JSON-RPC request plus your API’s own response time.

Yes, we do have plans to expand GetMCP to be available as pure self hosted version as well, but we don’t have any ETA on that. Currently we are focusing on the WP Plugin only. Though GetMCP is a WordPress plugin, it needs WordPress as backend framework only 🙂

Excellent question, Bryan! — security was a day-one design priority, so let me give you specifics rather than marketing-speak.

Credential storage:

-> All credentials — API keys, OAuth tokens, auth secrets — are encrypted at rest using libsodium authenticated encryption (XSalsa20-Poly1305 AEAD), with keys derived via HKDF-SHA256 from your WordPress salts. Not plaintext, not weak hashing — real authenticated encryption with a random nonce per value.

-> The plugin refuses to store credentials at all if the encryption stack is unavailable or your WP keys are weak — it fails safe, never falls back to plaintext.

-> Credentials never enter the AI’s context. GetMCP injects them server-side when calling your upstream
API — Claude/ChatGPT never see or hold your keys. And the inbound MCP token a client presents is stripped before the upstream call, so it can never leak to the external API either.

How AI clients authenticate to your server:

-> Full OAuth 2.1 — PKCE mandatory (S256 only), exact redirect-URI matching, single-use auth codes, short-lived access tokens with rotating refresh tokens, all hashed in the database. This is the current MCP auth spec, implemented properly.

-> Or per-server API keys — generated with a cryptographically secure RNG, stored only as SHA-256 hashes, shown once.

-> Failed auth attempts are rate-limited per IP, so brute-forcing credentials gets expensive fast.

Logging:

-> Call logs are HMAC-signed and append-only, with a daily integrity verification — tamper-evident logging, which matters if you ever need audit trails for compliance.

-> Configurable PII redaction (emails, cards, SSNs, phone numbers, IPs, AWS keys, JWTs, plus your own custom patterns) — applied both before logs are stored and before responses reach the AI client.

-> Sensitive argument fields are sanitized before logging; full request/response bodies are only logged if you explicitly opt in.

-> Retention is configurable (30 days default, auto-purged).

WordPress-level concerns:

-> Every REST route is capability-gated; every database query is prepared — no SQL interpolation anywhere.

-> Public MCP endpoints get body-size caps, per-IP rate limiting, IP allow/blocklists, and default-deny CORS.

-> Outbound requests are SSRF-checked, size-capped, and time-limited.

-> And the bigger picture: this is self-hosted. Unlike cloud API-to-MCP converters, your API keys never sit in someone else’s multi-tenant database. Your keys, your server, your rules.

Security questions are always welcome — happy to go deeper on any of this. 🙂

Yes, the limit of 200 sites is for the number of active sites. So as long as you delete GetMCP from a site ( no need to delete the site if you don’t want to ), just make sure you deactivate the license from that site, so it will be credited back to your sites quota 🙂

Not a beginner question at all — and yes, you’ve understood it correctly.

Your app does not need to be built on WordPress. If your app is hosted on Vercel or Netlify, it stays there exactly as it is. With the current version, WordPress acts as the backend/runtime where GetMCP runs.

However, we’re releasing the standalone version of GetMCP this week, which will be a much better fit for setups like yours. You’ll be able to run GetMCP separately without needing a WordPress installation, while your existing app continues to stay on Vercel or Netlify.

And yes, GetMCP works with your app’s REST API. You choose which API endpoints you want to make available as MCP tools. When Claude uses one of those tools, GetMCP sends the corresponding request to your app’s API and returns the result back to Claude.

It is definitely not limited to WordPress plugins or WordPress APIs. Your application can be hosted elsewhere and built with any stack, as long as it has the API endpoints you want to use.

And since you mentioned vibe coding, our next update should be especially interesting for you. You’ll be able to give your API documentation to your AI assistant and have it help create and configure the MCP server in GetMCP — making the whole setup much easier.

So yes — your Vercel/Netlify app example is exactly the kind of use case GetMCP can work with.

Hi, thank you for taking the time to write all of this up — this is one of the most thorough evaluations we’ve had. Since a few of these decide your tier, I’ll answer all 32 directly, including the honest “not yet” ones.

LICENSING AND SITE SLOTS

1. Yes. Commercial use is allowed — you can install and operate GetMCP for paying clients and charge them for it. That’s exactly what the agency tiers exist for. Nothing in the license restricts who owns the sites or whether you bill for the service.

2. An activation record, keyed to your license plus the normalized site URL. Scheme, www and default ports are ignored — https://www.client.com and http://client.com are one site. Subdomains and subdirectory installs count separately.

3. The slot returns instantly — we’ve tested this specifically. Deactivating a site frees its seat the moment the request lands; nothing is consumed permanently. One practical note: deactivate from the install before you destroy a server, because the release request is signed by the install itself. If a client’s server is already gone, contact support and we’ll release the seat manually.

4. No limit. No counter, no cooldown, no cycle cap. Move the license between sites as often as you like.

5. The key itself can’t be handed over — activation works through an encrypted key that is generated when the license connects to your account on our site, so the license stays tied to the purchasing account. What you can do is hand the entire installation over to the client: they manage their servers and everything keeps running as-is. The one thing to know: if they ever deactivate the license, reactivating it requires the license owner, so they’d need to contact you for that step.

6. Every activation counts — there is no staging exemption. In practice you rarely need one: the MCP server runs in the backend and doesn’t care whether the site is “production” or “staging”, so you can build and test against your AI client on the same install you’ll hand to the client. And since releasing a seat is instant and reactivation is unlimited (see 3 and 4), moving between environments costs nothing.

7. Unlimited means unlimited activations, and it’s live and working today. It’s enforced on your license record itself, not on our current plan catalog — so if we restructure retail plans later, nothing about an issued license changes. Features work the same way: every deal tier gets the full feature set (tiers differ only in site count), and the plan mapping is deliberately written so an unrecognized plan name never downgrades an active license. Worth knowing: the unlimited tier is only available in limited quantity through this deal — it doesn’t exist at retail.

MULTI-TENANCY

8. One installation is one admin realm. You can run any number of MCP servers on a single install — each with its own authentication, credentials, logs and settings — but there is no per-client admin isolation inside one install: anyone with admin access sees all servers. The model the site quota is built around is one install per client (their domain, their database, real data isolation), and the standalone app makes that cheap: one command on any VPS, SQLite by default, nothing else to set up. That’s exactly why the unlimited-sites tier fits what you described.

9. No hard limit. Servers, tools and calls are all unlimited on every paid tier — our own stress testing ran 10+ MCP servers on a single instance without issues (more in 22).

10. Not today — honest answer. Neither build has a client-scoped role that shows only one server. If clients need to see their own logs, the answer today is their own install (see 8), which gives them exactly that plus genuine data isolation.

11. Per server and per tool, plus a global default — not per end-user or per token yet. With install-per-client, per-server limits are effectively per-client limits. Each server’s limit is configurable (N requests per minute, or unlimited), and hitting it returns a proper 429 with Retry-After at the server level, or a JSON-RPC error with retry_after at the tool level.

AUTHENTICATION

12. Both, and it’s a per-server choice. Each server picks its client authentication: none, static bearer/basic (the pasted-header mode the FAQ describes — simplest option, the upstream API validates the credential), managed API keys, or full OAuth 2.1. The FAQ documents the simplest mode; the homepage describes OAuth — both are real, and OAuth 2.1 is what powers the one-click connector flow in Claude and ChatGPT.

13. GetMCP is the authorization server the AI clients talk to — it serves the discovery documents and the authorize/token endpoints and mints its own tokens (PKCE S256 required, no plain fallback, exact redirect-URI matching, single-use codes, rotating refresh tokens). For sign-in identity there are two modes: the built-in management server uses GetMCP’s own login and consent screen, and for your API servers GetMCP brokers to YOUR identity provider — you plug in your authorize/token URLs and client credentials, users sign in with you, and GetMCP handles both sides of the dance, storing upstream tokens encrypted and injecting each user’s own token on their API calls. What it doesn’t do yet is accept tokens minted by a third-party authorization server directly.

14. Yes. RFC 7591 dynamic client registration is live on every OAuth-enabled server (/oauth/register, advertised as registration_endpoint in the metadata) — exactly what Claude and ChatGPT remote connectors expect. We also support Claude’s hosted client-metadata documents, so the whole connector experience — paste URL, sign in, consent, tools appear — works with zero manual registration. Claude is what we test against most heavily.

15. Not as a UI feature yet. There is a per-tool scope hook (a one-line PHP filter, with a proper RFC 6750 insufficient_scope step-up challenge), but no admin-screen mapping of scopes or roles to toolsets. The supported pattern today for “different roles see different tools” is separate servers with different tool sets on the same install.

WHITE LABEL AND CLIENT EXPERIENCE

16. Not yet for the admin interface — there’s no white-label setting, so a client logging into the admin sees GetMCP branding, and the OAuth consent screen carries our mark. What your clients’ end users see is already yours though: your domain, your server name in the AI client, your server logo.

17. On the WordPress build, effectively yes: analytics and logs sit behind their own capability, so a role granted only the analytics capability (any role-editor plugin does it) gets read-only Analytics and Logs — deletion and settings changes are refused server-side. It isn’t scoped per server though (see 10). The standalone app is single-admin today.

18. Yes, entirely. The endpoint is https://client-domain.com/mcp/server-name, the OAuth discovery documents are served from that same domain, and the server name the AI client displays is whatever you set. The only GetMCP references on the wire are documentation links inside the OAuth discovery JSON — never seen by end users.

SCALE AND INFRASTRUCTURE

19. Every MCP call is a short, stateless request — no long-lived connections, no worker held open — so your ceiling is your PHP worker count times upstream API latency, and in practice the upstream API is the bottleneck, not GetMCP. Our stress testing ran 10+ MCP servers on one instance with 10-15 concurrent connections sustained for over 30 minutes without degradation, and throughput scales directly with the server configuration. On the database: the standalone supports SQLite (the zero-config default), MySQL/MariaDB, and PostgreSQL. SQLite is fine for a single client’s sustained traffic; move to MySQL/MariaDB or PostgreSQL when you have heavy concurrent write load — in practice, when you turn on full response logging on a busy install or push serious sustained volume through one box.

20. At default settings, 50,000 calls a month is a non-event. A log row stores metadata plus size-capped, credential-redacted arguments — roughly 1 KB a row, so on the order of 50 MB a month — and full request/response payload logging is off by default (it’s an opt-in debugging tool). Pruning is automatic: a daily job deletes call logs older than 30 days and analytics older than 90 by default, both configurable from 0 (keep forever) to 3650 days, and deletes run in chunks so a large table never locks.

21. Timeouts are per tool: default 30 seconds, maximum 300, with configurable retries and exponential backoff. Two things to know: there’s no streaming keepalive on a slow call — the AI client just waits — and your PHP process timeout is the outer bound, so keep tool timeouts under it. Practical guidance: most AI clients get impatient past about 60 seconds, so design tools to answer fast (the response shaping in 25 helps a lot) rather than proxying multi-minute jobs.

22. We launched publicly in August 2026, so I won’t pretend to years of production history or quote customer volumes we don’t have yet. What I can share is our own stress testing: 10+ MCP servers on a single instance handling 10-15 concurrent connections sustained for over 30 minutes without degradation — and since every call is a short stateless request, capacity scales directly with the server configuration. For track record: GetMCP is built by the team behind FlowMattic, which has been running automation workloads on customer sites for over 5 years.

DATA AND GDPR

23. The architecture is most of the answer: GetMCP runs entirely on your (or your client’s) infrastructure. MCP traffic, credentials, call logs — none of it ever touches our servers, so for your clients’ data we’re not in the processing chain at all. What our servers hold about an install is the site URL and the encrypted license key generated during activation; after that, the install periodically pings our update server to check for new versions — a version check only. No usage data, no tool or server names, no emails, no content, ever. We don’t have a formal DPA template published yet — tell us what your compliance process needs and we’ll provide the details.

24. Both, and it’s configurable. Redaction runs at two points: on the response before the model sees it, and on what gets written to logs (arguments, responses, error messages). Per server you choose both, response-only, or logs-only. Seven built-in patterns (emails, SSNs, credit cards, phone numbers, IPv4 addresses, AWS keys, JWTs) plus your own regex patterns with custom labels. Matches become labelled placeholders like [REDACTED:EMAIL] so the model keeps context. It ships off by default — enable it per server.

TOOL QUALITY AND RESPONSES

25. Every tool has a response mapping: full JMESPath (the real library, not a subset) or simple JSONPath, applied before anything reaches the model. So users[?active].{id: id, email: email} turns an 80-field-per-row payload into two fields per row. There’s a live test panel in the tool editor, and analytics tracks upstream bytes versus delivered bytes per tool, so you can see exactly how much context you’re saving.

26. Yes. The import preview lists every operation in the spec with checkboxes — select all or cherry-pick — lets you choose skip-vs-duplicate for name collisions, and imported tools land as drafts by default, so nothing goes live until you activate it.

27. Edits are fully free — names, descriptions, parameters, response mapping, everything. Re-import is honest territory: importing an updated spec never overwrites existing tools (it skips them, or creates duplicates you reconcile), so your edits can’t be clobbered — but there’s no update-in-place re-sync yet either. One caveat worth knowing up front: the tool name is what MCP clients call, so renaming a tool is a breaking change for already-connected clients — there’s no alias mechanism yet.

28. Partially. Tools have a draft, active, inactive lifecycle, and drafts and inactive tools are invisible to clients — so the working pattern is: create the new version as a separate tool, run both side by side, deactivate the old one when your clients have moved. Formal version history and a deprecation flag surfaced to clients don’t exist yet.

COMPANY AND CONTINUITY

29. The track record so far: 1.0 in mid-May, then 1.1.0 in June, 1.2.0 in July, 1.3.0 and 1.4.0 in August (the standalone app and the built-in MCP server) within the following weeks. On protocol: we support five MCP revisions today, from 2024-11-05 through 2026-07-28 (the current one) — implemented properly (stateless mode, batching removal, the new cache metadata), not just version-stamped. The MCP spec is this product’s foundation, so tracking it fast isn’t optional for us; every revision so far has shipped within weeks of publication.

30. Two things make the math work. First, both the app and the WordPress plugin are fully self-hosted — you run them on your infrastructure, so lifetime licenses add no recurring server cost on our side; support cost scales with documentation quality, which is why the knowledge base and install tooling get so much of our attention. Second, the free tier is deliberately minimal — it exists so anyone can test how it works — and the paid retail plans are the ongoing engine. And for the track record: we’ve been running FlowMattic on this same self-hosted model for over 5 years without issues.

31. Installations keep working — and that’s verified behavior in the code, not a promise. The product runs entirely on your servers, and the license check is deliberately lenient: if our licensing server were unreachable forever, an activated install keeps its full feature set indefinitely on its last-known plan — and lifetime licenses stop periodic license checks entirely after activation. Nothing phones home to stay alive. What you’d lose is updates.

32. Yes — a partner and referral program is planned. Once this deal wraps up, that’s the next focus on our official site: referrals and partner listings. If you go ahead and build on GetMCP, you’ll be exactly the kind of early agency partner we want to shape it with.

Absolutely — GetMCP is not limited to WordPress. GetMCP has a standalone app as well, so you can use it without WordPress.

If Webflow or your LMS provides a REST API for the functionality you want to access, you can use GetMCP to turn those API endpoints into MCP tools.

For example, Webflow provides REST APIs for CMS content, sites, forms, ecommerce and more. The same applies to off-the-shelf LMS platforms — if the functionality is available through their REST API and you have the required API access, you can bring it into your MCP server.

And with GetMCP 1.4.0, the setup is even easier: you can connect the GetMCP MCP Server to Claude, give Claude your API documentation, and ask it to help create and configure the MCP server for you.

So yes — Webflow, LMS platforms, SaaS apps, or your own applications can work with GetMCP as long as the functionality you need is available through a REST API.