One MCP endpoint for every client, backend, and API key

Zephex gives you one secure `/mcp` surface for Cursor, Claude Code, VS Code, JetBrains, and Windsurf, with routing, usage controls, billing, and key management built in.

Start with one endpoint

How it works

One endpoint.
Every client.

Instead of wiring each editor separately, you point everything at zephex.dev/mcp once and Zephex handles validation, routing, and limits from there.

One config per editor. One key. One endpoint.
Revoke or rotate keys from the dashboard, not config files.
10 tools available across all connected clients instantly.

Connect once

Paste one config and move on

Pick your client, copy the snippet, add your key, and point it at the Zephex endpoint. This is the part users should see early because it turns the product into something concrete immediately.

.cursor/mcp.json

{
  "mcpServers": {
    "zephex": {
      "url": "https://zephex.dev/mcp",
      "headers": {
        "Authorization": "Bearer {{API_KEY}}"
      }
    }
  }
}

Setup steps

1
Copy the JSON snippet above
Your API key is already filled in.
2
Create .cursor/mcp.json in your project root
In your project folder, create a .cursor folder, then create mcp.json inside it.
3
Paste the JSON and save
Make sure the file contains valid JSON — no extra text before or after the braces.
4
Fully restart Cursor
Mac: Cmd+Q then reopen. Windows: Ctrl+Q then reopen. A window reload is not enough.
5
Confirm in Settings → Tools & MCPs
You should see "zephex" listed. If you see a JSON error, open the file and check for typos.

No packages or commands required. Just paste the config file and restart your editor. The connection uses native Streamable HTTP — no npx, no bridge packages.

MCP toolbox

A toolbox for faster, safer changes

Use these MCP tools to understand a repo, find the right code, and pull current docs — with clear guidance on when to use each tool.

get_project_context

Get a verified snapshot of the repo.

Summarizes the repo’s stack and key integration points (auth, hosting, billing, queues) based on what’s actually present in code and config.

When to use

You just opened a new repo
You need the stack + key entry points
You want a safe overview before changing code

View all tools API docs

Built for real workflows

Who uses Zephex

Teams that need MCP to feel operational: one endpoint, one control layer, less config drift.

One endpointOne control layerLess config drift

Profile 01

Solo developers

One setup that survives repo switches, editor changes, and client work.

Where it breaks

You bounce between side projects, contract repos, and multiple editors. Native MCP means duplicated config, duplicated tools, and drift every time something changes.

What changes with Zephex

Keep one endpoint and one tool surface. Use separate keys for local and client work without rebuilding the whole MCP setup each time.

Repo hoppingMulti-editor setupSeparate local and client keys

Profile 02

Startups and product teams

A shared control layer for local, staging, and production work.

Where it breaks

Different people use different editors, environments, and tool sets. Access rules end up buried in config files and break quietly when the stack shifts.

What changes with Zephex

Point everyone at the same hosted endpoint, issue keys per person or environment, and keep tool availability consistent while the product changes underneath.

Team-wide rolloutStaging and productionFewer secret handoffs

Profile 03

Platform and ops teams

Operate MCP like infrastructure instead of tribal knowledge.

Where it breaks

Rate limits, key rotation, and usage tracking get patched into each client separately, which makes audits, ownership, and incident response harder than they should be.

What changes with Zephex

Centralize auth, usage visibility, and key lifecycle control at the proxy layer so policy changes happen once instead of repo by repo.

Key lifecycle controlRuntime limitsAudit visibility

Operational trust

Security and data boundaries users can verify

Show the controls, the runtime protections, and the policy surface people check before they trust a proxy.

Hash-only key storageProxy-level enforcementExplicit data-use policy

Key storage

API keys are hashed, rotated, and managed from the dashboard

Raw keys are shown once at creation. Server-side verification uses hashing, and exposed keys can be rotated or revoked without changing the endpoint users hit.

Raw key shown only at creation
Dashboard-based revoke and rotate flows
No plaintext key storage in the database

Review security

Runtime controls

Limits and abuse controls live at the proxy boundary

Per-key enforcement, usage tracking, and request ceilings happen where traffic enters instead of being bolted onto each client separately.

Per-key rate limiting and request ceilings
Usage visibility for billing and ops
Shared enforcement across clients and environments

Review rate limits

Data boundary

Data-use policy is explicit about what is and is not processed

Security, privacy, and data-use docs explain what is needed to operate the service and state that prompts, tool inputs, outputs, and code are not used to train models.

Dedicated Security page
Dedicated Data Use page
No model training on customer content

Review data use

Plans

Pricing that feels like the billing dashboard

Start free, upgrade when usage becomes real, and keep the plan math obvious.

FREE

$0/mo

Best for evaluating one endpoint against a few backends.

Requests300 / mo

MCP Backends3

API Keys3

Key scopesFull access

SupportCommunity

Start free View full pricing

PRO

$7/mo

Best for day-to-day dev workflows that need cleaner control.

Requests3,000 / mo

MCP Backends10

API KeysUnlimited

Key scopesCustom scopes

SupportEmail

Choose Pro View full pricing

MAX

$19/mo

Best for teams that need higher ceilings and priority support.

Requests10,000 / mo

MCP Backends20

API KeysUnlimited

Key scopesCustom scopes

SupportPriority

Choose Max View full pricing

API access

Create a key, send one header, call tools.

Generate the key in the dashboard, use it as a Bearer token, confirm tools/list, and route actual MCP traffic through the same endpoint.

Step 01

Create the key in the dashboard

Generate it once and keep separate keys for local, staging, and production.

Step 02

Send it as Bearer auth

Use the key in the Authorization header from an editor client or direct request.

Step 03

Confirm the tool catalog

Call `tools/list` first so the client sees exactly which tools this key can access.

Step 04

Route real MCP traffic

After discovery, send `tools/call` through the same endpoint and let Zephex enforce the boundary.

Read API docs Create API key

First request

Endpoint

https://zephex.dev/mcp

Authorization

Bearer mcp_sk_xxx

curl -X POST https://zephex.dev/mcp \
  -H "Authorization: Bearer mcp_sk_xxx" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Expected response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "read_code" },
      { "name": "find_code" },
      { "name": "inspect_url" }
    ]
  }
}

tools/list tells the client which tools this key can access before any real tool call runs.

Key handling rules

Separate environments

Use different keys for local, staging, and production so rotation stays precise.

Rotate on exposure

If a key lands in logs, a repo, or a screenshot, revoke it and mint a new one immediately.

Keep keys out of git

Store them in secret managers, not config committed to repositories or shared snippets.

FAQ

Questions before you connect

Quick answers for evaluation, setup, and security review.

How long does setup take?

Most users can connect in a few minutes: create a key, paste one config snippet, and call the MCP endpoint.

Which clients are supported?

Zephex provides setup guidance for Cursor, Claude Code, VS Code, Windsurf, JetBrains, and other MCP-compatible clients.

Do you train AI models on my tool content?

No. Zephex states that prompts, tool inputs, tool outputs, and code are not used to train AI models.

How should I handle API keys safely?

Treat keys like secrets: keep them out of public repos, rotate exposed keys immediately, and use separate keys per environment.

One endpoint.
Every client.

Instead of wiring each editor separately, you point everything at zephex.dev/mcp once and Zephex handles validation, routing, and limits from there.

One config per editor. One key. One endpoint.

Revoke or rotate keys from the dashboard, not config files.

10 tools available across all connected clients instantly.

Create a key, send one header, call tools.

Generate the key in the dashboard, use it as a Bearer token, confirm tools/list, and route actual MCP traffic through the same endpoint.

Step 01

Create the key in the dashboard

Generate it once and keep separate keys for local, staging, and production.

Step 02

Send it as Bearer auth

Use the key in the Authorization header from an editor client or direct request.

Step 03

Confirm the tool catalog

Call `tools/list` first so the client sees exactly which tools this key can access.

Step 04

Route real MCP traffic

After discovery, send `tools/call` through the same endpoint and let Zephex enforce the boundary.

One MCP endpoint for every client, backend, and API key

One endpoint.Every client.

Paste one config and move on

A toolbox for faster, safer changes

Who uses Zephex

Solo developers

Startups and product teams

Platform and ops teams

Security and data boundaries users can verify

API keys are hashed, rotated, and managed from the dashboard

Limits and abuse controls live at the proxy boundary

Data-use policy is explicit about what is and is not processed

Pricing that feels like the billing dashboard

Create a key, send one header, call tools.

Separate environments

Rotate on exposure

Keep keys out of git

Questions before you connect

How long does setup take?

Which clients are supported?

Do you train AI models on my tool content?

How should I handle API keys safely?

One MCP endpoint for every client, backend, and API key

One endpoint.Every client.

Paste one config and move on

A toolbox for faster, safer changes

Who uses Zephex

Solo developers

Startups and product teams

Platform and ops teams

Security and data boundaries users can verify

API keys are hashed, rotated, and managed from the dashboard

Limits and abuse controls live at the proxy boundary

Data-use policy is explicit about what is and is not processed

Pricing that feels like the billing dashboard

Create a key, send one header, call tools.

Separate environments

Rotate on exposure

Keep keys out of git

Questions before you connect

How long does setup take?

Which clients are supported?

Do you train AI models on my tool content?

How should I handle API keys safely?

One endpoint.
Every client.

One endpoint.
Every client.