get_file_outline
Structured summary of a file: exported symbols, types, signatures, line numbers. No implementation details.
What It Does
get_file_outline returns the structural skeleton of a file: every exported symbol, its kind (function, class, interface, type, variable), its signature, and its line number. What it does not return is implementation — no function bodies, no logic, no comments beyond JSDoc summaries.
This is the difference between reading a book’s table of contents and reading the entire book. When an agent needs to know “what does this file export?” or “what functions are in this service?”, reading the full file wastes tokens on implementation details that are irrelevant to the question.
Benchmark Results
Measured across three files of different sizes:
| File | Full Read (tokens) | get_file_outline (tokens) | Reduction |
|---|---|---|---|
| Small service (120 lines) | 890 | 180 | -80% |
| Medium service (340 lines) | 2,300 | 420 | -82% |
| Large component (680 lines) | 4,100 | 560 | -86% |
The savings scale with file size. Larger files have more implementation to skip, so the outline becomes proportionally cheaper. For a 680-line React component, the outline shows the component signature, its props type, and the hooks it uses — everything an agent needs for navigation — at 86% less cost than reading the full file.
What the Outline Contains
For a typical TypeScript service file, the outline includes:
- Exported functions — name, parameters with types, return type, line number
- Interfaces and types — name, fields with types, line number
- Classes — name, constructor signature, public methods
- Constants — name, type, line number
- Re-exports — what the file re-exports from other modules
What it excludes:
- Function bodies (the actual logic)
- Private/internal helper functions
- Import statements (unless they are re-exported)
- Comments (except JSDoc summaries attached to exports)
When Outline vs Full File
Use the outline when:
- Deciding which symbol to read in detail (use
get_symbolfor that) - Understanding a file’s API surface before modifying it
- Checking what a module exports for import planning
- Comparing two files’ structures during refactoring
Read the full file when:
- You need to modify the file (you need the implementation)
- You are debugging a specific function (need the logic)
- The file is small (<50 lines) — the outline does not save much
Key Parameters
file_path(required) — path relative to repo root (e.g.,src/services/risk.service.ts)
The tool has minimal configuration because its purpose is straightforward: return the structure, skip the implementation.
Relationship to Other Navigation Tools
get_file_tree tells you which files exist. get_file_outline tells you what is inside a specific file. get_symbol fetches one specific symbol’s full source. These three tools form a drill-down pattern: tree (find files) then outline (find symbols) then symbol (read code).
Related tools
Benchmark note
This benchmark compares CodeSift against the closest practical native workflow an agent would use for the same task.
For some tools, that baseline is a direct shell equivalent such as rg or find.
For AST-aware, graph-aware, and LSP-backed tools, the baseline is a multi-step workflow rather than a strictly identical command.
Results should be read as agent-workflow comparisons: token cost, call count, and practical context efficiency.