이 MCP 서버는 ts-morph 를 사용하여 TypeScript 및 JavaScript 코드베이스에 대한 리팩토링 작업을 제공합니다.
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 )기능 : 지정된 심볼(함수, 변수, 클래스, 인터페이스, 유형 별칭, Enum)을 현재 파일에서 지정된 다른 파일로 이동합니다.
유스 케이스 : 코드의 구성을 변경하기 위해서, 특정의 기능을 다른 파일에 잘라내고 싶은 경우.
필요한 정보 : 프로젝트의 tsconfig.json 경로, 원본 파일 경로 declarationKindString 대상 파일 경로 및 이동할 기호의 이름.
비고 : 심볼의 내부 종속성 (그 심볼 내에서만 사용되는 다른 선언) export 함께 이동합니다.
참고 : export default (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"
}
}
}
}서버의 동작 로그는 다음 환경 변수 env 사용하여 출력 레벨과 출력 대상을 제어할 mcp.json 있습니다.
LOG_LEVEL : 로그의 상세도를 설정합니다.
사용 가능한 레벨: fatal , error , warn , info (기본값), debug , trace , silent
예: "LOG_LEVEL": "debug"
LOG_OUTPUT : 로그의 출력 대상을 지정합니다.
console ( pino-pretty : NODE_ENV !== 'production' 에 로그를 출력합니다.
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 installTypeScript 코드를 JavaScript로 컴파일합니다.
pnpm build빌드 아티팩트는 dist 디렉토리에 출력됩니다.
단위 테스트를 실행합니다.
pnpm test코드의 정적 해석과 포맷을 실시합니다.
# Lintチェック
pnpm lint
# Lint修正
pnpm lint:fix
# フォーマット
pnpm format개발 중에 MCP 서버의 시작 순서, 표준 I/O 및 오류 출력을 자세히 확인하려면 프로젝트의 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 에 로그 .logs/mcp-ts-morph.log 출력되는지 확인하십시오.
이 래퍼를 사용하면 MCP 서버가 예상대로 부팅되지 않는 경우의 원인을 파악할 수 있습니다.
이 패키지는 GitHub Actions 워크플로( .github/workflows/release.yml )를 통해 npm에 자동으로 게시됩니다.
NPM 토큰: 공개 권한이 있는 npm 액세스 토큰이 리포지토리의 Actions secrets( Settings > Secrets and variables > Actions )에 NPM_TOKEN 이라는 이름으로 설정되어 있는지 확인합니다.
버전 업데이트 : 게시하기 전에 package.json 의 version 필드를 시맨틱 버전 관리 (SemVer)에 따라 업데이트하십시오.
릴리스 워크플로를 트리거하려면 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에 게시합니다.
확인: Actions 탭에서 워크플로의 상태를 확인하고 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Ship production-ready TypeScript code in half the time, at half the cost.