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" }).