Project Stack & Scripts
get_project_contextAnswer what the user's project is — name, stack, how to run/test/build, auth, database, deploy, folder layout — from their files on disk, not from training data. ALWAYS call this before you invent npm/pip/cargo commands or read package.json yourself. ALWAYS call when the user says: what is this app, what's the stack, how do I run it, how do I test, is this a monorepo, where is auth, what database, how do we deploy. If they named Zephex or MCP, call this first on their project. One topic per call. Start with topic=identity on a new folder, then follow next_calls (usually run or framework). Other topics: backend, frontend, database, auth, deploy, structure, integrations, security. This is the user's machine, any project: Node, Python, Go, Rust, Java, PHP, a monorepo, an unsaved folder. Local/stdio: omit path to use the editor cwd, or pass path as their project folder. No disk on this transport: inline_files with package.json or pyproject.toml/go.mod/Cargo.toml plus 2–4 source files. Returns topic, summary, data (identity, commands, key_paths), hint, next_calls. Copy dev/test/build from data — do not guess bun vs npm vs uv. Not for finding a function name (find_code) or reading a file body (read_code). Those come after you know what the project is. Example: get_project_context({ topic: "identity" }) then get_project_context({ topic: "run" }). Also call topic=auth before touching login, topic=database before schema work, topic=structure when you need the folder map. force:true if the project just changed. Brief is enough for orientation; do not skip this tool to save a round-trip — one identity call replaces reading several manifests.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | The user's project folder. Local/stdio: omit to use editor cwd, or pass the absolute folder (any OS). Hosted with no disk: omit and use inline_files. | |
| force | No | Set true to re-detect even if cached (use when project changed) | |
| topic | No | Which slice to return (one per call). identity=project name/type + which topics apply; run=dev/test/build/lint commands; framework=language/runtime/package manager; backend=API routes and server entry points; frontend=UI framework and pages; database=ORM and providers; auth=login/session providers; deploy=hosting and CI; structure=monorepo layout; integrations=Stripe/Sentry/etc.; security=env and auth surface. | |
| focus_on | No | Subdirectory to focus the file tree scan on (e.g. 'src/tools') | |
| detail_level | No | Output tier: "brief" (default, ≤500 tokens), "standard" (full fields), "full" (all fields + file tree) | |
| inline_files | No | Primary way to supply code. Shape: { "": "", ... }. The VALUE is the actual file body — never a filename, path, or placeholder. Example: { "package.json": "{\"name\":\"my-app\",\"dependencies\":{...}}" }. Always include the project-definition file (package.json / pyproject.toml / Cargo.toml / go.mod / pom.xml / Gemfile / composer.json / pubspec.yaml) plus tsconfig.json / framework config if present, plus 2-4 representative source files. Works on Mac, Windows, Linux, private repos, unsaved folders. | |
| structure_depth | No | Max folder depth for file tree scan (default: 3, max: 6) | |
| include_structure | No | When true, includes file tree in response (also triggered by detail_level: full) |