Skip to main content
Glama
Majrooo

majrooo-mcp-devkit

by Majrooo

split_file_by_declarations

Destructive

Split a large source file into smaller modules by top-level declarations, with optional index/combining file generation and dry-run preview before writing.

Instructions

Split a large file into multiple smaller files based on top-level declarations. Optionally generates a combining file (mod.rs / index.ts / init.py). Use dryRun: true (default) to preview the layout before writing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking dir for resolving relative file paths (default: primary project root)
fileYesSource file to split
dryRunNoPreview only — write nothing (default: true)
groupingYesModule groupings
languageNoLanguage (auto-detected from extension)
overwriteNoAllow overwriting existing target files (default: false)
targetDirNoWhere new files are written (default: dirname of file)
generateIndexNoCreate combining file (default: true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered; the description adds real value beyond that by disclosing that dryRun defaults to true (preview-before-write) and that a combining file is optionally generated. It still omits explicit overwrite/destruction semantics, but the default-safe behavior is a meaningful addition.

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?

Three tight sentences: purpose first, then the auxiliary output, then the safety-relevant default. No filler, and the most important information is front-loaded.

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 an 8-parameter mutating tool with no output schema, the description plus fully-covered schema and destructiveness annotations give the agent enough to call it correctly. Minor gaps remain around failure/return behavior, but the schema and annotations carry the rest.

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 coverage is 100%, so the schema already documents all 8 parameters (cwd, file, dryRun, grouping, language, overwrite, targetDir, generateIndex). The description only reinforces dryRun and the combining-file/index concept, adding nothing the schema doesn't already convey. Baseline 3 applies.

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?

Specific verb (Split) + resource (a large file) + mechanism (based on top-level declarations), with the auxiliary combining-file behavior named. It does not explicitly differentiate from potentially adjacent siblings such as generate_module_skeleton or batch_apply_edits, so it stops short of a 5.

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 the use case (splitting large files) and gives safety-oriented guidance for the dryRun flag, but never states when to prefer this over alternatives like generate_module_skeleton. Usage is only implied, not routed.

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