Remote Phylax MCP

The hosted server needs nothing installed. The client connects over HTTPS, which means one configuration works for a whole team and for clients that cannot spawn a local process.

Local or remote

	Local	Remote
Install	Phylax CLI on every machine	Nothing
Transport	stdio, no port	HTTPS
Token	Per developer, stays on the machine	Issued per user or per team
Works offline	Yes, for cached verdicts	No
Best for	One machine, no network hop	A team sharing one configuration

Connect

Claude Desktop

claude_desktop_config.json

{
  "mcpServers": {
    "phylax": {
      "url": "https://mcp.phyi.dev",
      "headers": {
        "Authorization": "Bearer ${PHYLAX_API_TOKEN}"
      }
    }
  }
}

Cursor

~/.cursor/mcp.json

{
  "mcpServers": {
    "phylax": {
      "url": "https://mcp.phyi.dev",
      "headers": {
        "Authorization": "Bearer ${PHYLAX_API_TOKEN}"
      }
    }
  }
}

VS Code

.vscode/mcp.json

{
  "servers": {
    "phylax": {
      "type": "http",
      "url": "https://mcp.phyi.dev",
      "headers": {
        "Authorization": "Bearer ${env:PHYLAX_API_TOKEN}"
      }
    }
  }
}

Issue the token from API tokens. Read endpoints are public, so the token only matters once you want your organization’s policies applied to the verdicts.

How the token is scoped

The token is bound to this server

Your Phylax token carries an audience claim naming the Phylax MCP server, and the server rejects anything issued for a different service even when it is correctly signed and unexpired. It is also never forwarded to a downstream API. Both behaviours are requirements of the MCP authorization specification, not choices: a server that accepts foreign tokens or passes them through is the confused deputy problem in the making.

The practical consequence for you: a Phylax token is useless to any other MCP server, and a token for some other service is useless here. That is intentional, and it is why you cannot reuse one token across every tool in your setup.

Team and organization scope

A token issued at organization level applies your shared policy to every verdict it returns, so two developers asking the same question get the same answer. A personal token returns the default public verdict. If a verdict differs between two people, the token scope is the first thing to check.

Rotate on the usual triggers

Tokens are read-only and cannot publish attestations or change policy, so a leak is recoverable by rotation alone. Rotate when someone leaves, when a token appears in a log or a screenshot, and on whatever schedule you already use elsewhere.

Before you connect any remote MCP server

This applies to every remote server you add, not just this one. A client that follows URLs supplied by a server can be steered somewhere it should not go.

• Require HTTPS. Accept http:// only on loopback during development.
• Block private and link-local address ranges when following any URL a server hands you: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, fc00::/7 and fe80::/10. The link-local range is the one that protects cloud instance credentials.
• Reject non-HTTP schemes in authorization URLs. javascript:, data: and file: have no legitimate use here.

Reputable clients do this for you. It is worth knowing because it is the difference between a malicious server being an annoyance and it being an credential exfiltration path.

Related guides

Local Phylax MCP for the stdio setup, or MCP Servers for what Phylax checks and why.