该 MCP 服务器利用ts-morph为 TypeScript 和 JavaScript 代码库提供重构操作。它与 Cursor 等编辑器扩展配合使用，允许基于 AST 的符号重命名、文件/文件夹重命名和参考查找。
Related MCP server: TypeScript Rename Helper
该 MCP 服务器提供以下重构功能：每个功能都使用ts-morph来分析 AST 并进行更改，同时保持整个项目的一致性。
rename_symbol_by_tsmorph ）作用：在整个项目中，全局重命名指定文件中特定位置的符号（函数、变量、类、接口等）。
用例：您想要更改函数或变量的名称，但对它有很多引用，手动更改它会很困难。
所需信息：项目的tsconfig.json路径、目标文件的路径、符号的位置（行和列）、当前符号名称、新符号名称
rename_filesystem_entry_by_tsmorph ）功能：重命名多个指定的文件和/或文件夹，并自动更新项目中所有import / export语句中的路径。
用例：您更改文件结构并想相应地修改导入路径。如果您想一次重命名/移动多个文件/文件夹。
所需信息：项目的tsconfig.json路径，重命名操作数组（ renames: { oldPath: string, newPath: string }[] ）。
评论：
引用主要通过符号解析来解析。
包含路径别名（例如@/ ）的引用将被更新但转换为相对路径。
引用目录索引文件（例如../components ）的导入将更新为明确的文件路径（例如../components/index.tsx ） 。
它还在重命名操作之前执行路径碰撞检查（现有路径和操作中的重复）。
**注意（执行时间）：**当同时处理许多文件和文件夹，或者对于非常大的项目时，解析和更新引用可能需要一些时间。
**注意（已知限制）：**目前，对形式为export default Identifier;可能无法正确更新。
find_references_by_tsmorph ）其作用：查找并列出指定文件中特定位置的符号定义，以及整个项目中的所有引用。
用例：您想知道函数或变量在哪里使用。您想探索重构的范围。
所需信息：项目的tsconfig.json路径、目标文件路径、符号位置（行、列）。
remove_path_alias_by_tsmorph ）功能：将指定文件或目录中的import / export语句中的路径别名（如@/components ）替换为相对路径（如../../components ）。
用例：您想让您的项目更具可移植性或符合特定的编码标准。
所需信息：项目的tsconfig.json路径，要处理的文件或目录的路径。
move_symbol_to_file_by_tsmorph ）功能：将指定的符号（函数、变量、类、接口、类型别名、枚举）从当前文件移动到另一个指定的文件。在您移动时自动更新整个项目的引用（包括导入/导出路径）。
用例：您想将某些功能提取到单独的文件中以重新组织您的代码。
所需信息：项目的tsconfig.json路径、源文件路径、目标文件路径、要移动的符号的名称。或者，您可以指定符号的类型（ declarationKindString ）来消除同名符号的歧义。
注意：符号的内部依赖项（仅在该符号内使用的其他声明）会随之移动。源文件中剩余的其他符号所引用的依赖项将保留在源中，并根据需要添加export ，并将其导入目标文件。
注意： export default导出的符号不能使用此工具移动。
将以下设置添加到mcp.json 。使用npx命令将自动使用您已安装的最新版本。
{
"mcpServers": {
"mcp-tsmorph-refactor": { // 任意のサーバー名
"command": "npx",
"args": ["-y", "@sirosuzume/mcp-tsmorph-refactor"],
"env": {} // 必要に応じてロギング設定などを追加
}
}
}如果您想从源代码在本地运行服务器，则需要先构建它。
# 依存関係のインストール (初回のみ)
pnpm install
# TypeScript コードのビルド
pnpm run build构建完成后，您可以通过在mcp.json中设置以下内容直接在node中运行它：
{
"mcpServers": {
"mcp-tsmorph-refactor-dev": { // 開発用など、別の名前を推奨
"command": "node",
// プロジェクトルートからの相対パスまたは絶対パス
"args": ["/path/to/your/local/repo/dist/index.js"],
"env": {
// 開発時のデバッグログ設定など
"LOG_LEVEL": "debug"
}
}
}
}可以使用以下环境变量来控制服务器操作日志的输出级别和目的地。在mcp.json的env块中设置它。
LOG_LEVEL ：设置日志详细程度。
可用级别： fatal 、 error 、 warn 、 info （默认）、 debug 、 trace 、 silent
例如： "LOG_LEVEL": "debug"
LOG_OUTPUT ：指定日志输出目的地。
console （默认）：记录到标准输出。如果您处于开发环境（ NODE_ENV !== 'production' ）并且安装了pino-pretty ，则输出将采用漂亮的格式。
file ：将日志输出到指定的文件。设置此项以避免影响 MCP 客户端。
例如： "LOG_OUTPUT": "file"
LOG_FILE_PATH ：如果LOG_OUTPUT设置为file ，则指定日志文件的绝对路径。
默认值： [プロジェクトルート]/app.log
例如： "LOG_FILE_PATH": "/var/log/mcp-tsmorph.log"
示例配置（在mcp.json中）：
// ... (mcp.json の他の設定)
"env": {
"LOG_LEVEL": "debug", // デバッグレベルのログを
"LOG_OUTPUT": "file", // ファイルに出力
"LOG_FILE_PATH": "/Users/yourname/logs/mcp-tsmorph.log" // ログファイルのパス指定
}
// ...Node.js（有关版本，请参阅.node-version或package.json中的volta字段）
pnpm（查看package.json中的packageManager字段了解版本）
克隆存储库并安装依赖项：
git clone https://github.com/sirosuzume/mcp-tsmorph-refactor.git
cd mcp-tsmorph-refactor
pnpm install将 TypeScript 代码编译为 JavaScript。
pnpm build构建产物输出到dist目录。
运行单元测试。
pnpm test它静态分析并格式化您的代码。
# Lintチェック
pnpm lint
# Lint修正
pnpm lint:fix
# フォーマット
pnpm format如果您在开发过程中想要详细检查 MCP 服务器的启动顺序、标准输入/输出以及错误输出，可以使用位于项目scripts目录中的mcp_launcher.js 。
该包装脚本将原始 MCP 服务器进程（ npx -y @sirosuzume/mcp-tsmorph-refactor ）作为子进程启动，并将启动信息和输出记录到项目根目录中的.logs/mcp_launcher.log文件中。
使用方法：
在mcp.json文件中，将mcp-tsmorph-refactor服务器配置更改如下：
将command设置为"node" 。
在args中，指定scripts/mcp_launcher.js的路径（例如， ["path/to/your_project_root/scripts/mcp_launcher.js"] ）。您还可以使用相对于项目根目录的路径（ ["scripts/mcp_launcher.js"] ）。
示例配置（ 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"
}
}
// ... 他のサーバー設定 ...
}
}重新启动或重新加载 MCP 客户端（例如 Cursor）。
请确认日志已输出到项目根目录中的.logs/mcp_launcher.log 。如果已配置，您还可以检查 MCP 服务器本身的日志（例如.logs/mcp-ts-morph.log ）。
使用此包装器可以帮助您诊断 MCP 服务器未按预期启动的原因。
该包将通过 GitHub Actions 工作流程（ .github/workflows/release.yml ）自动发布到 npm。
NPM 令牌：确保您拥有一个在存储库的操作机密（ Settings > Secrets and variables > Actions ）中设置了公共权限的 npm 访问令牌，其名称为NPM_TOKEN 。
更新您的版本：在发布之前，根据语义版本控制（SemVer）更新package.json中的version字段。
要触发发布工作流程，请使用 Git 标签推送。
如何：推送 Git 标签（建议发布时使用）
**预期用途：**常规版本发布（主要版本、次要版本、补丁版本）。 Git 是推荐的标准发布流程，因为它提供了历史记录和版本之间的清晰对应关系。
更新版本：更改package.json中的version （例如0.3.0 ）。
提交并推送：提交对package.json的更改并将其推送到主分支。
创建标签并推送：创建与版本匹配的 Git 标签（带有v前缀）并推送。
git tag v0.3.0
git push origin v0.3.0自动化：推送标签会触发Release Package工作流程，该工作流程会构建、测试并将包发布到 npm。
验证：在“操作”选项卡中检查工作流程的状态，并在 npmjs.com 上验证您的包。
版本一致性：在标签推送时触发，标签名称（例如v0.3.0 ）必须与package.json中的version完全匹配（例如0.3.0 ）。如果不匹配，工作流程将失败。
预检：尽管您的 CI 工作流程包括构建和测试步骤，但我们建议在更新版本之前在本地运行pnpm run build和pnpm run test以便尽早发现潜在问题。
该项目根据 MIT 许可证发布。请参阅LICENSE文件以了解详细信息。
[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.
Coding agents in multi-service codebases routinely rebuild existing helpers, trust stale type definitions, and modify API contracts without knowing who consumes them. Carrick solves this by indexing your entire TypeScript ecosystem across service and repository boundaries. By integrating deeply with the TypeScript compiler, Carrick traces every route, type, and cross-service call while recording function behaviour so agents search by intent rather than name. Delivered via MCP for AI agents and LSP for IDEs, Carrick ensures models see existing endpoints and utilities before generating new code. The scanner is source-available and runs from your CLI or CI pipeline.
