Skip to main content
Glama
mariusei

Scantool - File Scanner MCP

by mariusei
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Scan File

scan_file

Analyze a source file or directory to produce a structural skeleton with paths, line numbers, signatures, and condensed excerpts, aiding codebase exploration and AI-assisted development.

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; 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: 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
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.26.0
    • addedInput schema / properties / ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  2. 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"
+}
  3. Changed1 schema field changedv0.20.1
    • addedInput schema / additionalProperties
      Added value: +false
  4. First observedv0.19.4

TDQS

C2.5/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention elision markers (⟨…⟩ +N), focus behavior, and a self-levelling CONNECTIVITY note, which are useful. However, it does not state whether the operation is read-only, what the return structure looks like, how errors are handled, or any side effects. For a scan tool this is a notable gap.

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

Conciseness2/5

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

The description is a dense single paragraph that mixes core functionality, parameter details, CLI commands, and a caveat about the PATH. It is not front-loaded and would benefit from bullet points or clear sections. It contains some redundancy (e.g., repeated mention of budget) and is more verbose than necessary.

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?

For a tool with 15 parameters and no output schema, the description is incomplete. It does not describe the output format (beyond 'skeleton'), does not explain many parameters, and lacks guidance on expected return values or error conditions. While it covers some advanced features, the overall completeness is inadequate for an agent to use it confidently.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for all 15 parameters. It explains depth levels (quick/normal/deep), budget values, focus, and ref, but leaves delta, condense, output_format, show_complexity, show_decorators, show_docstrings, show_signatures, include_metadata, and caller entirely unexplained. The partial coverage is insufficient for the parameter count.

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 states a clear verb ('scan') and resource ('files or a directory') and describes the output as a skeleton with structure, signatures, and excerpts. It is not a tautology and provides a concrete picture of what the tool does, though it does not explicitly contrast itself with sibling tools like scan_directory or scan_file_content.

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

Usage Guidelines2/5

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

The description gives parameter-level guidance (budget for quick vs. exploration, focus for reading a node verbatim) but does not indicate when to choose this tool over its siblings. There is no mention of alternatives or exclusion criteria, leaving the agent to infer the tool's niche from the title and generic scan behavior.

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