Skip to main content
Glama
SiroSuzume

MCP ts-morph Refactoring Tools

by SiroSuzume

rename_symbol_by_tsmorph

Rename TypeScript/JavaScript symbols project-wide by analyzing the AST. Updates all references across files using the project's tsconfig.json. Supports dry runs for previewing changes before saving.

Instructions

[Uses ts-morph] Renames TypeScript/JavaScript symbols across the project.

Analyzes the AST (Abstract Syntax Tree) to track and update references throughout the project, not just the definition site. Useful for cross-file refactoring tasks during Vibe Coding.

Usage

Use this tool, for example, when you change a function name defined in one file and want to reflect that change in other files that import and use it. ts-morph parses the project based on tsconfig.json to resolve symbol references and perform the rename.

  1. Specify the exact location (file path, line, column) of the symbol (function name, variable name, class name, etc.) you want to rename. This is necessary for ts-morph to identify the target Identifier node in the AST.

  2. Specify the current symbol name and the new symbol name.

  3. It's recommended to first run with dryRun: true to check which files ts-morph will modify.

  4. If the preview looks correct, run with dryRun: false (or omit it) to actually save the changes to the file system.

Parameters

  • tsconfigPath (string, required): Path to the project's root tsconfig.json file. Essential for ts-morph to correctly parse the project structure and file references. Must be an absolute path (relative paths can be misinterpreted).

  • targetFilePath (string, required): Path to the file where the symbol to be renamed is defined (or first appears). Must be an absolute path (relative paths can be misinterpreted).

  • position (object, required): The exact position on the symbol to be renamed. Serves as the starting point for ts-morph to locate the AST node.

    • line (number, required): 1-based line number, typically obtained from an editor.

    • column (number, required): 1-based column number (position of the first character of the symbol name), typically obtained from an editor.

  • symbolName (string, required): The current name of the symbol before renaming. Used to verify against the node name found at the specified position.

  • newName (string, required): The new name for the symbol after renaming.

  • dryRun (boolean, optional): If set to true, prevents ts-morph from making and saving file changes, returning only the list of files that would be affected. Useful for verification. Defaults to false.

Result

  • On success: Returns a message containing the list of file paths modified (or scheduled to be modified if dryRun) by the rename.

  • On failure: Returns a message indicating the error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dryRunNoIf true, only show intended changes without modifying files.
newNameYesThe new name for the symbol.
positionYesThe exact position of the symbol to rename.
symbolNameYesThe current name of the symbol.
targetFilePathYesPath to the file containing the symbol to rename.
tsconfigPathYesPath to the project's tsconfig.json file.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it modifies files across the project based on AST analysis, requires absolute paths to avoid misinterpretation, includes a dry-run option for verification, and returns success/failure messages with file lists. It doesn't mention error handling specifics or performance implications, but covers the core behavioral traits well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, usage, parameters, result) and uses bullet points effectively. While somewhat lengthy, every sentence adds value: the opening explains the tool's approach, the usage section provides concrete examples and workflow, and parameter details include important warnings. It could be slightly more concise but remains focused and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (AST-based refactoring with 6 parameters, no annotations, no output schema), the description does an excellent job of providing context. It explains the tool's purpose, when to use it, detailed parameter semantics, and expected results. The only minor gap is the lack of output schema, but the description adequately describes success/failure return values. It's nearly complete for a complex refactoring tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema: it explains why tsconfigPath is 'essential for ts-morph to correctly parse the project structure,' emphasizes that paths 'must be absolute (relative paths can be misinterpreted),' clarifies position is 'typically obtained from an editor,' and provides practical guidance about dryRun being 'useful for verification.' This contextual information enhances parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'renames TypeScript/JavaScript symbols across the project' and specifies it 'analyzes the AST to track and update references throughout the project, not just the definition site.' This distinguishes it from simple file renaming tools and its sibling 'rename_filesystem_entry_by_tsmorph' which likely handles file system operations rather than code symbol refactoring.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Use this tool, for example, when you change a function name defined in one file and want to reflect that change in other files that import and use it.' It distinguishes from alternatives by mentioning ts-morph's project-wide analysis and includes a numbered workflow with a dry-run recommendation, giving clear context for when and how to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SiroSuzume/mcp-ts-morph'

If you have feedback or need assistance with the MCP directory API, please join our Discord server