repocontext
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_codebase_mapA | Extracts a token-efficient AST symbol outline map (classes, interfaces, functions, methods, exported types) across the repository. Behavior: Read-only operation. Zero file modifications, zero persistent side-effects, and zero network calls. Returns structured Markdown. When to use: Call this at the start of a coding task to inspect repository architecture, directory structure, and symbol hierarchies with 70%~85% token savings. When NOT to use: Do NOT use this if you need full function implementations (use read_file_content instead), or if you already know the target task and want only relevant files (use extract_relevant_context instead). |
| extract_relevant_contextA | Performs semantic relevance ranking to extract and package code files pertinent to a specific user coding task or bug report within a token budget. Behavior: Read-only operation. Zero file modifications, zero persistent side-effects, and zero network calls. Applies automatic secret redaction. Returns formatted Markdown. When to use: Use this when given a specific feature request, issue, or debugging objective to gather only the essential source code. When NOT to use: Do NOT use this for full-repository structural overviews (use get_codebase_map instead), or to inspect single file outlines (use read_file_outline instead). |
| read_file_outlineA | Extracts the semantic AST skeleton outline of a single source file, preserving all class declarations, function signatures, interfaces, and docstrings while stripping function bodies. Behavior: Read-only operation. Zero file modifications and zero network calls. Returns syntax-highlighted code block. When to use: Use this to understand API contracts, public types, and method signatures of an individual file without consuming tokens on implementation details. When NOT to use: Do NOT use this if you need complete implementation logic (use read_file_content instead), or if you need an overview of multiple repository files (use get_codebase_map instead). |
| read_file_contentA | Reads raw source code from a single file, with optional line-range slicing and automatic security redaction for secrets and sensitive keys. Behavior: Read-only operation. Zero file modifications and zero network calls. Automatically masks detected credentials. Returns formatted Markdown code block with line indicators. When to use: Use this when you must inspect, debug, or verify exact line-by-line implementation logic of a specific file identified through previous outline or mapping steps. When NOT to use: Do NOT use this for blind exploration of unfamiliar files (use read_file_outline or get_codebase_map first to conserve token budget). |
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 4 tools
Each tool serves a clearly distinct purpose: repo-wide symbol map, task-specific file extraction, single-file outline, and full file content. The descriptions include explicit 'when to use' and 'when NOT to use' guidance, eliminating any potential for misselection.
All four tools follow the verb_noun snake_case pattern (get_codebase_map, extract_relevant_context, read_file_outline, read_file_content). While the verbs differ (get, extract, read), the structure is consistent and the names accurately reflect each tool's function.
With exactly 4 tools, the server is well-scoped for its purpose of repository context exploration. Each tool fills a distinct role in the workflow, and there is no redundancy or unnecessary bloat.
The tool set covers the full lifecycle of code exploration: repo-wide mapping, semantic relevance filtering for tasks, single-file outlines, and raw content access. This provides a complete read-only context-gathering workflow with no obvious dead ends or missing operations.