Scantool - File Scanner MCP

Overview Schema Source Related Servers Discussions Admin

Scan File Content

scan_file_content

Analyze source code structure to extract classes, functions, methods, and metadata with line numbers. Read file contents, list functions, or focus on a specific function's source.

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. Content given directly (remote files, APIs, a git blob, stdin), same budget/depth and focus as scan_file. 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 - --as <path> or sct focus - --as <path> <name> (if sct is not on PATH, "/app/.venv/bin/python" -m scantool.cli replaces sct).

Input Schema

TableJSON Schema

Name	Required	Default
`mode`	No	balanced
`depth`	No
`focus`	No
`budget`	No
`content`	Yes
`condense`	No
`filename`	Yes
`body_only`	No
`output_format`	No	tree
`show_complexity`	No
`show_decorators`	No
`show_docstrings`	No
`show_signatures`	No
`include_metadata`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.28.0Sep 17, 2026
- addedInput schema / properties / body_only
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```

Changed6 schema fields changedv0.23.0Sep 13, 2026

addedInput schema / properties / budget

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / condense

Added value: +{
+  "default": true,
+  "type": "boolean"
+}

addedInput schema / properties / depth

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / focus

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / include_metadata

Added value: +{
+  "default": true,
+  "type": "boolean"
+}

addedInput schema / properties / mode

Added value: +{
+  "default": "balanced",
+  "type": "string"
+}

Changed1 schema field changedv0.20.1Sep 6, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedv0.19.4Jul 4, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the full disclosure burden and does substantial work: it explains output shape (skeleton, path:line, directory tree gists), elision marker '⟨…⟩ +N' and focus behavior, and per-depth token budgets (quick 300, normal 1500, deep). It omits edge-case behavior like error handling or network failures, but the core read-only scanning behavior is well disclosed.

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 description is dense and every clause adds information, but it is a single run-on paragraph that mixes output format, budgets, elision, use cases, and shell commands without clear separation. The opening phrase 'Skeleton of files or a directory' is confusing as a purpose statement and reduces clarity.

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

Completeness3/5

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

Given 14 parameters, no output schema, and no annotations, the description covers the core use cases and key behavioral parameters but leaves many schema fields and edge behaviors unaddressed. An agent can likely call the tool for reading or outlining directly supplied content, but would be guessing about output_format variants, condense behavior, and the display toggles.

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?

Schema description coverage is 0%, so the description must compensate. It meaningfully explains depth (quick/normal/deep with token approximations), budget, focus, and indirectly content and filename via 'Content given directly' and the `--as <path>` CLI form. However, most optional toggles—mode, condense, body_only, output_format, show_*, include_metadata—are left unexplained, so compensation is only partial.

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 identifies the action as scanning directly supplied content and extracting structural information: 'every structure with path:line, signature or title' and the 'Answers:' list covering read contents, outline, list functions/classes, and show source by name. It distinguishes from scan_file by noting that 'content [is] given directly' rather than via filesystem path, though it does not explicitly name the sibling as the alternative.

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 clear context for when to use this tool: when content is supplied directly from remote files, APIs, git blobs, or stdin. It also provides concrete shell invocations (`sct scan - --as <path>`, `sct focus - --as <path> <name>`) and explains depth/budget behavior, but it does not explicitly say when not to use it or directly contrast it with scan_file/scan_directory.

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

Deploy Server

Scan File Content

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools