A Rust file rarely becomes difficult to work in all at once. A few helpers accumulate beside a type. Its impl grows. Parsing, validation, and error handling end up sharing the same file because that was the easiest place to put them at the time.

Eventually, you ask a coding agent to split it up. Moving the text is straightforward. Deciding what should move together, which imports need to change, and what the tests can still access takes more care. A shorter file is not much of an improvement if understanding it now requires jumping through five poorly named modules.

rust-sitter-mcp gives agents structural tools for this work. It can inspect a large Rust file, suggest groups worth extracting, and produce reviewable patches for supported moves. When a move falls outside its automated coverage, the analysis can still help the agent plan and carry out the refactor with ordinary editing tools.

Start with the boundary, not the line count

“Split this file into chunks of 500 lines” gives an agent a measurable target, but says little about whether the result will be easier to maintain. Closely related code can end up separated just because a function happened to cross the cutoff.

The tool's suggest_split operation starts with the code's written structure. It inventories functions, types, implementation blocks, and their direct members, then offers candidate groups with reasons and supporting source locations. It surfaces relationships between types and implementations, reference patterns, and possible dependencies across a proposed boundary. Test access is part of the report too, within the scope it can inspect.

Those suggestions need engineering judgment. A shared name prefix is a clue, not an architectural decision. A helper used by one type may belong beside it, or it may deserve a separate home. The report gives the agent something concrete to investigate rather than asking it to invent a module layout from a quick skim.

It can also return incomplete analysis or no credible split. Neither means the file is well organized. Sometimes the available evidence is insufficient; sometimes the real problem is one enormous function that needs refactoring before moving whole items will help.

Automate the moves that can be checked

After reviewing the advice, the agent selects the items and their destinations explicitly. The move_item operation can plan moves into existing files, new sibling modules, or supported private child modules. It also supports moving eligible inherent methods and associated constants, so a large impl does not always have to travel as one block.

For supported cases, the plan includes the necessary import, path, and visibility changes. Comments and attributes are accounted for, and unrelated source bytes are preserved rather than reformatted as a side effect. Ambiguities are surfaced for review instead of silently guessed away.

The server does not edit your source tree. It returns a patch for the agent or developer to inspect and apply externally. That separation makes it possible to check the full proposed change before any files move.

This is bounded automation. A useful split suggestion does not guarantee an applicable patch, and a successful tool call does not mean the move passed its checks. The agent needs to inspect the plan's applicability and any unresolved decisions.

Where tree-sitter and rust-analyzer fit

There are two kinds of information involved here.

Tree-sitter supplies the syntax-tree view: where an item begins and ends, what kind of declaration it is, and how the written code is arranged. This is more precise than looking for matching text or counting braces, and it underpins the structural advice and edits.

Some relocation questions require more than syntax. A method call, for example, may need evidence about the receiver and the declaration it resolves to. For supported move checks, the tool can opt into rust-analyzer-based resolution using explicitly supplied crate configuration and source context.

It uses rust-analyzer libraries directly, rather than connecting to a running Language Server Protocol (LSP) server. Split advice remains structural; the optional resolution checks belong to move planning. They do not establish that the whole project compiles or that behavior is unchanged.

Macros, trait-dependent behavior, conditional code, and incomplete dependency context can still prevent an automated move. The tool documentation describes the supported cases and configuration requirements. Expect to encounter these limits in ordinary application code, not only unusual Rust.

Use the advice even when automation stops

A blocked patch does not make the investigation wasted work. The inventory may have identified a useful extraction, while the move report points to a dependency or consumer that needs manual attention.

At that point, the agent can explain the limitation, revise the proposed boundary, or make a separately reviewed manual edit and validate it with the compiler and tests. It should not hide troublesome consumers from the analysis or weaken checks just to obtain an applicable result.

This is an important part of the tool's usefulness: it helps with both the decision and the mechanical work, without pretending they are the same task. You can use it for advice alone, or continue into patch generation where the code fits its supported cases.

A practical agent workflow

Start with one file and a reason to split it. For example, you could ask:

Inspect this Rust file with rust-sitter-mcp and suggest a cohesive extraction. Explain what should stay together, what imports or visibility would change, and which test dependencies need review. Show me the proposal before editing. If the move is supported, generate a patch; otherwise explain what needs manual work.

A useful workflow is:

  1. Inspect the advice. Check its scope, completeness, candidate groups, and unresolved dependencies.
  2. Choose the boundary. Review the selected items and give the destination a name that describes its responsibility.
  3. Request the move plan. Use current source text and explicit destinations, then review the entire patch and its decisions.
  4. Apply and verify. Recheck that the patch still applies to the current files, then run cargo check, the relevant tests, and the project's usual validation commands.

Keep behavior changes out of the split where possible. Reviewing a relocation is easier when it does not also rewrite the functions being moved.

Try it on a file you already want to split

The project is MIT-licensed and runs as a local MCP server. Install it with:

cargo install --locked --git https://github.com/Chrysent-AI/rust-sitter-mcp

See the README for build prerequisites and client configuration. Connect your MCP client to the rust-sitter-mcp stdio command. The binary also exposes a read_skill_guide tool, so an agent can retrieve the bundled workflow guidance without a separate repository checkout.

Pick a file where navigation or review has become awkward, and ask for advice first. Judge the proposed split by whether the next change will be easier to understand, not just by how many lines disappear from the original file.