The MCP ts-morph Refactoring Tools server enables automated refactoring and code analysis for TypeScript and JavaScript projects using the ts-morph library. It provides:
Rename Symbols: Rename variables, functions, and classes while automatically updating all references across the project
Rename Files/Folders: Rename filesystem entries and update all related import/export paths
Find References: Locate all usage sites and the definition of a specific symbol within the project
Remove Path Aliases: Convert path aliases (e.g., @/components) to relative paths in import/export statements
Move Symbols: Relocate symbols between files while maintaining references
Dry Run: Preview changes before applying them
Test Connection: Verify connection to the MCP server is working correctly
The server integrates with editor extensions like Cursor for seamless refactoring workflows.
Enables AST-based code refactoring operations for JavaScript files including symbol renaming, file/folder renaming with automatic import path updates, and reference finding.
Provides a Node.js-based refactoring server that can be integrated with editor extensions like Cursor to perform code transformations.
Provides refactoring capabilities for TypeScript codebases including symbol renaming, finding references, and updating import paths, all performed using AST-based analysis.
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., "@MCP ts-morph Refactoring Tools rename the function 'calculateTotal' to 'computeTotal' in src/utils/math.ts"
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.
The MCP server leverages ts-morph to provide refactoring operations for TypeScript and JavaScript codebases, and works with editor extensions such as Cursor to allow AST-based (Abstract Syntax Tree)-based symbol renaming, file/folder renaming, find references, and more.
Related MCP server: TypeScript Rename Helper
The MCP server provides the following refactoring features, each of which uses ts-morph to analyze the AST and make changes while maintaining consistency across the project:
rename_symbol_by_tsmorph )What it does : Globally rename a symbol (function, variable, class, interface, etc.) at a specific position in a specified file across the entire project.
Use case : You want to change the name of a function or variable, but there are many references to it and it would be difficult to change it manually.
Required information : tsconfig.json path of the project, path of the target file, position of the symbol (line and column), current symbol name, new symbol name
rename_filesystem_entry_by_tsmorph )Feature : Renames multiple specified files and/or folders and automatically updates the paths in all import / export statements in the project.
Use cases : When you change file structure and want to modify import paths accordingly. When you want to rename/move multiple files/folders at once.
Required information : project's tsconfig.json path, array of rename operations ( renames: { oldPath: string, newPath: string }[] ).
remarks :
References are primarily resolved using symbol resolution.
References that contain path aliases (such as @/ ) will be updated but converted to relative paths .
Imports that reference a directory index file (e.g. ../components ) are updated to an explicit file path (e.g. ../components/index.tsx ) .
It also performs a path collision check (duplicates in existing paths and within the operation) before the rename operation.
Note (Execution time): When working with many files and folders at once, or for very large projects, parsing and updating references can take some time.
NOTE (known limitation): Currently, references to default exports of the form export default Identifier; may not be updated correctly.
find_references_by_tsmorph )What it does : Finds and lists the definition of a symbol at a particular location in a specified file, as well as all its references throughout the project.
Use case : You want to understand where a function or variable is used. You want to investigate the impact of a refactoring.
Required information : project's tsconfig.json path, target file path, symbol position (line, column).
remove_path_alias_by_tsmorph )Function : Replaces path aliases (such as @/components ) in import / export statements in the specified file or directory with relative paths (such as ../../components ).
Use case : You want to make your project more portable or to conform to specific coding standards.
Required information : tsconfig.json path of the project, path of the file or directory to process.
move_symbol_to_file_by_tsmorph )What it does : Moves a specified symbol (function, variable, class, interface, type alias, enum) from the current file to another specified file, automatically updating references (including import/export paths) throughout the project along with the move.
Use case : You want to extract certain functionality into a separate file to reorganize your code.
Required information : tsconfig.json path of the project, source file path, destination file path, name of the symbol to move, and optionally a symbol kind ( declarationKindString ) to disambiguate symbols with the same name.
NOTE : A symbol's internal dependencies (other declarations used only within that symbol) are moved along with it. Dependencies referenced by other symbols remaining in the source file will remain in the source and will be added as export (if necessary) and imported in the destination file.
Note : symbols that are exported export default cannot be moved with this tool.
Add the following settings to mcp.json . By using the npx command, the latest version installed will be automatically used.
{
"mcpServers": {
"mcp-tsmorph-refactor": { // 任意のサーバー名
"command": "npx",
"args": ["-y", "@sirosuzume/mcp-tsmorph-refactor"],
"env": {} // 必要に応じてロギング設定などを追加
}
}
}If you want to run the server locally from source code, you need to build it first.
# 依存関係のインストール (初回のみ)
pnpm install
# TypeScript コードのビルド
pnpm run buildAfter building, you can run it directly in node by setting the following in mcp.json :
{
"mcpServers": {
"mcp-tsmorph-refactor-dev": { // 開発用など、別の名前を推奨
"command": "node",
// プロジェクトルートからの相対パスまたは絶対パス
"args": ["/path/to/your/local/repo/dist/index.js"],
"env": {
// 開発時のデバッグログ設定など
"LOG_LEVEL": "debug"
}
}
}
}The output level and destination of the server operation log can be controlled by the following environment variables. Set them in env block of mcp.json .
LOG_LEVEL : Sets the log verbosity.
Available levels: fatal , error , warn , info (default), debug , trace , silent
Example: "LOG_LEVEL": "debug"
LOG_OUTPUT : Specifies the log output destination.
console (default): Logs to standard output. If you are in a development environment ( NODE_ENV !== 'production' ) and have pino-pretty installed, the output will be formatted in a pretty way.
file : Outputs the log to the specified file. Set this to avoid impacting MCP clients.
Example: "LOG_OUTPUT": "file"
LOG_FILE_PATH : If LOG_OUTPUT is set to file , this specifies the absolute path of the log file.
Default: [プロジェクトルート]/app.log
Example: "LOG_FILE_PATH": "/var/log/mcp-tsmorph.log"
Example config (in mcp.json ):
// ... (mcp.json の他の設定)
"env": {
"LOG_LEVEL": "debug", // デバッグレベルのログを
"LOG_OUTPUT": "file", // ファイルに出力
"LOG_FILE_PATH": "/Users/yourname/logs/mcp-tsmorph.log" // ログファイルのパス指定
}
// ...Node.js (for version, see .node-version or volta field in package.json )
pnpm (see packageManager field in package.json for version)
Clone the repository and install the dependencies:
git clone https://github.com/sirosuzume/mcp-tsmorph-refactor.git
cd mcp-tsmorph-refactor
pnpm installCompiles TypeScript code into JavaScript.
pnpm buildThe build artifacts are output to dist directory.
Run the unit tests.
pnpm testIt statically analyzes and formats your code.
# Lintチェック
pnpm lint
# Lint修正
pnpm lint:fix
# フォーマット
pnpm formatIf you want to check the startup sequence, standard input/output, and error output of the MCP server in detail during development, you can use mcp_launcher.js , which is located in the scripts directory of the project.
This wrapper script launches the original MCP server process ( npx -y @sirosuzume/mcp-tsmorph-refactor ) as a child process and logs the launch information and output to .logs/mcp_launcher.log file in the project root.
How to use:
In the mcp.json file, change mcp-tsmorph-refactor server configuration as follows:
Set command to "node" .
In args , specify the path to scripts/mcp_launcher.js (for example, ["path/to/your_project_root/scripts/mcp_launcher.js"] ). You can also use a path relative to the project root ( ["scripts/mcp_launcher.js"] ).
Example configuration ( mcp.json ):
{
"mcpServers": {
"mcp-tsmorph-refactor": {
"command": "node",
// scripts/mcp_launcher.js へのパス (プロジェクトルートからの相対パス or 絶対パス)
"args": ["path/to/your_project_root/scripts/mcp_launcher.js"],
"env": {
// 元の環境変数設定はそのまま活かせます
// 例:
// "LOG_LEVEL": "trace",
// "LOG_OUTPUT": "file",
// "LOG_FILE_PATH": ".logs/mcp-ts-morph.log"
}
}
// ... 他のサーバー設定 ...
}
}Restart or reload the MCP client (e.g. Cursor).
Check that the logs are output to .logs/mcp_launcher.log in your project root, and also to the MCP server's own log if configured (e.g. .logs/mcp-ts-morph.log ).
Using this wrapper can help you diagnose why your MCP server is not starting as expected.
This package will be automatically published to npm via a GitHub Actions workflow ( .github/workflows/release.yml ).
NPM token: Make sure you have an npm access token with public permissions set in your repository's Actions secrets ( Settings > Secrets and variables > Actions ) with the name NPM_TOKEN .
Update your version: Before publishing, update the version field in package.json according to Semantic Versioning (SemVer).
To trigger the release workflow, use a Git tag push.
How to: Push a Git tag (recommended for releases)
Intended use: Regular version releases (major, minor, patch). This is the recommended standard release process since it provides a clear correspondence between Git history and versions.
Update version: Change version in package.json (e.g. 0.3.0 ).
Commit & Push: Commit the changes to package.json and push them to the main branch.
Create tag & push: Creates a Git tag (with v prefix) that matches the version and pushes it.
git tag v0.3.0
git push origin v0.3.0Automation: Pushing a tag triggers the Release Package workflow, which builds, tests, and publishes the package to npm.
Verify: Check the status of your workflow in the Actions tab and verify your package on npmjs.com.
Version consistency: When triggering on a tag push, the tag name (e.g. v0.3.0 ) must exactly match version (e.g. 0.3.0 ) in package.json , or the workflow will fail.
Pre-check: Although your CI workflow includes build and test steps, we recommend running pnpm run build and pnpm run test locally before updating your version to catch potential issues early.
This project is released under the MIT license, see the LICENSE file for details.
[ts-morph] Add, remove, or reorder parameters of a function/method/arrow-function and propagate the matching argument changes to every call site in the project.
Adding a required parameter to a function with many callers (LLM single-edit reliably misses some — this tool guarantees every call site is updated via the type checker).
Removing or reordering parameters of a function that is imported, re-exported, or accessed through a method chain.
Inserting a context-like first parameter (ctx, logger, etc.) into existing helpers.
Renaming a parameter — use rename_symbol_by_tsmorph on the parameter identifier instead.
Changing only the parameter's type annotation without changing arity — edit the source file directly.
Moving the function to another file — use move_symbol_to_file_by_tsmorph.
position must point at the function's name identifier (1-based line/column). For const foo = () => {}, point at foo; for class C { foo() {} }, point at foo.
functionName must match the identifier text at that position (sanity check).
All paths (tsconfigPath, targetFilePath) MUST be absolute.
Spread arguments (fn(...args)) at call sites cause the operation to fail when a change would modify arguments. Refactor those callers manually first, or limit changes to trailing optional/defaulted parameters with no argumentForCallers.
Operations apply sequentially; later operations see the parameter list produced by earlier ones.
add: Inserts a parameter at index (default: end). If argumentForCallers is provided, that exact text is inserted at the same index in every call site. If omitted, callers are left untouched (use only for trailing optional / defaulted parameters).
remove: Removes the parameter at index. Each call site with at least that many arguments drops the corresponding one. Calls passing fewer arguments are left untouched.
reorder: Rebuilds the parameter list and every call site according to newOrder. Fails if any call site does not pass exactly that many arguments (no way to safely reorder omitted optionals).
Run with dryRun: true first when the function has many callers to preview the impacted files.
For adding multiple parameters at once, list multiple add operations; their index values refer to the parameter list after prior operations in the same call have been applied.
Returns the list of modified (or to-be-modified, in dryRun) file paths, plus status and processing time.
| Name | Required | Description | Default |
|---|---|---|---|
| tsconfigPath | Yes | Path to the project's tsconfig.json file. | |
| targetFilePath | Yes | Path to the file containing the function declaration. | |
| position | Yes | Exact position of the function name identifier. | |
| functionName | Yes | Name of the function/method at that position. | |
| changes | Yes | Ordered list of signature operations to apply. See the tool description for semantics. | |
| dryRun | No | If true, only show intended changes without modifying files. |
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 extensively discloses behavioral traits: critical constraints (position, functionName, absolute paths, spread arguments, sequential operations), operation semantics for add/remove/reorder, and tips (dryRun). It also explains the result format. This is thorough and leaves no ambiguity about the tool's behavior.
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 well-organized with clear sections: purpose, usage guidelines, critical constraints, operation semantics, tips, and result. It is front-loaded with the core purpose and each section earns its place. There is no redundant information, and the length is appropriate for the complexity.
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's complexity (6 parameters, nested objects, no output schema, no annotations), the description is very complete. It covers all necessary aspects: when to use, constraints, operation semantics, result format, and even provides tips for previewing changes. It does not need an output schema as the result is described as a list of modified files. The description fully equips an AI agent to use the 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?
Schema description coverage is 100%, but the description adds significant meaning beyond the schema. It explains how `index` works in sequential operations, the nuance of `argumentForCallers`, and the semantics of each operation kind (add, remove, reorder). It also clarifies the `newOrder` array format for reorder. This added context is valuable for correct usage.
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: 'Add, remove, or reorder parameters of a function/method/arrow-function and propagate the matching argument changes to every call site in the project.' It uses a specific verb ('add, remove, reorder') and resource (function parameters), and distinguishes itself from sibling tools like rename_symbol_by_tsmorph and move_symbol_to_file_by_tsmorph in the 'When NOT to use' section.
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 includes explicit 'When to use' and 'When NOT to use' sections, providing clear context and alternatives. It specifies when to use this tool (e.g., adding required parameters with many callers, removing/reordering parameters) and when not to (e.g., renaming parameters, changing type annotations, moving the function). It also names sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[ts-morph] Locate the definition AND every reference of a symbol at a given position, project-wide. Read-only.
Assessing the blast radius of a planned refactor before changing anything.
Answering "who calls this function?" / "where is this type used?" precisely.
Prefer this over grep for identifier lookups: grep matches unrelated same-name tokens (different scopes, comments, strings), while this tool uses the type checker to return only true references.
You just want a free-text search (comments, strings, doc files) -> use grep.
You already plan to rename -> skip straight to rename_symbol_by_tsmorph (it computes the same set internally and supports dryRun).
position must land on the symbol identifier itself (1-based line/column, as shown by editors). A position on whitespace or another token will fail to resolve.
All paths (tsconfigPath, targetFilePath) MUST be absolute.
Returns the definition (file path, line, column, source line) when found, followed by a numbered list of references with the same fields.
| Name | Required | Description | Default |
|---|---|---|---|
| tsconfigPath | Yes | Absolute path to the project's tsconfig.json file. | |
| targetFilePath | Yes | Absolute path to the file containing the symbol. | |
| position | Yes | The exact position of the symbol. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully covers behavior: read-only, constraints on position (must land on symbol identifier), absolute paths required, and result format (definition + references).
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?
Well-structured with sections, bullet points, code blocks. Front-loaded purpose, every sentence adds value, no fluff.
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 no output schema, description explains result format (definition and numbered references with file path, line, column, source line). Covers constraints, use cases, and sibling differentiation. Very complete.
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 100% of parameters with descriptions, and description adds critical context: paths must be absolute, position must be on the symbol identifier, and 1-based line/column. Adds significant value beyond 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 locates the definition AND every reference of a symbol, project-wide, and is read-only. It distinguishes from siblings like rename_symbol_by_tsmorph and grep.
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?
Explicit 'When to use' and 'When NOT to use' sections provide clear guidance, including specific examples like blast radius assessment and alternatives such as grep for free-text search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[ts-morph] List exports that have no references outside their declaring file across the project. Read-only.
Hunting for dead code candidates after a refactor or migration.
Auditing a module's surface area: which exports does nobody actually consume?
Pre-deletion safety check before manually removing exports — combine with find_references_by_tsmorph to double-confirm.
You want a single symbol's references — use find_references_by_tsmorph.
Single-file unused locals — tsc --noUnusedLocals is faster.
Reports:
export function/class/const/let/var/enum/interface/type ... (inline export keyword)
export default function/class ... and export default <Identifier>
export = <Identifier> (CommonJS)
For each candidate identifier, findReferencesAsNodes() is run and the following references are excluded before deciding "unused":
References inside the SAME file as the declaration (internal use does not count).
References inside any ExportDeclaration (pure re-export sites like export { x } from "./y" or export *). This means a symbol re-exported only via a barrel — with nothing actually consuming the barrel — IS reported as unused.
References in node_modules.
If 0 references remain, the export is reported.
Static analysis cannot see:
Dynamic require() / import() resolved from runtime strings.
File-system / convention based routing (Next.js page.tsx, Remix routes, etc.). Pass these as entryPoints.
Symbols looked up via reflection or string keys.
Pure local re-exports (export { x } without from) where x is declared by a separate const x = ... in the same file — this form is not enumerated.
Mixed function + namespace declarations may be partially missed.
Workspace packages that publish built output: in a monorepo, when a scanned package's package.json entry points (exports / main / module / types) resolve outside the scanned sources (e.g. "exports": { ".": "./dist/index.js" }), imports from OTHER workspace packages resolve to the built files (or node_modules) instead of the scanned sources. Every export of such a package is then reported unused even when it IS consumed — a systematic false positive. The tool detects this shape and prepends a ⚠ package-level warning to the result; treat all candidates from a warned package as low confidence. Workaround: point that package's exports at source files for analysis, or verify each candidate with find_references_by_tsmorph / textHits.
export default <Identifier> / export = <Identifier> (shown with the [default] tag) are prone to FALSE POSITIVES: findReferencesAsNodes runs on the local identifier and often fails to connect to import Foo from "./mod" default-import sites. A default export reported here with textHits well above 0 is almost certainly actually used. Treat [default] candidates as low confidence and always confirm with find_references_by_tsmorph.
Always verify a candidate with find_references_by_tsmorph before deletion.
tsconfigPath: absolute path to tsconfig.json.
entryPoints: list of absolute file paths whose exports should be skipped (treat as public API). Reference sites IN these files still count as "used" automatically.
excludeFilePatterns: substrings; any file whose absolute path includes() a pattern is not scanned. Use this for test files (e.g. ".test."), generated dirs, etc.
maxResults: cap on number of reported entries. Default 100. When reached, scanning stops and truncated becomes true — narrow scope with the filters above and retry.
responseFormat)"list" (default): one line per candidate (format below).
"summary": aggregate counts for the WHOLE project — total, delete-safety split (deletable vs unexport-only), default-export count, and breakdowns by kind and by directory. On large repos the per-line list easily blows past the response size limit, so start with "summary" to see where dead code clusters, then narrow with entryPoints / excludeFilePatterns and switch to "list" for exact locations. (summary scans the whole project regardless of maxResults.)
A bullet list of candidates with file:line:column, symbol name, declaration kind, a [default] tag for default exports, textHits=N, and sameFileRefs=N.
sameFileRefs — decides delete vs. unexport (read this first)Every reported export is, by definition, unreferenced OUTSIDE its declaring file. sameFileRefs tells you whether it is still used INSIDE that file (declaration itself and re-export sites excluded), which determines the safe action:
sameFileRefs=0: not used anywhere, including its own file → truly dead, safe to delete the whole declaration (combine with textHits=0 for highest confidence).
sameFileRefs=1+: used within its own file → only the export keyword is unnecessary. Remove export, but KEEP the declaration — deleting it breaks the in-file references.
Deleting every reported declaration blindly will break the build: the majority are often sameFileRefs=1+ (over-exported but internally used).
textHits — text-occurrence triage hinttextHits is the number of word-boundary occurrences of the export's name in OTHER source files (declaring file excluded — so it says nothing about same-file usage; use sameFileRefs for that):
textHits=0: no OTHER file mentions the name. Does NOT by itself mean deletable — still check sameFileRefs.
textHits=1+: the name appears as a string literal, JSX tag, dynamic import().then(m => m.X), or comment. Verify with find_references_by_tsmorph before deleting. Short names (e.g. a, id) match incidentally — discount accordingly.
When a package that produced candidates publishes built output (see Known limitations), a ⚠ warnings block is prepended to the result (both list and summary modes) naming the package, its out-of-scan entry points, and how many candidates are affected. Those candidates are likely false positives.
Trailing line reports Scanned files: N and Truncated: bool.
| Name | Required | Description | Default |
|---|---|---|---|
| tsconfigPath | Yes | Absolute path to the project's tsconfig.json. | |
| entryPoints | No | Absolute file paths to treat as public API. Exports declared here are skipped. | |
| excludeFilePatterns | No | Substrings; files whose absolute path includes any of these are not scanned. | |
| maxResults | No | Cap on reported entries (list mode). Default 100. Ignored intent in "summary" mode, which scans the whole project. | |
| responseFormat | No | "list" (default): one line per candidate. "summary": aggregate counts (delete-safety / kind / directory) for the WHOLE project — use this first on large repos to avoid huge output, then narrow with entryPoints/excludeFilePatterns and switch to "list". | list |
| expandNamespaceImports | No | Default true. Inject synthetic named imports into files containing `import * as ns from "./mod"` so that exports of the target module register as 'used' even when consumed only via `{ ...ns }` spread or other escaping patterns. Set to false if you want raw findReferences semantics. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: read-only, detection algorithm, excluded reference types, known limitations (dynamic imports, routing conventions, monorepo false positives), and detailed guidance on interpreting results (`sameFileRefs`, `textHits`). It even warns about default export false positives and package-level warnings.
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 quite long but well-structured with headings, bullet points, and code formatting. Each section serves a purpose—core statement, usage guidelines, algorithm, limitations, options, output format, and result interpretation. While no sentence seems wasted, it could be slightly trimmed without losing value. The front-loading of purpose and usage is effective.
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's complexity (6 parameters, no output schema, no annotations), the description is remarkably complete. It covers not only how to invoke the tool but also how to interpret results (`sameFileRefs`, `textHits`), common pitfalls (default exports, monorepo false positives), and strategies for narrowing scope. The agent can confidently use this tool based solely on the description.
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 the input schema already provides parameter descriptions (100% coverage), the description adds significant practical context: how `entryPoints` affect results, when to use `responseFormat='summary'` for large repos, how `maxResults` interacts with summary mode, and the purpose of `expandNamespaceImports`. This guidance helps the agent use parameters effectively.
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 opens with a clear statement: 'List exports that have no references outside their declaring file across the project. Read-only.' It explicitly distinguishes from the sibling tool `find_references_by_tsmorph` in the 'When NOT to use' section, making the purpose unambiguous.
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 includes dedicated 'When to use' and 'When NOT to use' sections, providing concrete scenarios and naming alternative tools (e.g., `find_references_by_tsmorph`, `tsc --noUnusedLocals`). This gives the agent clear context for selecting the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[ts-morph] Return the TypeChecker-inferred type at a specific position in a TypeScript/JavaScript file, plus the symbol and its declaration location.
Quickly verifying "what is the actual inferred type of this variable / expression / function?" without spawning tsc or running a full type check.
Cheaper than Read-ing the declaration file when all you need is the type signature.
Before refactoring, to confirm what a value's actual shape is (especially helpful when types are inferred through multiple generics).
Bulk type analysis across many positions — call tsc directly instead.
Listing every reference of a symbol — use find_references_by_tsmorph.
position is 1-based (line/column), matching what editors display.
All paths (tsconfigPath, targetFilePath) MUST be absolute.
For function/method identifiers (where ALL declarations are signature-bearing) the type is rendered as a call-style (arg: T) => R text taken directly from the declaration source, preserving rest ..., optional ?, default values, and destructuring patterns. Overloads are joined with & and the implementation signature is hidden.
For function/namespace merges or other mixed symbols (function with extra properties), the raw TypeChecker text (e.g. typeof fn) is returned to avoid silently dropping the property side of the type.
For imported symbols the resolved (aliased) symbol's declaration location is reported, including barrel re-export chains (export * from, export { x } from) which are recursively unwrapped.
For built-in or third-party symbols (e.g. console, Promise), declaration may point inside node_modules lib.d.ts files.
type: the inferred type text.
nodeKind / nodeText: what the position landed on (Identifier, StringLiteral, etc., and the source text — truncated to 80 chars).
symbol (optional): the resolved symbol's name and the kind of its first declaration.
declaration (optional): file path + 1-based line/column of the first declaration.
Pointing at whitespace or a comment line returns a SourceFile/EndOfFileToken node and the file-level inferred type (e.g. typeof import("...")) — this is NOT an error but is usually not what you want. Check nodeKind in the response and re-target to the identifier.
For function/namespace merges where the type returns as typeof fn, inspect the declaration location to discover the merged namespace members.
| Name | Required | Description | Default |
|---|---|---|---|
| tsconfigPath | Yes | Path to the project's tsconfig.json file. | |
| targetFilePath | Yes | Path to the file containing the position to inspect. | |
| position | Yes | Exact position to inspect. |
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 discloses critical constraints: 1-based position, absolute paths, handling of function/method identifiers (overloads, merged symbols), imports, and built-ins. It also describes result fields and potential edge cases (whitespace/comments). No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections, bullet points, and front-loaded core purpose. Every sentence adds value, covering constraints, usage, and results efficiently without redundancy.
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 complexity of the tool, no output schema, and no annotations, the description is remarkably complete. It explains all result fields, error states (whitespace/comments), and provides actionable tips. Covers all important aspects for an AI agent to use it 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 coverage is 100%, providing a baseline of 3. The description adds value beyond the schema by explaining that position is 1-based, paths must be absolute, and by providing context for how parameters are used (e.g., how position maps to node types). This extra guidance justifies a 4.
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: 'Return the TypeChecker-inferred type at a specific position in a TypeScript/JavaScript file, plus the symbol and its declaration location.' It uses specific verbs and resources, and distinguishes from siblings by mentioning cheaper alternative to tsc and not for bulk analysis.
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 includes explicit 'When to use' and 'When NOT to use' sections, providing clear guidance on appropriate contexts (quick type checking, before refactoring) and exclusions (bulk analysis, listing references). It also names alternatives like tsc and find_references_by_tsmorph.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[ts-morph] Move one top-level symbol (function, variable, class, interface, type, enum) from one file to another, carrying its internal-only dependencies and rewriting all imports/exports across the project.
Splitting a large file: move related symbols to a new file one by one.
Relocating a helper from a generic utils.ts to a feature-specific module.
Prefer this over manual cut-and-paste + import fixing. Manual moves frequently miss re-exports, leave stale imports, or fail to add the new export -- this tool handles all of that via the type checker.
Renaming the file (without moving a single symbol out of it) -> rename_filesystem_entry_by_tsmorph.
Renaming a symbol in place -> rename_symbol_by_tsmorph.
The symbol you want to move is a export default -> NOT SUPPORTED, refactor it to a named export first.
ONE top-level symbol per call. To move N symbols, invoke the tool N times.
Default exports CANNOT be moved. Convert them to named exports beforehand.
If multiple top-level declarations share the same name (e.g., function + namespace), pass declarationKindString (e.g., "FunctionDeclaration", "VariableStatement") to disambiguate.
Internal dependency rules:
Dependencies used ONLY by the moved symbol travel with it.
Dependencies also used by other symbols in the source file stay put, gain export if missing, and are imported back into the destination file.
All paths (tsconfigPath, originalFilePath, targetFilePath) MUST be absolute.
targetFilePath may point to a non-existent file; it will be created.
Run with dryRun: true first when the source file has many co-dependencies to confirm what gets pulled along.
Returns the list of modified (or to-be-modified, in dryRun) file paths, plus status and processing time.
| Name | Required | Description | Default |
|---|---|---|---|
| tsconfigPath | Yes | Absolute path to the project's tsconfig.json file. Essential for ts-morph. | |
| originalFilePath | Yes | Absolute path to the file containing the symbol to move. | |
| targetFilePath | Yes | Absolute path to the destination file. Can be an existing file; if the path does not exist, a new file will be created. | |
| symbolToMove | Yes | The name of the single top-level symbol you want to move in this execution. | |
| declarationKindString | No | Optional. The kind of the declaration. Providing this helps resolve ambiguity if multiple symbols share the same name. | |
| dryRun | No | If true, only show intended changes without modifying files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses critical behaviors: internal dependency rules (carries only internal deps, leaves shared ones with export), path requirements (must be absolute), creation of non-existent target file, and dry-run support. Covers all significant behavioral traits.
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?
Description is well-structured with sections, bullet points, and clear headings. Immediately states core functionality, then provides usage guidelines, constraints, tips, and result. Every sentence earns its place; no redundancy.
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 no output schema and 6 parameters, the description thoroughly explains the tool's behavior, constraints, and expected result (list of modified files). Includes a tip to use dryRun first. Everything an agent needs to invoke correctly is present.
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%, so baseline is 3. The description adds some extra context (e.g., 'Essential for ts-morph' for tsconfigPath, 'disambiguate' for declarationKindString) but mostly restates schema, providing moderate added value.
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: moving a top-level symbol between files while rewriting imports/exports. It distinguishes from sibling tools by naming them explicitly (e.g., rename_filesystem_entry_by_tsmorph, rename_symbol_by_tsmorph) and noting when not to use this tool.
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?
Includes explicit 'When to use' and 'When NOT to use' sections with clear context and alternatives, such as renaming a file or renaming a symbol. Also warns about unsupported default exports, guiding the agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[ts-morph] Convert path-alias imports/exports (e.g., @/components/Button) to relative paths (../../components/Button) within a target file or directory.
Standardizing on relative paths for a subset of the codebase.
Preparing for a large rename_filesystem_entry_by_tsmorph run when you want to control alias rewriting explicitly (note: rename_filesystem_entry_by_tsmorph already rewrites aliases to relative paths automatically; run this tool first only if you want the conversion to be a separate, reviewable commit).
Prefer this over manual find/replace -- relative path computation is error-prone across nested directories.
The project has no paths mapping in tsconfig.json (this tool has nothing to do).
You want to ADD aliases or change one alias to another (not supported).
Aliases are read from the paths option of the project's tsconfig.json. Only those aliases are resolved.
targetPath may be a single file OR a directory. Directory targets process every .ts/.tsx file under it.
All paths (tsconfigPath, targetPath) MUST be absolute.
Run with dryRun: true first when applying to a directory, to confirm the scope.
Returns the list of modified (or to-be-modified, in dryRun) file paths, plus status and processing time.
| Name | Required | Description | Default |
|---|---|---|---|
| tsconfigPath | Yes | Absolute path to the project's tsconfig.json file. | |
| targetPath | Yes | Absolute path to the target file or directory. | |
| dryRun | No | If true, only show intended changes without modifying files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: aliases from tsconfig, targetPath as file or directory, requirement for absolute paths, dryRun behavior, and result format. It clearly indicates it modifies files (or shows intended changes). Minor deduction for not mentioning error handling or idempotency.
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 well-structured with clear sections, front-loaded with the main action, and every sentence provides useful information. It is concise yet comprehensive.
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 no output schema and 3 parameters, the description covers key aspects: data source (tsconfig), scope (file or directory), constraints (absolute paths), tips (dryRun), and result format. Slightly incomplete regarding error cases or behavior when no aliases found, but sufficient for typical 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 description coverage is 100%, so baseline is 3. The description adds context (e.g., tsconfigPath is the project's tsconfig, paths must be absolute) but does not significantly increase meaning beyond the schema's own descriptions.
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 'Convert path-alias imports/exports to relative paths within a target file or directory', using specific verb and resource. It distinguishes from sibling tools by noting that rename_filesystem_entry_by_tsmorph already does this automatically.
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 includes explicit 'When to use' and 'When NOT to use' sections, providing clear guidance on when to choose this tool over alternatives like rename_filesystem_entry_by_tsmorph, and when not to use it (e.g., no paths mapping, wanting to add aliases).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[ts-morph] Rename or move one or more TypeScript/JavaScript files and/or folders, and automatically rewrite every import/export path that references them.
Renaming or moving any .ts/.tsx/.js/.jsx file or directory (single or batch).
Prefer this over mv + manual import fixing. This tool resolves references via the type checker, so it handles relative paths, path aliases (@/), and barrel imports (from '.', from '..') that grep cannot reliably find.
Use batch mode (multiple entries in renames) when reorganizing several files at once -- a single AST pass is much faster than running the tool repeatedly.
Renaming a symbol inside a file -> rename_symbol_by_tsmorph.
Moving a single symbol (not the whole file) to another file -> move_symbol_to_file_by_tsmorph.
Path aliases in updated imports are REWRITTEN AS RELATIVE PATHS (e.g., @/foo -> ../foo). If you want to keep aliases, run remove_path_alias_by_tsmorph separately beforehand, or accept the conversion.
Barrel imports like import X from '../components' are rewritten to point at the resolved index file (e.g., '../components/index.tsx').
Default exports declared via a bare identifier (export default Foo;) may not be updated correctly. Default function/class declarations (export default function foo() {}) are handled.
All paths (tsconfigPath, oldPath, newPath) MUST be absolute.
The tool refuses to run on path conflicts (target already exists, duplicate destinations).
Run with dryRun: true first for any non-trivial rename to inspect the affected file list.
timeoutSeconds defaults to 120; raise it for very large projects or huge batch renames.
Returns the list of modified (or to-be-modified, in dryRun) file paths, plus status and processing time. On timeout the operation is cancelled and an error is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| tsconfigPath | Yes | Absolute path to the project's tsconfig.json file. | |
| renames | Yes | An array of rename operations, each with oldPath and newPath. | |
| dryRun | No | If true, only show intended changes without modifying files. | |
| timeoutSeconds | No | Maximum time in seconds allowed for the operation before it times out. Defaults to 120. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses critical behaviors: path aliases rewritten as relative, barrel imports resolved, default exports may not update, paths must be absolute, refuses on conflicts, dryRun and timeout behavior.
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?
Well-structured with clear headings, bullet points, and concise sentences. Every section adds value without redundancy. Length is justified by the tool's complexity.
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 complexity and no output schema, description covers usage, constraints, tips, and result format. Sufficient for an agent to decide when and how to invoke the 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?
Schema coverage is 100%, so each parameter is already documented. Description adds general context (e.g., dryRun tip, timeout default) but does not significantly enhance parameter semantics beyond schema descriptions.
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 renames or moves TypeScript/JavaScript files/folders and automatically rewrites import/export paths. It distinguishes from sibling tools like rename_symbol_by_tsmorph and move_symbol_to_file_by_tsmorph by specifying what each handles.
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?
Explicit 'When to use' and 'When NOT to use' sections with concrete alternatives (e.g., rename_symbol_by_tsmorph for symbol renaming, move_symbol_to_file_by_tsmorph for moving symbols). Also advises batch mode for multiple renames for efficiency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[ts-morph] Type-aware rename of a TypeScript/JavaScript symbol (function, variable, class, type, interface, enum, etc.) across the entire project.
Renaming any symbol that may be imported, re-exported, or referenced in other files.
Prefer this over manual Edit + grep / sed. Identifier-based search misses re-exports, JSX attribute usage, and matches unrelated same-name tokens. This tool resolves references via the type checker, so it is both safer and faster.
Even for a "local-only" symbol, this tool is the correct default: it costs nothing extra and guarantees no missed reference.
Renaming a file or folder (and updating imports to it) -> use rename_filesystem_entry_by_tsmorph.
Moving a symbol to a different file -> use move_symbol_to_file_by_tsmorph.
Just looking up where a symbol is used (no rename) -> use find_references_by_tsmorph.
position must point at the symbol's identifier (1-based line/column, as shown by editors). If the position lands on whitespace or a different token, the rename fails.
symbolName must match the identifier text at that position; it is used as a sanity check.
All paths (tsconfigPath, targetFilePath) MUST be absolute.
Run with dryRun: true first when the change spans many files, to preview the affected file list.
Returns the list of modified (or to-be-modified, in dryRun) file paths, plus status and processing time.
| Name | Required | Description | Default |
|---|---|---|---|
| tsconfigPath | Yes | Path to the project's tsconfig.json file. | |
| targetFilePath | Yes | Path to the file containing the symbol to rename. | |
| position | Yes | The exact position of the symbol to rename. | |
| symbolName | Yes | The current name of the symbol. | |
| newName | Yes | The new name for the symbol. | |
| dryRun | No | If true, only show intended changes without modifying files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as type-aware, safe, and fast, and explains 'Critical constraints' about position and symbolName. However, it does not detail error handling or access permissions.
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 well-structured with clear sections and bullet points. It is concise yet comprehensive, with every sentence adding value. No redundant information.
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's complexity (6 parameters, nested objects, no output schema), the description covers constraints, usage guidance, and result format thoroughly. It even includes a tip to use dryRun first.
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%, but the description adds significant value: it clarifies that position must be 1-based and point to the symbol's identifier, symbolName is a sanity check, paths must be absolute, and dryRun for preview. This goes 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 'Type-aware rename of a TypeScript/JavaScript symbol across the entire project,' using specific verbs and resources. It distinguishes itself from sibling tools like rename_filesystem_entry_by_tsmorph and move_symbol_to_file_by_tsmorph by explicitly listing what it is not for.
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?
Dedicated 'When to use' and 'When NOT to use' sections provide explicit guidance, including when to prefer this over manual grep or sibling tools. It names alternatives (e.g., find_references_by_tsmorph) and clarifies 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.5.2find_unused_exports_by_tsmorph2 fields changedInput schema / properties / maxResults / descriptionPrevious value: -"Cap on reported entries. Default 100."New value: +"Cap on reported entries (list mode). Default 100. Ignored intent in \"summary\" mode, which scans the whole project."Input schema / properties / responseFormatAdded value: +{
+ "default": "list",
+ "description": "\"list\" (default): one line per candidate. \"summary\": aggregate counts (delete-safety / kind / directory) for the WHOLE project — use this first on large repos to avoid huge output, then narrow with entryPoints/excludeFilePatterns and switch to \"list\".",
+ "enum": [
+ "list",
+ "summary"
+ ],
+ "type": "string"
+}v1.5.0find_unused_exports_by_tsmorphget_type_at_position_by_tsmorphv1.3.0change_signature_by_tsmorphv1.1.0find_references_by_tsmorphmove_symbol_to_file_by_tsmorphremove_path_alias_by_tsmorphrename_filesystem_entry_by_tsmorphrename_symbol_by_tsmorphv1.0.1find_references_by_tsmorphmove_symbol_to_file_by_tsmorphremove_path_alias_by_tsmorphrename_filesystem_entry_by_tsmorphrename_symbol_by_tsmorphv1.0.0find_references_by_tsmorphmove_symbol_to_file_by_tsmorphremove_path_alias_by_tsmorphrename_filesystem_entry_by_tsmorphrename_symbol_by_tsmorphScored across 8 tools
Each tool owns a clearly distinct operation—symbol rename, file rename/move, symbol move, signature change, reference lookup, type query, alias removal, and dead-export detection. The descriptions include explicit "When NOT to use" cross-references that route the agent to the correct counterpart, leaving no ambiguity between overlapping-sounding tools like rename_symbol vs. move_symbol vs. rename_filesystem_entry.
All 8 tools follow a consistent snake_case verb_noun_by_tsmorph pattern, with the shared suffix making the family instantly recognizable. Minor structural variations like move_symbol_to_file_by_tsmorph and get_type_at_position_by_tsmorph are still verb-first and follow the same morphological convention, so there is no real inconsistency.
8 tools is a well-scoped size for a refactoring toolkit. Each tool covers a distinct, frequently-needed refactoring or analysis operation with no redundancy or bloat, and the count is comfortably within the ideal 3–15 range.
The surface covers the major project-wide refactorings—rename symbol, rename/move files, move symbol, change signature, dead-code detection—plus read-only helpers for references and types. The only notable gap is the absence of extract/inline-style refactorings, but those aren't strongly implied by the server's stated purpose, so this is a minor rather than significant gap.
Stateless TS/JS compiler facts for agents: references, imports, impact. No repo index or OAuth.
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.