Skip to main content
Glama

Zephex

by io.github.Tanbir404

Explain Architecture

explain_architecture
Read-onlyIdempotent

Map how files in the user's project connect — which files are hubs, what imports what, where auth/API/database live. Not file bodies. ALWAYS call when they ask how auth works, where login is checked, what's the database, how the API is wired, give me an overview of these files, or where do I patch this feature. If they named Zephex or MCP and want a wiring map, you MUST call this before opening a pile of files. Prefer this over native Read on 10–20 files. Any language on their machine: Python CLI, Node, Go, a monorepo, an unsaved folder. Local/stdio: omit path (editor cwd) or pass their folder. No disk: inline_files or a public GitHub URL (https://github.com/owner/repo). concern = the word they used (auth, gateway, billing, users) — any label, not a fixed list. focus=auth|api|database|integrations when they named that slice. mode=overview first; mode=deep only if you need request_flows. subpath = one package in a monorepo. Read summary + data.entry_points + data.auth_flow + data.concern_cluster + next_calls. Then read_code outline on those hubs — do not open 20 files yourself. Empty cluster means that label is not in this repo. Outbound provider keys (OPENAI_API_KEY) are not inbound login. Not for stack/scripts (get_project_context). Not for 'where is this symbol' (find_code). Not for a function body (read_code). Example: explain_architecture({ concern: "auth", mode: "overview" }). Public repo: explain_architecture({ path: "https://github.com/owner/repo", focus: "api" }).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNooverview=fast wiring map (no AST flow trace), deep=request_flows + sequenceDiagram, audit=anti_patterns + health_score. Default: overview
pathNoThe user's project folder. Local/stdio: omit to use editor cwd, or pass the absolute folder. Hosted with no disk: omit and use inline_files, or a public GitHub URL.
focusNoWiring slice. Default: api. auth=validation chain, integrations=external SDK touchpoints, database=ORM, security=auth+errors, full=all analyzers.
forceNoBypass architecture result cache. Default false.
concernNoAny subsystem label (folder name, feature codename, module). Uses find_code concept search + import graph — not a fixed keyword list. Returns roles, edges, symbols (no file bodies).
excludeNoOptional glob patterns to exclude from ripgrep (vendor, build, etc.).
subpathNoMonorepo scope — analyze only this subdirectory (e.g. apps/api). Faster than whole repo.
verbosityNoOutput size. minimal=core only, standard=default, full=adds constraints + state_management. Alias: detail_level
seed_filesNo1–20 paths from find_code — graph expands to related modules. Use with or without concern.
detail_levelNoLegacy alias for verbosity
inline_filesNoFallback for remote transports. Shape: { "": "" }. Include 10-50 SOURCE files (entry points, routes, middleware, auth, DB setup) plus package.json. For local stdio, prefer 'path'.
project_pathNoAlias for 'path' (some clients pass this name). Accepts the same values.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / path / description
      Previous value: -"Where the project lives. Stdio MCP: absolute path to the project directory on disk. Hosted transport without local disk: use inline_files (10–50 source files + package.json)."New value: +"The user's project folder. Local/stdio: omit to use editor cwd, or pass the absolute folder. Hosted with no disk: omit and use inline_files, or a public GitHub URL."
  2. Changed1 schema field changed
    • changedInput schema / properties / path / description
      Previous value: -"Where the project lives. Local absolute directory (e.g. /Users/alice/myapp on macOS, /home/alice/myapp on Linux, C:/Users/alice/myapp on Windows, /mnt/c/Users/alice/myapp on WSL) OR a GitHub / GitLab / Bitbucket URL (https://github.com/owner/repo or short-form github:owner/repo). Private repos require GITHUB_PAT on the server."New value: +"Where the project lives. Stdio MCP: absolute path to the project directory on disk. Hosted transport without local disk: use inline_files (10–50 source files + package.json)."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey read-only and non-destructive behavior, and the description adds meaningful behavioral context: it returns an architecture map, has empty-cluster semantics for absent labels, clarifies that outbound provider keys are not inbound login, and warns against opening many files manually. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and the first sentence carries the essential meaning. It is long and dense, and its one-paragraph layout makes scanning harder, so it loses a point on structure despite every sentence carrying useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by naming expected result fields (summary, data.entry_points, data.auth_flow, data.concern_cluster, next_calls), giving the follow-up workflow (read_code on hubs), covering the local/stdio/remote cases, and explaining what an empty cluster means. For a 12-parameter compositional analysis tool, this is a fully serviceable definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Because the schema documentation covers 100% of parameters, the floor is 3, but the description adds clarifying semantics beyond the schema: 'concern' is any user label, not a fixed list, 'focus' maps to the slice the user named, 'path' behaves differently for local vs hosted, and it gives concrete invocation examples. Not every parameter gets extra treatment, so 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Map how files in the user's project connect' and clarifies scope with 'Not file bodies'. It also distinguishes itself from siblings like read_code and find_code, so an agent gets a crisp picture of what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-call triggers ('ALWAYS call when they ask how auth works', 'where to patch this feature'), a MUST-call condition for Zephex/MCP wiring questions, and an explicit not-for list naming sibling tools. It even advises preferring this over native Read on 10–20 files.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Zephex toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct domain: URL auditing, package checking, tests, architecture, code search, project context, planning, memory, code reading, and expert guides. Descriptions are extremely detailed and explicitly state when not to use each tool, leaving no ambiguity.

Naming Consistency4/5

Most tools follow the verb_noun snake_case pattern (audit_headers, check_package, check_test, explain_architecture, find_code, get_project_context, read_code), but project_memory (noun_noun) and Zephex_dev_info (brand_noun) deviate, and keep_thinking uses a gerund instead of a noun. The pattern is strong but not perfectly uniform.

Tool Count5/5

10 tools is well-scoped for a comprehensive development assistant. Each tool serves a clear purpose without redundancy, covering security, package management, testing, code understanding, project context, planning, memory, and expert knowledge. The count is neither too few nor excessive.

Completeness4/5

The tool surface covers a wide range of development analysis tasks: security auditing, package checking, test running, architecture mapping, code search, project context, planning, memory, code reading, and developer guides. Minor gaps include the lack of direct code editing or project execution/build tools, but the server appears intentionally focused on read-only information and planning.

Resources