GetMCP 1.8.0 — Project Gateways, Remote MCP Servers, and the People You Choose

Most teams don’t want one MCP endpoint per API. They want one endpoint per client, per project, per team, and they want the servers other people already run to sit behind the same sign-in as their own. 1.8.0 is about that: project gateways group your servers, remote MCP servers put any MCP server behind your authentication, and a pasted Claude Desktop or Cursor config becomes servers in one step. On WordPress 6.9 the new Abilities become tools, and you can now say exactly which WordPress accounts may connect. The standalone app gets its own Users. And a release-day security audit landed a round of hardening that every install gets with the update.

Project gateways: one endpoint for a set of servers

The MCP Gateway from 1.6.0 publishes every server on your install at /mcp. A project gateway publishes only the servers you pick, up to 50 of them, at /mcp/your-gateway with its own sign-in. Make one per client and their AI gets exactly that client’s systems, nothing else. Make one per team and the team configures a single address instead of six.

Tool names inside a gateway carry the server they came from, northwind-orders__list_orders, so two servers can both have a search tool and the model always knows which system it is talking to. Open Gateway → Project gateways to create one; the list has a switch and a delete action for each. A gateway never passes a caller’s credential on to a member server, so a member that forwards the client’s key to its API is flagged as Not ready until it has a stored credential of its own, and saving a gateway whose sign-in is weaker than a member’s own warns you which members it would expose. Calls that go through a gateway show via and the gateway’s name in Logs.

Remote MCP servers: any MCP server behind your sign-in

Some tools you want are already an MCP server: a vendor’s hosted endpoint, a server a colleague runs, a service that only ships as MCP. Click Connect Remote MCP on the Servers page, paste its address, and GetMCP proxies it. Your people sign in to GetMCP the way they do for any server, and GetMCP calls the remote server for them with the credential you stored once, encrypted. Your rate limits, PII redaction, allowed IPs and call log apply to its tools as to your own.

Every upstream tool has a switch, and tools the remote server adds later stay off until you turn them on, so a vendor cannot put a new tool in front of your clients without you noticing. The upstream connection uses no auth, a fixed header or Basic; on WordPress it can also be per-user OAuth, where each person connects their own account under Users → My MCP connections. Addresses are checked before every connection and the connection is pinned to the addresses that passed, so DNS cannot switch it to a private network. Remote servers are never part of a gateway; clients connect to them directly.

Import a client config

If your servers already live in a Claude Desktop, Cursor or VS Code JSON file, a Codex TOML file or YAML, paste it under Import → Client config. A claude mcp add command or a plain URL works too. GetMCP previews the servers it found, says which ones it can proxy (the https:// ones; a server started with npx runs on a desktop, not a web server), and creates the ones you tick as remote servers. They start closed, with WordPress sign-in and an empty allowed-users list on WordPress or API-key authentication with no key on the standalone app, so an import never opens a door by itself.

The same dialog converts a config between the Claude, VS Code and Codex formats, with every secret replaced by a placeholder, which makes it safe to paste into a chat or a support ticket.

Client API keys, where you’d look for them

Keys for a server with API-key authentication now live on its Authentication tab. Type who the key is for, pick an expiry, and the key is shown once. Each key shows when it was last used, and Revoke retires one client without touching the others. No WP-CLI or Artisan needed, though both still work for scripted setups.

A status line above the keys says what the server does right now: Protected, accepting only the keys below; forwards any key to your API, which does the checking; or refuses everyone until you create a key. That last state is new and deliberate. A server with mailbox, database or file-server tools, and the Gateway in API-key mode, used to accept any key until one was created, because nothing upstream was checking it. Both now refuse every request until you create a key. The section above it is now called Upstream API credential, and says plainly that it does not decide who may connect.

WordPress Abilities as MCP tools

WordPress 6.9 introduced Abilities, actions that core and plugins register in one place with a name, a description and an input schema. On 6.9 and later, Import Tools → From WordPress Abilities lists every ability on your site and turns the ones you tick into tools, with the server’s authentication, logging and rate limits in front of them. Abilities marked read-only add straight away; the others ask for a confirmation, because an AI client calling them changes your site.

An ability runs as the signed-in user, so with WordPress sign-in it sees exactly what that person may see, or as the server’s Run abilities as user for servers reached with a key. Administrators are refused as the run-as user unless the getmcp_ability_allow_admin_run_as filter allows it. Abilities registered since your last visit are marked new, and a test run shows which user it ran as.

WordPress sign-in with an allowed-users list

Choose WordPress sign-in as a server’s client authentication and pick the people who may connect. When one of them connects an AI client, it opens your site’s sign-in; they approve, and the client gets a token for that server only. An empty list lets nobody in, administrators included. The list is checked on every request and at every OAuth step, removing someone deletes their tokens at once, and the Gateway honours it. It is the natural choice for a server whose tools act on the site itself.

Standalone app: Users and My account

The standalone app now has accounts of its own. Under Users, an admin adds people by an emailed link that works for seven days, or by setting a password and sharing it. Admins see everything; members see My account and, when an admin allows it, Chats, and they can sign in to servers an admin published. Everyone can change their own name, email and password, and the sign-in page has Forgot password?. A password change signs the account’s other browsers out on their next request. The last admin can never be removed or demoted. Emails carry your brand name with White Label, and INSTALL.md has the SMTP settings the links need; a fresh install writes them to the log until you add a mail server.

Server logos and brand images on the standalone app come from the app’s own media library now: upload once, reuse on any server.

Activation codes for sites getmcp.com cannot reach

A site on your laptop, behind a VPN or on a .local address cannot receive the activation callback from getmcp.com. On the License page, open Have an activation code?, follow the link to generate a code in your getmcp.com account, and paste it. You can also set it as GETMCP_LICENSE_ACTIVATION_CODE in wp-config.php or .env. A refused code says why, right under the box.

The security audit, and what it changes for you

Before publishing 1.8.0 we audited both builds against their own code. Everything found is fixed in this release, and a few of the fixes change behaviour you may notice:

• A server cannot both forward a caller’s credential and store one. With Bearer or Basic client authentication, GetMCP passes the client’s credential on to your API; such a server may no longer also hold a stored upstream credential, and create, update and import refuse the pairing. A GetMCP-managed API key or OAuth token is never forwarded upstream.
• Gateways no longer pass a caller’s credential to member servers. A member that forwards the client’s key returns an error through a gateway: call it on its own endpoint, or give it a stored credential.
• A header-sourced connection variable may not sit in a tool URL’s host on a server with a stored credential, because a caller could name their own server in the header and receive your key. A host chosen through a header may never be a private address, whatever Settings → Security allows for the hosts you configured.
• Mailbox folder names and search text containing a line break are refused. Inside an IMAP command they ran as further commands under the mailbox login, so a read-only tool set could have deleted mail.
• Read-only database queries are checked for INTO OUTFILE with comments and quoted values removed first.
• OAuth. An authorization code can be exchanged only with the exact redirect URI it was issued to; a grant works only on the server that issued it; a per-user OAuth sign-in is bound to the browser that started it; the consent page refuses to render inside a frame. A sign-in in progress while you update has to start again.
• Resources, prompts and completions are no longer served to a caller whose credential only the upstream API checks. Lists answer empty; reads need a key you created, or OAuth sign-in.
• Network. Tool requests, remote MCP connections and URL imports pin the address that passed the private-network check into the connection; the guard sees through NAT64 and 6to4 and never goes through a proxy; call-log signatures cover the tool name and the gateway.
• Standalone app. Every link the app builds, including password-reset emails, comes from APP_URL, not from the request’s Host header; X-Forwarded-* headers are believed only from this machine, private networks and Cloudflare’s ranges (set TRUSTED_PROXIES for another proxy); the connection key cannot manage accounts; the installer stays closed when the database is unreachable; .env.example ships with debug off.

Also in 1.8.0

• Call logs keep the name of the tool that ran, so calls to a remote server’s tools, or to a tool deleted since, still show it in Logs, Analytics and the dashboard; remote calls carry a Remote badge and the CSV export has a Via column.
• Updating a server’s settings through the REST API merges the keys you send over the stored ones, one level deep; a key sent as null is removed.
• Desktop apps that sign in with their own app link, such as the Claude desktop app and Cursor, can connect to the Gateway and the built-in GetMCP server again.
• PII redaction was off on a server whose redaction scope had never been saved; it now uses the default scope. Importing a server can no longer create tools past your plan’s limit.
• Licence activation from a *.localhost address verifies through your browser like other local addresses.
• Mailchimp template: the tools call your account’s own data centre, which you set once when installing.
• Branding: choosing a new logo no longer deletes the saved one before you click Save. Dialogs cover the whole screen on every page.
• Standalone app: the download no longer includes package.json, so Netlify, Vercel and Render stop trying to build it; the installer’s logo no longer shows as a broken image.

Getting 1.8.0

If you’re on the WordPress plugin, the update is waiting in your dashboard. On the standalone app, System Status will offer it, or update from the command line:

curl -fsSL https://get.getmcp.com | bash -s -- --update --dir=/path/to/getmcp

Both builds are the same codebase. Project gateways and remote servers need a Pro plan; everything else is in every plan. To get started, read Project gateways, Connect a remote MCP server, Import a client config, Client API keys, WordPress Abilities as MCP tools, WordPress sign-in with an allowed-users list and, on the standalone app, Users and My account. The full list of changes is on the changelog, and if you hit anything odd, support is the fastest way to reach us.