Skip to main content
Glama
Sign In
File Organizer MCP

File Organizer MCP

by kridaydave
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Preview File Organization Plan

file_organizer_preview_organization
Read-onlyIdempotent

Preview file organization outcomes without applying changes. See moves, conflicts, and skip reasons before finalizing.

Instructions

Shows what would happen if files were organized, WITHOUT making any changes. Shows moves, conflicts, and skip reasons.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "directory": "<directory>"
    },
    "name": "file_organizer_preview_organization"
  }
}

Input Schema

NameRequiredDescriptionDefault
directoryYesFull path to the directory
response_formatNomarkdown
conflict_strategyNoHow to handle file conflicts for preview (rename/skip/overwrite). Uses config default if not specified
show_conflicts_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.5.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description reinforces these and adds value by listing the specific behavioral outputs: moves, conflicts, and skip reasons. This goes beyond what the annotations state. It does not mention the impact of conflict_strategy or response_format, but those are captured in the schema. No contradiction; the description is consistent with annotations.

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

Conciseness5/5

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

The description is two sentences with no waste. The core purpose and key differentiator ('WITHOUT making any changes') is front-loaded, and the output specifics are listed concisely. Every word earns its place.

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

Completeness4/5

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

For a preview tool with 4 parameters and no output schema, the description covers the essential outcome and non-destructive nature. However, it omits how parameters like conflict_strategy or response_format influence the preview output, and does not describe the response structure. Given the schema provides parameter details and the tool's purpose is simple, this is a minor gap rather than a fatal one.

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?

The description does not reference any of the four parameters. Schema coverage is 50% (directory and conflict_strategy have descriptions, while response_format and show_conflicts_only lack them). The tool description provides no additional meaning beyond parameter names, leaving the two undocumented parameters unsupported by semantic guidance. A tool description could easily mention that conflict_strategy affects the preview's conflict handling, but it does not.

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

Purpose5/5

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

The description clearly states this is a preview tool: 'Shows what would happen if files were organized, WITHOUT making any changes.' It also specifies the outputs (moves, conflicts, skip reasons), distinguishing it from actual organization tools like file_organizer_organize_files. The verb-resource pairing is explicit and unambiguous.

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

Usage Guidelines3/5

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

The description implies a dry-run use case ('Shows what would happen if...') and emphasizes non-destructiveness, but it does not explicitly name alternatives or provide a when-to-use vs. when-not-to-use rule. It leaves the agent to infer that this should precede a real organization, but gives no direct guidance against other sibling tools. This is acceptable but not explicit.

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