Describes the environment variables required to run the server.

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

Which tool for what: plain text search (an exact string, log message, config value) → Grep, it is the best at that; "where do I start with this task?" → locate; definitions, structure, callers, impact → callgraph (outline, method_body, find_callers, depth). The first call of a task: give locate the names and domain terms of the task in ONE call: function, class, property and file names, columns, routes, translation keys, and for a non-English domain word its English code name too (e.g. visszatérítés → refund). It answers from the project map without reading files: the top 5 files (all: true: every match), each with its reasons (exact definition, file name, name part, string, call, callers: N). Continue on those files with the outline / method_body / find_callers. Recipes: bug fix = locate → outline of the top file → method_body of the method. "Who calls it / what breaks" = the name pattern with find_callers and depth 2 → method_body of the calling method. Unfamiliar project = project_profile → locate → outline. "Where is this text / constant" = search (strings) / search (constants) (exact text: Grep).

callgraph (callgraph mcp): AST-based, token-efficient code map (PHP, Rust, JS / TS / Vue, Swift, Python, Go, SCSS); the CLI's queries as read-only tools, with the same output. Use it before reading a code file. Paths are relative to the project root: a registered alias (project, list: projects) or the server's working directory. Typical flow: locate (where to start) → outline → method_body for just the method you need → find_callers with the name pattern.

• locate {terms}: where to start with a task (see above): ranked files with reasons, from the names and terms of the task in one call; all: true = every match, not just the top 5.

• outline {path}: structure of a file or directory: classes / components, methods with line ranges, calls by category. Start here. method: one method's call graph; format: api, flow (branches), summary, hotspots.

• method_body {path, method}: line-numbered source; method is a name or a list (["store", "update"]). Compact by default (docblock above and blank lines dropped, comments kept, line numbers exact); doc: true adds the docblock, raw: true gives the exact text.

• find_callers {pattern}: who calls it (file, method, line range, call line); path narrows the scope, depth 2–5 = impact analysis (callers of callers), guess: true adds name-only matches. JS / TS / Vue keys: useForm.js::submit (export), route::orders.show, i18n::orders.title, vue::emit:save, Atoms/AtomButton.vue.

• search {kind: strings | constants, pattern}: where a string literal (error message, key) or a constant is.

• framework_view {view, path}: routes, middleware, validation, jobs, events, providers, magic, di, views of a directory.

• notes: notes left on files / methods (📝, read-only). guide: this manual in full (CLI examples, languages).

• next {result_id, choice}: when the server runs with callgraph mcp --next, some results end with ↪ r7 possible next: [1] … [2] … (read-only navigation); run one by number (choice: 1 or [1, 3]), only if it fits your task; otherwise ignore the line. Output is capped at 400 lines (directory → summary, file → method index, search → 1 line per match): narrow path, method or pattern first; full: true only when justified.

Finding callers: start with the name pattern (^|::|\.|->)name$. It catches every call, also where the receiver type is unknown, inherited or comes from a trait. Type::method finds only the calls resolved to that type (plus calls through its interface / parent / trait), so it can miss callers; use it to narrow a noisy common name (save, find, get).

Reading search output (find_callers, depth, search (strings), search (constants), directories):

• First line root: /abs/path: every path after it is relative to that project root; pass them back as they are (with the same project).

• L25 │ $this->repo->find($id): the call's own source line. You don't need method_body just to see how something is called, only for the full logic.

• via Resolver: the call goes through an interface, parent class or trait of the searched type.

• L12, L40 │ …: the same call on several lines; at most 3 rows per caller, then … +2 more: L55, L61.

• ? / ?::name: the receiver type is unknown, a name-only match; it may be wrong, check the line.

• 🔒 after a file path: the file is protected; read it, don't edit it.

Static analysis: dynamic calls ($this->$method(), obj[key]()), magic methods and class names / registered components assembled at runtime cannot be resolved. They are marked dynamic_call in the outline (PHP, JS / TS / Vue, Python; listed last, the target is the called expression): not a caller edge, so find_callers / depth / locate ignore it — depth only notes how many callers contain one ("check them by hand"). By default depth follows only the certain (resolved) callers; name-only matches are shown by guess: true with a "?" mark. For the exact control logic you need method_body (compact, comments kept; raw: true gives the exact text). A ⚠ syntax error line means a file did not parse fully: the result may be incomplete — read that file directly.

Project profile of the working directory (from folder and file names; details: project_profile; narrow a query to one layer with layer): profile: SwiftUI MVVM (Views → ViewModels) · confidence: medium layers (files): command src/cli/commands (+2 more) 27 model src/model (+2 more) 15 component golden/samples/js 2 view (rust) src/notes (+1 more) 2 handler golden/samples/rust/src 1 route src/query/format/framework 1 store golden/samples/swift 1 view (swift) golden/samples/swift 1 viewmodel golden/samples/swift 1 … +3 more layers (profile --full) patterns: Command / Handler (28: src/cli/commands), Adapter (3), Strategy (2), Builder (1) unknown: src/query/format (22 files), src/profile (19 files), src/lang/js (15 files), +63 more folders

Features and capabilities supported by this server

Functions exposed to the LLM to take actions

Interactive templates invoked by user choice

Contextual data attached and managed by the client