A read-only MCP server that wraps WizTree's CSV export functionality to provide disk usage analysis tools on Windows.
Locate WizTree (locate_wiztree): Automatically find the WizTree executable from environment variables, PATH, or common installation directories.
Scan a Drive or Folder (scan_path): Run WizTree to export a CSV snapshot of a drive or folder, with options for admin elevation, file/folder filters, sorting, timeout, and optional treemap PNG generation.
List Snapshots (list_snapshots): View available CSV snapshots in the export directory, ordered newest first.
Analyze a CSV Snapshot (analyze_csv): Summarize an existing WizTree CSV export, including top entries by size.
List Top Entries (top_entries): Retrieve the largest files, folders, or all entries from a snapshot, sortable by size or allocated space.
Drill Down into Folders (drill_down): Inspect the direct children of a specific folder within a snapshot, sorted by size.
Search Entries (search_entries): Find paths matching a substring or glob pattern, with total matched size and count.
Find Old Large Files (old_large_files): Identify large files that have not been modified recently, sorted by size.
Summarize by Extension (extension_summary): Aggregate and rank disk usage broken down by file extension.
Compare Snapshots (compare_csv): Diff two CSV exports to identify the largest growth or shrinkage by path.
Get Treemap Image (get_treemap): Retrieve a previously generated treemap PNG as an inline image.
Clean Up Snapshots (cleanup_snapshots): Delete older CSV and PNG exports, retaining only the most recent ones.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WizTree MCP scan drive C and list top 20 files by size"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Read-only MCP server that wraps WizTree's CSV export and adds disk-usage analysis tools.
Windows-only in practice, because it depends on WizTree.
locate_wiztree: Find a WizTree executable from WIZTREE_PATH, PATH, and common install locations.
scan_path: Run WizTree CSV export for a drive or folder. Writes CSV snapshots under exports/. With treemap: true, also exports a treemap PNG and returns it inline as an image.
list_snapshots: List CSV snapshots in the export directory, newest first.
analyze_csv: Summarize an existing WizTree CSV snapshot.
top_entries: List the largest files or folders from a CSV snapshot.
drill_down: List the direct children of a folder within a snapshot, sorted by size.
search_entries: Search a snapshot for paths matching a substring or glob (* and ?), with total matched size and count.
old_large_files: Find large files not modified for a long time, sorted by size.
extension_summary: Aggregate file usage by extension.
compare_csv: Compare two CSV snapshots and report growth/shrinkage by path.
get_treemap: Return a previously generated treemap PNG as an image.
cleanup_snapshots: Delete older CSV/PNG exports from the export directory, keeping the most recent ones.
The server never touches scanned files. It only launches WizTree for export and reads generated CSVs; the one exception is cleanup_snapshots, which deletes only this server's own exports inside the export directory.
List-style tools return compact tab-separated tables instead of JSON to keep token usage low. Parsed snapshots are cached in memory, so repeated queries against the same CSV do not re-parse it.
Related MCP server: Disk Insights MCP
Clone the repo, enter the repo folder, install dependencies, and build the TypeScript output.
git clone https://github.com/onmokoworks/wiztree-mcp.git
cd wiztree-mcp
npm install
npm run buildThis produces dist/index.js, which is the file your MCP client should run.
Replace C:\\path\\to\\wiztree-mcp with the folder where you cloned this repo.
{
"mcpServers": {
"wiztree": {
"command": "node",
"args": ["C:\\path\\to\\wiztree-mcp\\dist\\index.js"],
"env": {
"WIZTREE_PATH": "C:\\Program Files\\WizTree\\WizTree64.exe"
}
}
}
}WIZTREE_PATH is optional if WizTree is installed in a common location or is on PATH.
For Codex, add the same server to C:\\Users\\<you>\\.codex\\config.toml:
[mcp_servers.wiztree]
command = 'node'
args = ['C:\path\to\wiztree-mcp\dist\index.js']
startup_timeout_sec = 120
[mcp_servers.wiztree.env]
WIZTREE_PATH = 'C:\Program Files\WizTree\WizTree64.exe'After changing MCP configuration, restart the MCP client or open a new session so it reloads the server list.
You can verify that the compiled server starts with:
node .\dist\index.jsThe process waits for MCP JSON-RPC messages over stdio, so it will appear idle. Press Ctrl+C to stop it.
WizTree CSV exports contain full local file and folder paths. This server writes exports to exports/ by default, and that directory is intentionally ignored by Git.
Before sharing logs, screenshots, or CSV files, check that they do not expose private project names, user names, or file paths.
This server does not delete, move, or modify scanned files. Only cleanup_snapshots deletes files, and only inside the export directory.
Running WizTree with admin: true triggers a Windows UAC elevation dialog; in an unattended environment the scan will hang until the configured timeout.
The CSV parser supports both English and Japanese WizTree column headers.
Summarize an existing WizTree CSV snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| csvPath | Yes | Path to a WizTree CSV export. | |
| topLimit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Summarize' without detailing what the summary contains, whether it modifies data, or any output characteristics. The lack of behavioral disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose. However, it could be slightly expanded to include key details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of two parameters, no output schema, and sibling tools, the description is insufficient. It does not explain the output format, what 'summarize' means in practice, or how topLimit affects results. The agent would have to infer or test to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although csvPath has a schema description, the description adds nothing beyond it. The topLimit parameter lacks any semantic explanation in both schema and description; its purpose and effect on output are unclear. With 50% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Summarize an existing WizTree CSV snapshot' clearly states the verb (summarize) and resource (WizTree CSV snapshot). It implicitly distinguishes from siblings like 'top_entries' and 'extension_summary' by indicating it summarizes the entire snapshot rather than focusing on specific aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'compare_csv' or 'scan_path'. It does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two WizTree CSV snapshots by path and report the largest changes.
| Name | Required | Description | Default |
|---|---|---|---|
| beforeCsvPath | Yes | ||
| afterCsvPath | Yes | ||
| kind | No | all | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions comparison by path and reporting largest changes, but lacks details on what 'largest changes' means, case sensitivity, error handling, or performance implications. The absence of annotations amplifies the gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is front-loaded but critically under-specified. It lacks necessary detail, making it insufficient for effective tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is far from complete. It does not explain the output format, parameter semantics, or usage context, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the 4 parameters. It does not mention any parameter names, types, or defaults, leaving the agent to infer from the schema alone. The description adds zero value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two WizTree CSV snapshots and reports the largest changes, which is specific and distinct from sibling tools like analyze_csv or extension_summary. However, it doesn't explicitly differentiate from siblings, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like analyze_csv or top_entries. The description does not mention prerequisites, constraints, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate file usage by extension from a WizTree CSV snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| csvPath | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the purpose and does not disclose behaviors such as file reading, aggregation formula, output format, or error handling. This is insufficient for an agent to understand operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loading the purpose. However, the conciseness comes at the cost of missing critical details, but structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain what 'aggregate' means (e.g., sum of sizes, count), what the output looks like, or how to use the tool effectively. Completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter (csvPath or limit). The description mentions 'WizTree CSV snapshot' but gives no detail about csvPath format or limit's purpose, leaving agents to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Aggregate', the resource 'file usage by extension', and the source 'WizTree CSV snapshot'. It distinguishes from sibling tools like analyze_csv and top_entries by specifying extension-level aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for aggregating extension data from a WizTree CSV but does not provide explicit when-to-use or when-not-to-use guidance, nor does it contrast with alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a WizTree executable using WIZTREE_PATH, PATH, and common install folders.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It describes the search locations but does not disclose whether the tool is read-only, what happens if the executable is not found, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the purpose and method without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the search method but does not mention the return value (e.g., path string or error). Given no output schema, this is a gap. However, the tool is simple and the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100% by default. The description adds context about the search locations, which is helpful but not strictly about parameters. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'WizTree executable', and the search strategy is specified. It is distinct from sibling tools which analyze, compare, or scan data rather than locate an executable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for locating the WizTree executable, which is a prerequisite for other tools. However, it does not explicitly state when to use or not use it, or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run WizTree CSV export for a drive or folder. This is read-only and writes a CSV snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| targetPath | Yes | Drive or folder to scan, such as "C:" or "D:\Data". | |
| wiztreePath | No | Optional explicit path to WizTree64.exe or WizTree.exe. | |
| includeFiles | No | Include file rows in the export. | |
| includeFolders | No | Include folder rows in the export. | |
| admin | No | Pass /admin=1 to WizTree. May trigger Windows elevation. | |
| filter | No | Optional WizTree include filter, such as "*.mp4". | |
| filterExclude | No | Optional WizTree exclude filter, such as "node_modules". | |
| sortBy | No | Optional WizTree sort option, such as "size". | |
| treemap | No | Also export a 1024x768 treemap PNG beside the CSV. | |
| timeoutSeconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool as 'read-only' and mentions writing a CSV snapshot, but lacks detail on potential side effects (e.g., admin elevation triggers, timeout behavior, file overwrite behavior). Without annotations, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundant information. Each word adds value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief for a tool with 10 parameters and no output schema. It omits details like return value (e.g., path to CSV), error conditions, prerequisites (WizTree installation), and performance expectations. This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 90% (9 of 10 parameters have descriptions), so the schema already provides parameter semantics. The description adds overall context but does not enhance individual parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Run WizTree CSV export') and the resource ('drive or folder'), and distinguishes from sibling tools like analyze_csv and compare_csv by specifying it produces a CSV snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scanning a path and producing a CSV, but provides no explicit guidance on when to use this tool versus alternatives like top_entries or compare_csv. No when-not-to-use conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the largest files, folders, or all rows from a WizTree CSV snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| csvPath | Yes | ||
| kind | No | all | |
| by | No | size | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only mentions listing, without disclosing read-only nature, error handling, or performance implications, which reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified; it lacks detail on parameters and output, making it minimally acceptable for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and limited description, the return format is unknown. The tool's behavior for kind=all (potentially large output) is not addressed, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), and the tool description does not explain any parameters (csvPath, kind, by, limit), leaving agents without necessary context for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists largest files, folders, or all rows from a WizTree CSV snapshot, distinguishing it from sibling tools like analyze_csv or compare_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage for viewing top entries, but no explicit guidance on when not to use it or alternatives is provided, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_csvcompare_csvextension_summarylocate_wiztreescan_pathtop_entriesScored across 6 tools
Each tool has a clearly distinct purpose: analyzing a CSV, comparing two CSVs, aggregating by extension, locating the WizTree executable, scanning a path to create a CSV, and listing top entries. No overlap or ambiguity.
All names use lowercase with underscores (snake_case), and most follow a verb_noun pattern (analyze_csv, compare_csv, locate_wiztree, scan_path). Two names (extension_summary, top_entries) are slightly different but still clear and consistent in style, so only minor deviation.
With 6 tools, the set is well-scoped for the domain of disk space analysis via WizTree CSV snapshots. Each tool earns its place, covering creation, analysis, comparison, and listing without being excessive or insufficient.
The tools cover the core workflow: scanning a path to create a CSV, summarizing, comparing, and extracting specific views (by extension, top entries). A minor gap is the lack of a tool to delete or filter snapshots, but the set is largely complete for the stated purpose.
Read-only MCP server exposing a user ORANO library to their own AI agent.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Official Microsoft MCP Server to query Microsoft Entra data using natural language
