Scantool - File Scanner MCP
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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| preview_directoryB | No command on a directory = orientation: size and language mix, entry points, hot functions, the call-graph map (~3-5k tokens; for first-time orientation of an unknown codebase, not for targeted questions). The file tree is the tier below (scan). In your shell: |
| list_directoriesB | Skeleton of files or a directory: every structure with path:line, signature or title, a condensed excerpt within the budget. A directory gives the tree with one-line gists. --depth quick is about 300 tokens per file, normal 1500, deep everything with module values whole (files only). Elided content is marked ⟨…⟩ +N; focus reads it. Folders only, no files: the directory hierarchy. In your shell: |
| scan_file_contentA | Skeleton of files or a directory: every structure with path:line, signature or title, a condensed excerpt within the budget. A directory gives the tree with one-line gists. --depth quick is about 300 tokens per file, normal 1500, deep everything with module values whole (files only). Elided content is marked ⟨…⟩ +N; focus reads it. Content given directly (remote files, APIs, a git blob, stdin), same budget/depth and focus as scan_file. In your shell: |
| scan_fileC | Skeleton of files or a directory: every structure with path:line, signature or title, a condensed excerpt within the budget. A directory gives the tree with one-line gists. --depth quick is about 300 tokens per file, normal 1500, deep everything with module values whole (files only). Elided content is marked ⟨…⟩ +N; focus reads it. One file; budget=1500 for exploration, 300 for a quick look; focus='name' (or 'Class.method') reads one node verbatim instead of guessing line ranges; ref= reads it at a git ref. May append a self-levelling CONNECTIVITY note (candidate dead/orphan/drift across the corpus, silent when clean). In your shell: |
| scan_directoryB | Skeleton of files or a directory: every structure with path:line, signature or title, a condensed excerpt within the budget. A directory gives the tree with one-line gists. --depth quick is about 300 tokens per file, normal 1500, deep everything with module values whole (files only). Elided content is marked ⟨…⟩ +N; focus reads it. A directory: the file tree with one-line gists per file, code health and churn labels; ref= reads it at a git ref. Replaces Glob/ls for all file types. In your shell: |
| scan_diffA | Structural diff between refs. One ref = that ref vs the working tree. Two refs = A...B against their merge-base by default (--no-merge-base compares the tips; a note says which). Per file: + added, ~ changed (signature: old → new; or body: N code / M doc lines), = renamed (paired by identical body; children follow a renamed class), - removed; identical signature deltas in 3+ functions fold into one row; new files as skeletons; a + or ~ function says how many other changed functions call it. The coverage line counts files changed without structural rows and names the reason for each. --review appends candidate dead/orphan/drift the changed files introduced; off by default on both doors. ref vs the working tree, or ref vs ref2; review=True appends the review tail. Use instead of git diff for review and 'what changed' questions. In your shell: |
| find_divergenceA | Peer divergence across a directory: functions that break a call pattern their siblings follow (peers calling X also call Y, this one does not). A review hint, not a verified bug list; silent on a consistent codebase, and that silence is the answer. In your shell: |
| search_structuresA | Text across a directory (or one file) with structural context: each hit shows its enclosing structure, plus leads to where matched names are defined; when no lead exists it says so. --names matches structure names instead of text, and an empty answer names the paths that match. The pattern is a Python regex; grep's |
| surfaceA | The public surface of a package directory at a ref: every exported name with its signature, how it is exported and where it is defined. Each language applies its own rule: Python's all, lazy tables and re-export chains; Rust's pub and lib.rs re-exports; TypeScript's index exports; Go's exported identifiers; visibility keywords elsewhere; a namespace or module is looked through. --against REF prints the surface diff; the header states the direction (A → B). In your shell: |
| overlapA | N branches against one base, each at its own merge-base: structures touched by 2+ branches (marked base(~/+/-) when the base itself changed them since the branches forked), new names introduced independently by 2+ branches, commits two branches share (a stack: overlap between them is expected; the residual beyond their shared commits is what stays), and per branch whether it is already in the base and by which criterion (ancestor / patch-equivalent / tree-equal; patch-equivalence proves it can be deleted, not that its content is in the current tree). Ends with a merge-order hint, not a verdict. In your shell: |
| callersA | Actual call sites of a function or method across a directory, never a mention in prose, a comment, a docstring or a string literal; each with its enclosing function and path:line, the definition(s) first. A qualified name (Class.method) narrows the definitions; which definition a site binds to is not resolved, and the answer says so. In your shell: |
| historyA | One structure followed backwards through the commits that touched its file: a signature or body change, a rename (paired by identical body, the earlier name followed), the commit that introduced it; a file move is followed. Commits that touched the file but not the structure are counted, not listed. What git log -L gives for a line range, keyed on the structure. In your shell: |
| resolveA | Translate path:line or path::name from one ref to another: the enclosing structure with start and end at --from, and where it is at --to (same place, renamed with an identical body, or gone, with the nearest names). In your shell: |
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 13 tools
The scan/list/preview family (preview_directory, list_directories, scan_file_content, scan_file, scan_directory) shares nearly identical descriptions and differs only by subtle input-target or output-level details, making tool selection ambiguous. The remaining tools are more distinct, but the overlap among the scanning tools creates real boundary confusion.
Names mix verb_noun forms (scan_file, search_structures) with bare nouns (surface, overlap, callers, history) and a lone verb (resolve). The scan_* prefix is consistent, but the broader set lacks a single predictable convention, and list_directories vs scan_directory adds further inconsistency.
13 tools is a substantial but reasonable surface for a comprehensive code-analysis server, covering scanning, diffing, search, callers, history, and ref resolution. The count is slightly inflated by five overlapping list/scan/preview tools, but overall it remains within a well-scoped range.
The tool set covers orientation, scanning, search, diffing, branch overlap, callers, history, and symbol resolution, providing broad read-only code-analysis coverage. Minor gaps exist—such as raw full-file content retrieval and explicit definition lookup—but these are workable through existing skeleton and context tools.