Enables TypeScript-aware file and directory moves within a project by leveraging a persistent tsserver instance to automatically update imports and maintain project integrity.
Click on "Install 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., "@ts-refactor-mcp move src/utils.ts to src/lib/utils.ts and update all imports"
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.
TypeScript-aware file refactoring for AI agents via the Model Context Protocol (MCP).
An MCP server that enables AI coding agents to move TypeScript files while automatically updating all imports. When you move a file in VS Code, TypeScript's language server updates every import automatically. This tool exposes that same capability to AI agents through MCP.
The problem it solves: AI agents can move files, but they break imports. They either miss updates or waste tokens fixing them manually. This server does it correctly in one atomic operation.
Related MCP server: ts-mcp-server
npm install ts-refactor-mcpOr install from source:
git clone https://github.com/schicks/ts-refactor-mcp.git
cd ts-refactor-mcp
npm install
npm run buildAdd to your MCP client configuration (e.g., Claude Desktop):
{
"mcpServers": {
"ts-refactor": {
"command": "npx",
"args": ["ts-refactor-mcp"]
}
}
}Or use the built package:
{
"mcpServers": {
"ts-refactor": {
"command": "node",
"args": ["/path/to/ts-refactor-mcp/dist/index.js"]
}
}
}moveFileMove a TypeScript file and update all imports automatically.
Input:
{
projectRoot: string; // Path to project root (where tsconfig.json is)
oldPath: string; // Current file path
newPath: string; // New file path
dryRun?: boolean; // If true, preview changes without applying
}Output (when applied):
{
applied: true;
filesModified: number;
moved: { from: string; to: string };
durationMs: number;
}Output (dry-run):
{
applied: false;
edits: Array<{
filePath: string;
textEdits: Array<{
start: { line: number; offset: number };
end: { line: number; offset: number };
newText: string;
}>;
}>;
wouldMove: { from: string; to: string };
filesModified: number;
}Example:
// Move a file and update all imports
{
"projectRoot": "/home/user/my-project",
"oldPath": "/home/user/my-project/src/utils/helper.ts",
"newPath": "/home/user/my-project/src/lib/helper.ts",
"dryRun": false
}
// Preview changes first
{
"projectRoot": "/home/user/my-project",
"oldPath": "/home/user/my-project/src/utils/helper.ts",
"newPath": "/home/user/my-project/src/lib/helper.ts",
"dryRun": true
}warmupPre-load a TypeScript project to speed up subsequent operations.
Input:
{
projectRoot: string; // Path to project root (where tsconfig.json is)
}Output:
{
status: 'ready';
durationMs: number;
}Why use this: First operation on a project takes 5-30 seconds while TypeScript loads. Call warmup at session start to pay this cost upfront. Subsequent operations complete in 10-100ms.
Persistent tsserver: Keeps TypeScript's language server running between requests
Atomic operations: All import updates succeed or none do—no partial failures
Uses project's TypeScript: Spawns tsserver from your node_modules/typescript
Battle-tested: Uses the same getEditsForFileRename API that VS Code uses
Agent calls moveFile
↓
MCP Server
↓
tsserver.getEditsForFileRename() ← Same API VS Code uses
↓
Apply all edits atomically
↓
Move the file
↓
Return successInitial warmup: 5-30 seconds (large projects)
Subsequent moves: 10-100ms
Memory: Persistent tsserver process (~100-500MB depending on project size)
Node.js >= 18.0.0
TypeScript project with tsconfig.json
TypeScript installed in project's node_modules
git clone https://github.com/schicks/ts-refactor-mcp.git
cd ts-refactor-mcp
npm installnpm test # Run all tests
npm run test:watch # Watch modenpm run build # Compile TypeScript
npm run watch # Watch modesrc/
├── tsserver-client/ # Wrapper around tsserver process
├── edit-applier/ # Applies text edits to filesystem
├── mcp-server/ # MCP protocol implementation
└── types/ # Shared TypeScript types
__tests__/
├── tsserver-client/ # Unit tests for tsserver wrapper
├── edit-applier/ # Unit tests for edit applier
├── mcp-server/ # Integration tests for MCP server
├── acceptance.test.ts # End-to-end acceptance test
└── fixtures/ # Test fixturesWe keep tsserver running between requests. First request pays startup cost (5-30s), subsequent requests are fast (10-100ms). Without persistence, every move would reload the entire project.
All edits and the file move happen atomically. Either everything succeeds or nothing changes. This prevents broken intermediate states.
We use the TypeScript version from your project's node_modules, not a global install. This ensures refactoring behavior matches your project's TypeScript version.
When files change outside our server, we don't track it. If tsserver gets out of sync, call warmup again. Trying to maintain perfect sync is complex and unnecessary—tsserver handles file watching internally.
TypeScript only: Requires tsconfig.json (JavaScript-only projects not supported)
One project at a time: One tsserver per tsconfig
No directory moves: Currently only supports single file moves
Cold starts: MCP server restart requires project warmup again
Potential future additions (not currently implemented):
moveDirectory: Move entire directories with all files
renameSymbol: Rename a function/class across files
extractToFile: Move a function to a new file
Multi-root workspace support
JavaScript-only project support
Pull requests welcome! Please:
Add tests for new functionality
Ensure all tests pass (npm test)
Follow existing code style
Update documentation
MIT
Built using:
@modelcontextprotocol/sdk - MCP protocol implementation
TypeScript's tsserver - Language service API
Move a TypeScript file and update all imports automatically. Applies edits atomically.
| Name | Required | Description | Default |
|---|---|---|---|
| projectRoot | Yes | Absolute path to the project root (where tsconfig.json is) | |
| oldPath | Yes | Absolute path to the file to move | |
| newPath | Yes | Absolute path to the new location | |
| dryRun | No | If true, return the edit plan without applying changes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavior: automatic import updates and atomic application. However, with no annotations, it lacks details on potential side effects (e.g., whether destination is overwritten, error handling for non-existent files).
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 sentences, no fluff. Front-loaded with purpose, then key behavior. Every word earns its place.
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?
Adequate for a simple move tool, but lacks details on error conditions, overwrite behavior, and return value (no output schema). Could be more complete for reliable agent invocation.
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 covers all 4 parameters with descriptions. The description adds no extra semantics beyond restating the tool's purpose; baseline 3 is appropriate given full schema coverage.
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?
Description clearly states it moves a TypeScript file and automatically updates imports. The verb 'move' and resource 'TypeScript file' are specific, and the sibling tool 'warmup' is unrelated, so no confusion.
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 explicit guidance on when to use this tool versus alternatives. It implies it's for TypeScript files in a project, but does not mention prerequisites, caveats, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-load a TypeScript project to speed up subsequent operations
| Name | Required | Description | Default |
|---|---|---|---|
| projectRoot | Yes | Absolute path to the project root (where tsconfig.json is) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It only mentions speeding up subsequent operations but doesn't state side effects, idempotency, error conditions, or whether it modifies the project. This lack of detail is a significant gap for a tool that likely has internal state.
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 concise sentence that effectively communicates the core purpose without superfluous 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?
Despite the tool's simplicity (one parameter, no output schema), the description lacks details about what 'subsequent operations' are affected, the effect of multiple calls, and the tool's internal behavior. It feels incomplete for an agent to use confidently.
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 100%, and the parameter 'projectRoot' is already described as 'Absolute path to the project root (where tsconfig.json is)'. The tool description adds no further semantics, so baseline score of 3 is appropriate.
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's purpose: 'Pre-load a TypeScript project to speed up subsequent operations'. The verb 'Pre-load' and resource 'TypeScript project' are specific, and it distinguishes this from its sibling tool 'moveFile'.
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 the tool is for performance optimization but provides no explicit guidance on when to use it, prerequisites (like the project must exist), or how it relates to other operations. No alternative tools are discussed.
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. Dates show when Glama detected each change.
moveFilewarmupThe two tools have clearly distinct purposes: moveFile handles file relocation with import updates, while warmup optimizes performance by pre-loading projects. There is no ambiguity or overlap.
Both tool names use camelCase and are concise. Although moveFile follows a verb_noun pattern and warmup is a single word, they are consistent in style and easily distinguishable.
With 2 tools, the count is slightly below the typical 3-15 range, but for a focused refactoring server offering essential file-moving and caching capabilities, it is reasonable and well-scoped.
While the tools are well-implemented, the server lacks common refactoring operations like symbol renaming, extraction, or type transformations, leaving significant gaps for a refactoring toolset.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
An MCP server that gives your AI access to the source code and docs of all public github repos
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/schicks/ts-refactor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
