Skip to main content
Glama

Rename Symbol

rename_symbol
Destructive

Rename code symbols across your entire codebase to maintain consistency and improve readability. Specify the symbol's path and new name to update all references automatically.

Instructions

Renames the symbol with the given name_path to new_name throughout the entire codebase. Note: for languages with method overloading, like Java, name_path may have to include a method's signature to uniquely identify a method. Returns result summary indicating success or failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
name_pathYesName path of the symbol to rename (definitions in the `find_symbol` tool apply).
relative_pathYesThe relative path to the file containing the symbol to rename.
new_nameYesThe new name for the symbol.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Core handler for the 'rename_symbol' MCP tool. The RenameSymbolTool.apply method implements the tool logic by creating a CodeEditor and invoking its rename_symbol method to perform the refactoring.
    class RenameSymbolTool(Tool, ToolMarkerSymbolicEdit):
        """
        Renames a symbol throughout the codebase using language server refactoring capabilities.
        """
    
        def apply(
            self,
            name_path: str,
            relative_path: str,
            new_name: str,
        ) -> str:
            """
            Renames the symbol with the given `name_path` to `new_name` throughout the entire codebase.
            Note: for languages with method overloading, like Java, name_path may have to include a method's
            signature to uniquely identify a method.
    
            :param name_path: name path of the symbol to rename (definitions in the `find_symbol` tool apply)
            :param relative_path: the relative path to the file containing the symbol to rename
            :param new_name: the new name for the symbol
            :return: result summary indicating success or failure
            """
            code_editor = self.create_code_editor()
            status_message = code_editor.rename_symbol(name_path, relative_file_path=relative_path, new_name=new_name)
            return status_message
  • ToolRegistry.__init__ automatically discovers all subclasses of Tool (including RenameSymbolTool) in serena.tools packages and registers them with snake_case names derived from class names (RenameSymbolTool -> 'rename_symbol').
    self._tool_dict: dict[str, RegisteredTool] = {}
    for cls in iter_subclasses(Tool):
        if not any(cls.__module__.startswith(pkg) for pkg in tool_packages):
            continue
        is_optional = issubclass(cls, ToolMarkerOptional)
        name = cls.get_name_from_cls()
        if name in self._tool_dict:
            raise ValueError(f"Duplicate tool name found: {name}. Tool classes must have unique names.")
        self._tool_dict[name] = RegisteredTool(tool_class=cls, is_optional=is_optional, tool_name=name)
  • Tool.get_name_from_cls derives the MCP tool name 'rename_symbol' from the class name 'RenameSymbolTool'.
    def get_name_from_cls(cls) -> str:
        name = cls.__name__
        if name.endswith("Tool"):
            name = name[:-4]
        # convert to snake_case
        name = "".join(["_" + c.lower() if c.isupper() else c for c in name]).lstrip("_")
        return name
  • LanguageServerCodeEditor.rename_symbol performs the actual renaming using LSP 'rename' request and applies the resulting workspace edit across the codebase.
    def rename_symbol(self, name_path: str, relative_file_path: str, new_name: str) -> str:
        symbol = self._find_unique_symbol(name_path, relative_file_path)
        if not symbol.location.has_position_in_file():
            raise ValueError(f"Symbol '{name_path}' does not have a valid position in file for renaming")
    
        # After has_position_in_file check, line and column are guaranteed to be non-None
        assert symbol.location.line is not None
        assert symbol.location.column is not None
    
        lang_server = self._get_language_server(relative_file_path)
        rename_result = lang_server.request_rename_symbol_edit(
            relative_file_path=relative_file_path, line=symbol.location.line, column=symbol.location.column, new_name=new_name
        )
        if rename_result is None:
            raise ValueError(
                f"Language server for {lang_server.language_id} returned no rename edits for symbol '{name_path}'. "
                f"The symbol might not support renaming."
            )
        num_changes = self._apply_workspace_edit(rename_result)
    
        if num_changes == 0:
            raise ValueError(
                f"Renaming symbol '{name_path}' to '{new_name}' resulted in no changes being applied; renaming may not be supported."
            )
    
        msg = f"Successfully renamed '{name_path}' to '{new_name}' ({num_changes} changes applied)"
        return msg
  • JetBrainsCodeEditor.rename_symbol delegates to JetBrainsPluginClient for IDE-based refactoring support.
    def rename_symbol(self, name_path: str, relative_file_path: str, new_name: str) -> str:
        with JetBrainsPluginClient.from_project(self._project) as client:
            client.rename_symbol(
                name_path=name_path,
                relative_path=relative_file_path,
                new_name=new_name,
                rename_in_comments=False,
                rename_in_text_occurrences=False,
            )
            return "Success"
Behavior4/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds valuable context: it specifies the scope ('throughout the entire codebase'), mentions language-specific considerations (Java method overloading), and describes the return format ('result summary indicating success or failure'). This goes beyond what annotations provide.

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

Conciseness5/5

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

The description is perfectly sized at three sentences, front-loaded with the core purpose, followed by important implementation notes and return value information. Every sentence earns its place with no wasted words.

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

Completeness5/5

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

Given the destructive nature (annotations), 3 parameters with full schema coverage, and the existence of an output schema, the description provides complete context. It covers purpose, scope, language considerations, and return format without needing to explain parameters or output details already documented elsewhere.

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

Parameters3/5

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

With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description adds minimal extra context: it references 'find_symbol' tool for name_path definitions and mentions method signatures for overloading, but doesn't provide significant additional parameter semantics beyond the schema.

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 verb ('renames') and resource ('symbol with the given name_path'), specifying scope ('throughout the entire codebase'). It distinguishes from siblings like 'replace_symbol_body' by focusing on renaming rather than content replacement.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool (renaming symbols across codebases) and includes a note about method overloading in languages like Java. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.

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

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/oraios/serena'

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