CTX
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ctx_projectA | Return the project overview as JSON: {root, git, files, symbols, dependencies, languages}. Use this first to orient a coding agent on a repo: absolute root path, git root, and how large the codebase is (counts of indexed files, symbols and dependency edges, plus the distinct languages present). Requires the project to have been indexed (see ctx_search for symbol lookup). Returns only counts, never file contents. Prefer ctx_stats for detailed index-health numbers (e.g. index.db size) and ctx_search to actually find symbols. |
| ctx_searchA | Search the project's code graph for symbols or file paths by name and return JSON. Symbol results give {name, parent, kind, path, line, signature}; with files=true results give {path, language, size}. Use to find where a function/class/type is defined before reading it, or to locate files by path fragment. Use ctx_symbol for deep detail on a single exact symbol, and ctx_impact to see what depends on a match. query is a case-insensitive substring/name match. Constrain with kind (function, method, class, struct, trait, enum, interface, type, constant, variable, module, field, constructor, impl) and limit results (default 50, 1-500). |
| ctx_skeletonA | Return a body-less structural skeleton of one source file as {path, language, skeleton}. The skeleton preserves signatures, types, exports and doc comments but strips function bodies, so it is a compact map of a file's public API and structure. Use before editing a file to understand its shape without reading the whole body. path is project-relative or absolute (must be inside the project; traversal is rejected). Set with_stats=true to also include {stats} (symbol counts). Only paths for supported languages can be resolved (error otherwise); use ctx_search (files=true) to confirm a path first. |
| ctx_symbolA | Return deep detail for a single symbol as JSON: [{name, kind, signature, file, line, methods, references, dependencies}]. Use when you already know the exact symbol name and need its definition, signature, methods it exposes, everywhere it is referenced, and its dependencies. For fuzzy or name-based discovery use ctx_search first, then ctx_symbol for the best match. Returns an array because a name may resolve in multiple files. |
| ctx_dependenciesA | Return the outbound import edges of a file as JSON: [{target, imported_symbol}] — the project files/modules it imports and, where known, the symbol imported. Use to see what a file depends on before refactoring it. path is project-relative or absolute (traversal rejected). For the reverse direction (who imports this) use ctx_dependents. Requires the project to be indexed. |
| ctx_dependentsA | Return the inbound (reverse) dependency edges of a file as JSON: [{source, imported_symbol}] — the project files that import it and, where known, the symbol they import. Use to find every consumer of a file before changing or removing it. path is project-relative or absolute (traversal rejected). For the forward direction (what a file imports) use ctx_dependencies. |
| ctx_impactA | Analyze the blast radius of changing a symbol or file. Returns an ImpactReport: {target, target_symbol, depth, direct, indirect, tests, unknown} where direct/indirect/test lists are [{path, distance, symbols}]; unknown surfaces imports that could not be statically mapped. Use before modifying code to estimate what else must be checked or updated. Provide exactly one of symbol (a name) or path (a project-relative file); depth controls how many hops of indirect impact to traverse (default 3, 1-20). Requires the project to be indexed; returns an error object if the target is not found. |
| ctx_contextA | Build a compact, relevance-ranked context package for a coding task and return it as JSON. This is the high-value tool: give it a natural-language task and it returns the most relevant files/symbols/snippets to feed to an LLM, optionally including recent git changes. Use when you need a focused slice of the codebase for a prompt instead of reading many files. task is required and should describe the goal; include_bodies (default false) embeds function bodies; max_tokens (default auto, 128-100000) caps package size. |
| ctx_changedA | Return files and symbols changed since a git reference as JSON, including working-tree changes by default. Use to focus an agent on what changed in a branch or commit range before reviewing or testing. ref is a git ref (e.g. HEAD~5, main, a SHA); omit it to report uncommitted working-tree changes. Only works in git repositories (returns an error otherwise). For a per-symbol semantic diff between two refs use ctx_diff; for a plain list of changed file paths use this tool. |
| ctx_diffA | Return a semantic symbol diff between two git refs as JSON: the symbols added, modified or removed per file. Compared to ctx_changed, this is a structural (symbol-aware) diff rather than a file list. Provide base and head explicitly, or supply only base (or neither) — when base alone is given it resolves to its merge-base with HEAD so the diff shows only the current branch's changes; head defaults to HEAD. Only works in git repositories. |
| ctx_statsA | Return index-health statistics as JSON: counts of indexed files, symbols and dependency edges, plus the size of index.db (the underlying code-graph database). Use to check whether the project has been indexed (all-zero counts mean you must run init/indexing before graph tools such as ctx_search or ctx_impact will return results). Read-only, no side effects. For a broader project overview (root/git/languages) use ctx_project. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Most tools are clearly distinct, with ctx_symbol, ctx_search, ctx_skeleton, and ctx_context each serving a different purpose. The only mild ambiguities are ctx_project vs ctx_stats and ctx_changed vs ctx_diff, but the descriptions explicitly point to the more detailed or semantic variant.
All tools share the consistent ctx_ prefix and use lowercase snake_case, which makes the set feel uniform. However, the names mix nouns (symbol, skeleton, impact), a verb (search), and an adjective (changed), so it is not a strict verb_noun pattern throughout.
Eleven tools is a well-scoped size for a code-context server. Each tool covers a distinct aspect of code navigation, dependency analysis, impact assessment, or change tracking without redundant entries.
The tool set covers the full workflow: orient with ctx_project, search and inspect symbols, understand file structure, trace dependencies in both directions, assess impact, and inspect git changes at file or symbol level. There are no obvious dead ends for an agent trying to build a contextual picture of a codebase.