Skip to main content
Glama
mariusei

Scantool - File Scanner MCP

by mariusei
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Scan File

scan_file

Scan any source file to extract its structure—functions, classes, methods, and line numbers—for quick codebase exploration.

Instructions

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, body_only=True without the parent context; ref= reads it at a git ref. May append a self-levelling CONNECTIVITY note (candidate dead/orphan/drift across the corpus, silent when clean). Answers: read a file's contents; outline of a file; list the functions and classes in a file; read or show the source of one function, method or class by name. In your shell: sct scan <path> or sct focus <path> <name> (if sct is not on PATH, "/app/.venv/bin/python" -m scantool.cli replaces sct).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNo
modeNobalanced
deltaNo
depthNo
focusNo
budgetNo
callerNo
condenseNo
body_onlyNo
file_pathYes
output_formatNotree
show_complexityNo
show_decoratorsNo
show_docstringsNo
show_signaturesNo
include_metadataNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.28.0
    • addedInput schema / properties / body_only
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
  2. Changed1 schema field changedv0.26.0
    • addedInput schema / properties / ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  3. Changed2 schema fields changedv0.23.0
    • addedInput schema / properties / caller
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • addedInput schema / properties / include_metadata
      Added value: +{
+  "default": true,
+  "type": "boolean"
+}
  4. Changed1 schema field changedv0.20.1
    • addedInput schema / additionalProperties
      Added value: +false
  5. First observedv0.19.4

TDQS

A3.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but the description carries the burden well: it discloses elision markers ('⟨…⟩ +N'), focus/body_only behavior, git-ref reading, and the optional CONNECTIVITY note with a 'silent when clean' property. This goes beyond basic read-safety and tells the agent what shape and caveats to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core behavior and budgets are front-loaded, and almost every clause carries information. But the prose is telegraphic and run-on ('One file; budget=1500... focus=... reads one node verbatim instead of guessing line ranges'), making it harder to parse than a structured definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 16 parameters, no output schema, and no annotations, the description should explain return formats and flag interactions. It explains the skeleton/tree and elision but does not cover output_format choices, mode/delta/condense semantics, or the show_*/metadata toggles, so it is not complete enough for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds real semantics for depth (quick/normal/deep with token budgets), budget, focus (name or Class.method), body_only, and ref. However, with 16 parameters and 0% schema description coverage, mode, delta, condense, output_format, caller, and the show_* flags are left unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete behavior: 'Skeleton of files or a directory' with path:line, signatures, and condensed excerpts, and later lists specific questions it answers. However, it never names or contrasts sibling tools such as scan_file_content or scan_directory, so an agent must infer how it differs from them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit use cases ('Answers: read a file's contents...'), budget guidance ('budget=1500 for exploration, 300 for a quick look'), and shell equivalents for scan and focus. It doesn't state when to prefer a sibling like scan_diff or search_structures, so exclusion guidance is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools