Percher is now a one-click connector, no install required

Until now, connecting Percher to an AI assistant meant one thing: install the MCP package locally with npx -y @percher/mcp, point your client's config at it, and you were off. That works well, and for Claude Code with a project open it is still the right answer. But it is an install. It assumes a terminal and a config file on a machine that can run the package.

Other hosts moved to a second option in parallel. They started shipping hosted MCP endpoints you add by pasting a URL: you approve a login in the browser and the platform's tools show up in the chat with nothing installed. Percher only spoke the local dialect, which meant that next to those one-click connectors we read as "npx-only."

Not anymore. Percher now runs a hosted MCP endpoint at `https://mcp.percher.app/mcp`. You add it as a custom connector in Claude.ai, Cursor, or Windsurf, approve a Percher login in your browser, and your assistant can operate your apps. There is nothing to install.

What happens when you add a connector

Here is the part that surprises people: there is no token to paste. This is not an API key you drop into a settings field. It is OAuth.

When you add the URL, your client runs the whole handshake on its own. It discovers the endpoint, registers itself, opens a Percher consent page in your browser, and once you click Allow it receives a short-lived access token plus a refresh token that it manages for you. You never see a credential. You approve a login, the same way you approve "Sign in with Google" somewhere, and that is the entire ceremony.

That design is deliberate, and it is the difference between a connector you can trust and one you cannot. A pasted bearer token is a long-lived secret sitting in a config file and flowing through a proxy. An OAuth grant is short-lived and revocable. Open the Percher dashboard and cut off the connected client. The next request it makes fails. No waiting for a token to expire, no secret to rotate.

What it can do, and what it deliberately cannot

The hosted connector is not the full local tool set, and that is on purpose. The local package can read your project directory; the hosted server cannot read your disk at all. So the hosted surface is a defined remote-safe subset: the tools that operate against the platform rather than your filesystem.

With it your assistant can list and operate your apps, set environment variables, manage domains, read logs, inspect deploys, diff versions, create a public inspect link, share an app or transfer it, and deploy a connected repo. That last one is the "publish my app" move, done the way a remote server can: Percher already clones connected repos server-side through the GitHub App, so a hosted deploy ships the latest commit of a repo you have connected, and percher_redeploy re-runs the current version.

What it cannot do is the first publish of a brand-new project from local files. The remote server has no working directory and no access to your machine, so there is nowhere to read those files from. That is not a limitation we are apologizing for; it is the same boundary every remote MCP endpoint draws. For that first push from local source, use npx -y @percher/mcp or bunx percher publish. Both are unchanged.

So the two paths split cleanly. The local npx package, recommended for Claude Code, carries everything including first-publish-from-local-files. The hosted connector is the zero-install, OAuth way to operate apps and deploy connected repos from any client that supports custom connectors. They are additive. Run bunx percher mcp and the CLI prints both.

The security model, in plain language

A hosted, internet-facing endpoint that can deploy your apps deserves a clear account of how it is kept safe. Three things matter.

The proxy holds no standing secret. The container that serves mcp.percher.app/mcp has no platform credential of its own: no internal API key, no privileged access. It forwards your OAuth token to the Percher API, which honors it only within the scope you approved, and there is no master key behind the connector to steal. The honest caveat is that your token does pass through that container, so a full compromise of it could abuse whatever grants are in flight at that moment, for as long as they stay valid. That is the blast radius the next two properties exist to bound, not a risk I am going to pretend away.

Your grant is scoped and live-revocable. The token is validated on every single request against the live grant. Revoke the connection in the dashboard and the very next tool call fails. There is no cached-token window where a revoked connector keeps working. And the token's reach is bounded by a deny-by-default capability list: it can run the remote-safe operations and nothing else. A brand-new API route is unreachable to it until someone deliberately classifies it as safe.

Consent does not trust what the client claims to be. This is the subtle one. Connecting is open: any client can register itself, which is what makes one-click discovery work at all. But open registration means a client supplies its own name and its own callback address. Someone could register a client that calls itself "Claude" and points the approval at their own server. So the Percher consent screen does not render a self-declared name as if it were verified. Instead it shows you the exact redirect origin the approval will be sent to, the one security-relevant fact, alongside an explicit "unverified client" label. Trusted branding is reserved for clients we have statically verified, not for anything that types "Claude" into a registration form. Check the origin before you click Allow. That one habit is what keeps open, one-click connecting from becoming a phishing vector.

Try it

Open Claude.ai, go to Settings, Connectors, Add custom connector, and paste https://mcp.percher.app/mcp. Approve the Percher login. Then ask your assistant to list your apps, or to redeploy one. Cursor and Windsurf add it the same way.

One honest expectation to set: custom connectors and their OAuth handshake are new across clients, and the flow is occasionally finicky. This hosted endpoint is newer and less proven than the local npx package it sits beside. If the one-click add does not go cleanly in your client, that local package is the dependable fallback and costs you nothing but the convenience.

And if you are in Claude Code with a project open in front of you, use npx -y @percher/mcp anyway. It can read those files and ship them for the first time, which is exactly the thing a hosted endpoint never will.