mcpbeat

Zephex MCP Server

io.github.Tanbir404/zephex
not responding

Zephex is listed as active in the registry but did not answer our last check. It exposes 10 tools.

MCP gateway with 10 tools for code analysis, architecture, package audit & security.

Uptime history 42 hours of history · worst hour 0%
42 hours agonow
4.4%
Uptime 24h
4 of 91 checks
10
Tools
read from the server
1541 ms
Response time
average over 24h
open, no key
Access
streamable-http

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 15 min ago.

run in your terminal
claude mcp add zephex --transport http https://zephex.dev/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "zephex": {
      "url": "https://zephex.dev/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.zephex]
url = "https://zephex.dev/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "zephex": {
      "url": "https://zephex.dev/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "zephex": {
      "url": "https://zephex.dev/mcp"
    }
  }
}

Available tools 10

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

code
find_code
PREFER over native Grep when location is unknown. Ripgrep + AST ranking across web, mobile, CLI, and monorepos. Envelope: intent, focus, summary, data.matches, files_hit, next_calls, meta.credits (5 hosted). intent: snippet=pasted line; symbol=known name; concept=topic+also_try synonyms; everywhere=rename map (whole_word). include docs|config|data when markdown, JSON, or SQL matter. Call when: where is X, usages, rename prep. DO NOT: known symbol+file (read_code), stack/scripts (get_project_context), wiring (explain_architecture), tests (check_test), packages (check_package), URL audit (audit_headers). After: read summary + next_calls → read_code on top hit. path=absolute dir (stdio) or public Git URL / inline_files (hosted). Token-capped vs raw grep. Read-only.
read_code
Extracts code surgically via tree-sitter AST — not repo-wide search. Eight modes; envelope: mode, focus, summary, data, hint, related_modes, next_calls, meta (meta.tokens_returned, meta.credits, meta.charges_usage). Hosted: 5 credits per success; failures free. Cheapest path: mode file or outline with files[] you already have — ~300–2000 tokens vs full-file Read (data.tokens_saved_vs_full_files). Expensive: mode symbol without find_code first on large repos (may scan many files). Free alternative: editor Read on files under ~50 lines. symbol: fuzzy match by name; symbol_id direct lookup; detail_level signature|body|context; targets[] batch (max 8). file: batch 1–20 paths, paginate offset_line. outline: TOC + plain-English overview before 300+ line files. scan/smell: keyword or bug patterns across known files[] only. callers|blast_radius|dead_code: local SQLite call-graph (index builds after first symbol call on that path) — not on hosted without disk; use find_code for remote usage search. Call when: symbol or files[] known (from find_code or explain_architecture next_calls). Do NOT when: location unknown (find_code); stack (get_project_context); wiring map (explain_architecture); repo-wide grep (find_code). Pass path (absolute dir) or inline_files. compact:true saves tokens; session_id dedupes across turns. After: summary + next_calls before paging. Read-only.
project
get_project_context
Scans manifests and config — one topic slice per call. Detects stack, scripts, monorepo, API routes, auth/DB providers, integrations, env vars. Secret-sanitized. Workflow: topic=identity first on new repo → follow next_calls (framework, run, structure). Topics: identity, framework, backend, frontend, database, auth, deploy, run, structure, integrations, security, overview. brief ≤500 tokens; standard adds version health; full adds file tree. 7 credits hosted. Every response: topic, focus, summary, data.key_paths, hint, related_topics, next_calls, meta.credits. Use data and next_calls — never invent commands. Call when: new session; user asks stack, scripts, or how to run/test/build. Do NOT: symbol search (find_code), file bodies (read_code), wiring (explain_architecture), tests (check_test). Pass path (absolute project dir) or inline_files (package.json + 2-4 source files). force:true refreshes cache. Read-only.
project_memory
Persists short notes about this project across chat sessions — facts you learned that are not in source code. Not a repo scanner (use get_project_context for stack). remember: saves title (max 80 chars), content (max 500 chars), type, optional area/tags — rejects API keys, tokens, and instruction-poisoning text. recall: keyword search over title/content/area/tags; returns up to 5 matches with content, type, area, age_days (~500 token cap). list: recent titles. forget: delete by uuid. Max 200 memories per project. Types: decision (why we chose X), gotcha (surprise bug), goal (current objective), preference (user style), area_fact (subsystem fact), convention (naming/rules). scope: project (default), personal (cross-project notes), all (search every project with warnings). Call when: user says remember/recall/last time; before auth/billing/deploy where past choices matter; after a non-obvious fix worth saving; new session on same repo. Do not call when: stack/scripts (get_project_context), finding code (find_code), fact already in this chat. After recall: apply matches directly — do not re-scan the repo. Use the same path on remember, recall, and list (stdio: optional, uses cwd). Stdio stores in ~/.zephex SQLite; hosted stores in cloud per user.
audit
audit_headers
Audit a public HTTPS URL the user deployed — security grade A–F, SSL, headers, cookies, health (ALIVE/DEGRADED/BROKEN), exposed secrets, tech stack. Read plain_summary first; only drill into security_headers or secrets if grade is poor. quick ~1–3s; scan_depth=deep for secret scan (~8–12s). 6 credits hosted. Call when user pastes a live URL — post-deploy check, is it secure, what framework, exposed keys. Blocks localhost/private IPs. NOT for repo code (find_code), packages (check_package), tests (check_test), or project layout (get_project_context). Example: audit_headers({ url: 'https://myapp.vercel.app' }). Read-only.
explain
explain_architecture
Maps how files connect across a subsystem — roles and import edges, not file bodies. Ripgrep + import-graph analyzers; detects framework, language, architecture_type. Envelope: focus, summary, hint, data, related_focus, next_calls, meta (meta.cache_hit, meta.tokens_returned, meta.credits, meta.charges_usage). Hosted: 7 credits per success; failures free. Cheapest path: mode overview + concern or seed_files — ~1.5–4k tokens, replaces 10+ blind read_code file opens. Repeat identical calls hit server cache (meta.cache_hit) until force:true. Expensive: mode deep or audit on whole monorepo — use subpath. >10k files auto-degrades to overview. data: entry_points, layer_map, concern_cluster (with concern or seed_files[]), integration_map, auth_flow, dependency_graph; deep adds request_flows + Mermaid; audit adds anti_patterns + health_score. dimension_confidence per slice; warnings on low confidence. focus: api|auth|integrations|database|security|data_flow|error_handling|full. Pass concern (any label) or seed_files[] (1–20 from find_code). subpath scopes monorepos. Call BEFORE cross-cutting edits — how a feature spans modules, where to patch. Do NOT for stack (get_project_context), search (find_code), bodies (read_code), tests, packages, live URL. After: next_calls → read_code outline on hub files. Read-only.
keep
keep_thinking
Structure multi-step debugging and planning across tool calls — not a one-shot think. Tracks hypotheses, observations, plans; detects loops via lastActions; riskLevel high/critical blocks dangerous edits (drop table, prod deploy). Loads projectBrief (stack, key_paths, project_memory recall) on local project. On close, suggestedRemember → call project_memory remember. 4 credits hosted. Hard cap 10 thoughts/session. Call when: stuck after 2+ failed debug attempts, auth/billing/schema change spans 3+ files, flaky test you cannot explain, or you need a plan before editing. Pass lastActions (2–5 recent tool calls), goalAnchor after thought 2, sessionId to resume, area for subsystem. NOT when fix is known, single typo, repeating without new evidence, or session ended (nextThoughtNeeded:false). Read thoughtConfirmed and shouldContinue first. Legacy alias: thinking. Example: keep_thinking({ thought: 'Hypothesis: refresh token not rotated in middleware', thoughtType: 'hypothesis', thoughtNumber: 1, totalThoughts: 5, nextThoughtNeeded: true, confidence: 0.6, goalAnchor: 'Fix auth logout loop', lastActions: ['find_code(query=refreshToken)', 'read_code(target=authMiddleware)'], area: 'auth' }). Read-only.
package
check_package
Check a public registry package before install or version bump — frameworks (next, react, vite), payments (stripe), auth (next-auth, clerk), ORMs (prisma, drizzle). task=check: exists, slopsquat, deprecation, CVEs (pass version); task=upgrade|migrate: breaking_changes + migration_steps from release notes; task=security: CVEs for your version. Returns summary, data, next_calls, meta.credits (5 hosted). No project path — just package name + version. Call BEFORE npm install or bumping next/stripe/prisma. NOT for repo layout (get_project_context), import search (find_code), tests (check_test), architecture (explain_architecture), live URLs (audit_headers). Example: check_package({ package: 'next', task: 'upgrade', from_version: '14.2.0' }). Read-only.
test
check_test
Run tests and return structured health — fix_first, broken_areas, failure_clusters, coverage_by_area, blind_spots, deploy probes. Not for finding which files to edit (find_code). Workflow: task=detect (0 credits — framework, command, test file count, missing-test gaps) → task=run once (1 credit hosted on success) → task=failures|missing|why|status|fix_prompt on session_id (0 credits, cached session, no re-run). task=missing scans git diff for source files without tests (0 credits, no suite run). meta.credits and meta.charges_usage show billing. Read summary and fix_first first; detail_level=brief on PASS. Call after every substantive edit, when user asks if tests pass or if tests are missing, or before push. Pass diff_base: main for failures_in_diff. area/file_filter scopes re-runs after a full run. Local stdio: absolute project path (runs on your machine). Hosted: public GitHub URL or inline_files — not local disk paths. NOT for symbols (find_code), packages (check_package), stack brief (get_project_context), URL audit (audit_headers). Example: check_test({ task: "detect", path: "/abs/my-app" }) then check_test({ task: "missing", path: "/abs/my-app" }) then check_test({ task: "run", path: "/abs/my-app" }). Does not modify source.
zephex
Zephex_dev_info
Expert developer playbooks — not your repo. Stripe webhooks & checkout, Supabase RLS, Next.js auth (clerk, next-auth), payment flows, CSP/HSTS, deploy patterns. operation=search finds entries by question; operation=get returns full guidance by slug from search. Read summary and checklist first. 2 credits hosted. No project path. Call when standard patterns beat guessing — wiring stripe checkout, fixing auth middleware, Supabase RLS policies, hardening after audit_headers. Use AFTER repo tools if code context is still thin. NOT for user's codebase (get_project_context, find_code, read_code), registry packages (check_package), tests (check_test), live URL (audit_headers), or saving decisions (project_memory). Example: Zephex_dev_info({ operation: 'search', query: 'Stripe webhook raw body verification', category: 'payments' }) then get with returned slug. Read-only.

Endpoints

URLTransportStateLatencyChecked
https://zephex.dev/mcp streamable-http answering 129 ms 15 min ago

Zephex — questions

Answers built from our own checks of this server.

What can Zephex do?
It exposes 10 tools, read directly from the server on our last check. Among them: audit_headers, check_package, check_test, explain_architecture, find_code, get_project_context and 4 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
What is Zephex mostly used for?
Its tools cluster around code and project. That is what this server is built to work with — the grouping comes from the actual tool names, not from a category we assigned.
Is Zephex working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 4 of 91 checks got a reply (4.4%), average response time 1541 ms. The bar chart above shows every period we have measured.
The registry lists Zephex as active — why does it not respond?
The official MCP registry stores what the author submitted; it does not verify that the server still runs. We check the endpoint ourselves, and this one does not answer. Catalogues that copy the registry without checking will show it as working.
How do I connect Zephex?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Zephex need an API key?
No. Zephex completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 10 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Zephex?
It answers our handshake in 1541 ms on average, which is faster than 2% of all working MCP servers we measure. That is on the slow side — worth knowing if the tool sits inside an interactive loop. The comparison comes from our own checks across the whole registry, every 15 minutes.