"My Zephex MCP just saved me from a bad Stripe upgrade. Two prompts in Claude Code. check_package → Stripe is clean, no red flags."— r/ClaudeAI
Your AI editor keeps forgetting your project. Zephex fixes that.
One hosted MCP endpoint gives Cursor, Claude Code, VS Code, and Windsurf instant project context — your stack, your packages, your architecture — every session. Paste one config. Free to start.
How it works
Stop re-explaining your codebase.
Connect once.
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. Same endpoint, same tools, everywhere.
- Rotate or revoke keys from the dashboard — not buried in config files.
- 10 tools activate instantly across every connected editor.
Connect once
Paste one config and move on
Pick your client, copy the snippet, add your key, and point it at the Zephex endpoint.
- 1Copy the JSON snippet aboveYour API key is already filled in.
- 2Create .cursor/mcp.json in your project rootIn your project folder, create a .cursor folder, then create mcp.json inside it.
- 3Paste the JSON and saveMake sure the file contains valid JSON — no extra text before or after the braces.
- 4Fully restart CursorMac: Cmd+Q then reopen. Windows: Ctrl+Q then reopen. A window reload is not enough.
- 5Confirm in Settings → Tools & MCPsYou should see "zephex" listed. If you see a JSON error, open the file and check for typos.
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.
Summarizes the repo’s stack and key integration points (auth, hosting, billing, queues) based on what’s actually present in code and config.
- You just opened a new repo
- You need the stack + key entry points
- You want a safe overview before changing code
Built for real workflows
Who uses Zephex
Teams that need MCP to feel operational: one endpoint, one control layer, less config drift.
Profile 01
Solo developers
One setup that survives repo switches, editor changes, and client work.
You bounce between side projects, contract repos, and multiple editors. Native MCP means duplicated config, duplicated tools, and drift every time something changes.
Keep one endpoint and one tool surface. Use separate keys for local and client work without rebuilding the whole MCP setup each time.
Profile 02
Startups and product teams
A shared control layer for local, staging, and production work.
Different people use different editors, environments, and tool sets. Access rules end up buried in config files and break quietly when the stack shifts.
Point everyone at the same hosted endpoint, issue keys per person or environment, and keep tool availability consistent while the product changes underneath.
Profile 03
Platform and ops teams
Operate MCP like infrastructure instead of tribal knowledge.
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.
Centralize auth, usage visibility, and key lifecycle control at the proxy layer so policy changes happen once instead of repo by repo.
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.
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
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
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
Zephex vs. local MCP and documentation tools
Scans your codebase, not a cached library
This is why Zephex users catch breaking changes Context7 misses — it reads your repo, not a cached library.See the tools →
Plans
Simple pricing, clear limits.
Start free. Upgrade when you need more requests, more backends, or custom key scopes.
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.
Generate it once and keep separate keys for local, staging, and production.
Use the key in the Authorization header from an editor client or direct request.
Call `tools/list` first so the client sees exactly which tools this key can access.
After discovery, send `tools/call` through the same endpoint and let Zephex enforce the boundary.
https://zephex.dev/mcpBearer mcp_sk_xxxcurl -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":{}}'{
"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.
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 beforeyou connect
Quick answers for evaluation, setup, and security review.
Most users connect in a few minutes — create a key, paste one config snippet into your editor, and call the MCP endpoint. No long onboarding, no infrastructure to provision.
No. Zephex does not use your prompts, tool inputs, tool outputs, or code to train AI models. Your data is routed and enforced at the boundary — nothing is retained for model training.
Treat every key like a secret: keep them out of public repos, rotate any exposed key immediately, and use isolated keys per environment. Zephex makes this easier with scoped key policies from your dashboard.
Zephex surfaces the failure in your operational dashboard in real time. The boundary enforcer catches tool-call errors before they propagate and logs them with full trace context so you can diagnose without reproducing.
Yes. The single-endpoint model means you control exactly what crosses the boundary. Scoped keys and policy rules let you permit or block specific tools, namespaces, and output shapes — without modifying your client configuration.