Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rope-mcp-server rename function calculate_total to compute_sum in src/utils.py"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides Python refactoring capabilities powered by the Rope library. Enables AI agents like Claude to perform safe, project-wide refactoring operations.
Move Symbol - Move classes and functions between files with automatic import updates
Move Module - Move entire modules or packages to different folders
Move and Rename Module - Move module to folder and rename (e.g., foo_extra.py → foo/extra.py)
Convert Module to Init - Transform foo.py into foo/__init__.py (no import changes!)
Convert Module to Package - Transform foo.py into foo/foo.py with import updates
Rename Symbol - Rename variables, functions, classes across entire projects
Extract Method - Extract code blocks into new methods
Inline Variable - Inline variables at all usage sites
List Symbols - Discover top-level symbols in Python files
All operations are project-aware and automatically update imports and references throughout your codebase.
Related MCP server: Rope MCP
# Global installation (all projects)
claude mcp add rope-refactor uvx rope-mcp-server -s user
# Or for current project only
claude mcp add rope-refactor uvx rope-mcp-server -s localpip install rope-mcp-serverclaude mcp add rope-refactor uvx rope-mcp-server -s user
claude mcp list # verifyThat's it.
list_symbolsList all top-level symbols (classes, functions, variables) in a Python file.
project_path: /path/to/your/project
file_path: src/models.pymove_symbolMove a class or function to another file. Automatically updates all imports.
project_path: /path/to/your/project
source_file: src/models.py
symbol_name: UserModel
dest_file: src/users/models.pymove_moduleMove a module or package to another folder. Automatically updates all imports.
project_path: /path/to/your/project
module_path: src/utils.py
dest_folder: src/libconvert_module_to_init (recommended)Convert a module file into a package by moving it to __init__.py. No import changes needed!
This is the recommended way to convert a module to a package. After conversion, you can use move_module to move related files (like foo_mixins.py) into the new package.
project_path: /path/to/your/project
module_path: app/views/customer_order.pyBefore:
app/views/customer_order.py
app/views/customer_order_mixins.pyAfter running convert_module_to_init:
app/views/customer_order/__init__.py (was customer_order.py)
app/views/customer_order_mixins.py (move this next with move_module)Import from app.views.customer_order import X stays unchanged!
move_and_rename_moduleMove a module to a folder and optionally rename it. Perfect for moving related files (like _mixins.py, _extra.py) into a package created with convert_module_to_init.
Auto-detection: If the module name starts with the destination folder name + underscore, it strips that prefix automatically.
Rope bug workaround: This tool includes a workaround for a Rope bug that crashes when a file has imports from BOTH the destination package AND the module being moved. Such files are temporarily hidden during the move, then their imports are fixed manually.
project_path: /path/to/your/project
module_path: app/views/customer_order_mixins.py
dest_folder: app/views/customer_order
new_name: mixins # Optional - auto-detected from prefixBefore:
app/views/customer_order/__init__.py
app/views/customer_order_mixins.pyImport: from app.views.customer_order_mixins import MyMixin
After:
app/views/customer_order/__init__.py
app/views/customer_order/mixins.pyImport: from app.views.customer_order.mixins import MyMixin
convert_module_to_packageConvert a module file into a package with the same name. Transforms foo.py into foo/foo.py while updating all imports project-wide.
Use this when you want the original module content in a submodule, not in __init__.py.
project_path: /path/to/your/project
module_path: app/views/service_contractor.pyBefore:
app/views/service_contractor.pyImport: from app.views.service_contractor import MyClass
After:
app/views/service_contractor/
├── __init__.py
└── service_contractor.pyImport: from app.views.service_contractor.service_contractor import MyClass
rename_symbolRename a symbol across the entire project.
project_path: /path/to/your/project
file_path: src/utils.py
symbol_name: old_function_name
new_name: new_function_nameextract_methodExtract a code region into a new method.
project_path: /path/to/your/project
file_path: src/service.py
start_line: 15
start_col: 4
end_line: 20
end_col: 30
new_name: extracted_helperinline_variableInline a variable at all usage sites.
project_path: /path/to/your/project
file_path: src/handler.py
variable_name: temp_result
line: 42close_rope_projectClose a Rope project to free memory. Call when done with refactoring.
project_path: /path/to/your/project# Install dependencies
uv sync
# Run tests
uv run pytest tests/ -v
# Run server locally
uv run python -m rope_mcp_server.serverThis server wraps the Rope refactoring library and exposes its capabilities via the Model Context Protocol. When Claude (or any MCP-compatible agent) needs to refactor Python code, it can use these tools to perform safe, AST-aware transformations that preserve code correctness.
Key implementation details:
Project caching - Rope projects are cached to avoid re-parsing on every operation
AST-based offset calculation - Symbol locations are computed via Python's AST module for accuracy
Automatic import handling - Rope handles all import updates when moving/renaming symbols
Only supports Python code (Rope limitation)
Moving methods between classes requires the target class to exist
Large projects may have slower initial indexing
Rope bug workaround: Files with imports from both the destination package and the module being moved are handled specially (hidden during move, then imports fixed manually) - see move_and_rename_module
MIT
Contributions welcome! Please open an issue first to discuss what you would like to change.
Close a Rope project and release resources.
Call this when done with refactoring to free memory.
Args: project_path: Root directory of the Python project
Returns: JSON with success status
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that resources are freed and memory is released, which is key behavioral information. While no annotations exist, the description adequately covers safety concerns.
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?
Two short paragraphs efficiently convey purpose, usage, parameters, and return value without unnecessary verbosity. Well structured.
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?
For a simple close operation with one parameter and an output schema, the description is complete. It covers all necessary aspects given the tool's complexity.
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?
The single parameter 'project_path' is self-explanatory from its name and type. The description does not add further semantics, but schema coverage is 0% - however, given the simplicity, baseline of 3 is appropriate.
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 action ('Close a Rope project and release resources'), which is distinct from sibling tools that perform various refactoring operations.
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?
Explicitly states when to call it ('when done with refactoring'), offering clear usage guidance. It could mention alternatives, but for this narrow tool it's sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a module file into a package by moving it to init.py.
Transforms foo.py into foo/__init__.py. No import changes needed
since the import path stays the same!
Example:
views/customer_order.py becomes views/customer_order/__init__.py
Import from views.customer_order import X stays unchanged.
This is the recommended way to convert a module to a package when you want to later split it into multiple files.
Args: project_path: Root directory of the Python project module_path: Path to module file (relative to project_path), e.g. "app/views/foo.py"
Returns: JSON with success status and new path
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| module_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that no import changes are needed, which is a key trait. However, it does not discuss potential side-effects (e.g., overwriting existing files), permissions required, or error conditions. This leaves some behavioral aspects implicit.
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 and front-loaded with the core purpose, followed by an example and a usage recommendation. It is concise without being terse, though the 'Args:' section could be integrated more succinctly. Overall, no unnecessary sentences.
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 simplicity (2 parameters, no annotations, output schema exists), the description covers the purpose, usage context, parameter semantics, and return format. It lacks details on error handling or prerequisites, but these are not critical for this straightforward transformation.
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 0%, so the description must explain parameters. It provides clear explanations for both 'project_path' and 'module_path' with examples and context (e.g., relative to project_path). This adds significant meaning beyond the schema's type-only definitions.
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 action (convert module file to package via moving to __init__.py) and the resource (module file). It provides an example and explains why the import path stays unchanged. However, it does not distinguish itself from the sibling tool 'convert_module_to_package', which could cause confusion.
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 specifies when to use this tool ('when you want to later split it into multiple files') and states it is the recommended approach. It does not explicitly mention when not to use it or provide comparison to alternatives, but the context given is sufficient for informed selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a module file into a package with the same name.
Transforms foo.py into foo/foo.py while updating all imports project-wide.
Example:
views/service_contractor.py becomes views/service_contractor/service_contractor.py
All imports like from views.service_contractor import X
become from views.service_contractor.service_contractor import X
This is a two-step process using Rope:
Move module to a temporary package (different name to trigger import updates)
Rename the temporary package to the original module name
Args: project_path: Root directory of the Python project module_path: Path to module file (relative to project_path), e.g. "app/views/foo.py"
Returns: JSON with success status and list of changed files
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| module_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully explains the two-step Rope process and the impact of updating imports project-wide. It provides a clear example and steps, though it omits potential edge cases like collisions or irreversible changes.
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 a main sentence, example, steps, and returns. It is slightly verbose but remains efficient and front-loaded with the core purpose.
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 has only 2 parameters, an output schema (as per context signals), and the description includes return format, the description is fully complete for an agent to invoke 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?
Despite 0% schema description coverage, the description includes an Args section that explains project_path and module_path with concrete examples, adding meaning beyond the schema's bare type definitions.
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 verb 'convert' and resource 'module file into a package', with an explicit example distinguishing it from siblings like move_module or rename_symbol. It is specific and actionable.
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 implies the tool is for converting modules to packages, but does not explicitly state when to use it versus alternatives like move_module. No exclusions or prerequisite conditions are provided, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a code region as a new method.
Args: project_path: Root directory of the Python project file_path: File path relative to project_path start_line: Start line (1-based) start_col: Start column (0-based) end_line: End line (1-based) end_col: End column (0-based) new_name: Name for the extracted method
Returns: JSON with success status and list of changed files
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| file_path | Yes | ||
| start_line | Yes | ||
| start_col | Yes | ||
| end_line | Yes | ||
| end_col | Yes | ||
| new_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that the tool returns JSON with success status and changed files, but omits important traits like whether the selection is replaced with a method call, or effects on imports.
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 concise and well-structured with an Args list and Returns section. No redundant sentences; every line adds value.
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?
The tool has an output schema, so return description is sufficient. However, the description lacks behavioral context (e.g., side effects on original code) and fails to differentiate usage from sibling refactoring tools, making it only partially 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?
Input schema has 0% description coverage, but the description explains each parameter (e.g., 'Start line (1-based)', 'Root directory of the Python project'). This adds meaning beyond the bare schema types, though some details (e.g., line inclusivity) could be clearer.
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 'Extract a code region as a new method', which is a specific verb and resource. It distinguishes well from siblings like rename_symbol or move_symbol, which are different refactoring operations.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., inline_variable, convert_module_to_init). There is no mention of prerequisites such as the file being open or the region being valid for extraction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inline a variable at all usage sites.
Args: project_path: Root directory of the Python project file_path: File path relative to project_path variable_name: Name of the variable to inline line: Line number where variable is defined (1-based)
Returns: JSON with success status and list of changed files
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| file_path | Yes | ||
| variable_name | Yes | ||
| line | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it modifies files and returns a success status with changed files, but it lacks details on side effects, error handling, or limitations (e.g., how it handles variable shadowing or dynamic references). Without annotations, the description carries the burden and only partially fulfills it.
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 structured with Args/Returns sections and is concise, containing no redundant information. However, it could be slightly streamlined by integrating parameter descriptions inline.
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?
For a refactoring tool with 4 parameters and an output schema, the description adequately explains the action, inputs, and return. It does not cover error scenarios or scope limitations, but it is generally complete for its complexity.
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?
The input schema has 0% description coverage, but the description provides meaningful parameter descriptions (e.g., 'project_path: Root directory', 'line: 1-based line number'), adding essential context beyond the property names and types.
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 'Inline a variable at all usage sites', which is a specific refactoring action on a variable. It distinguishes itself from sibling tools like rename_symbol and extract_method, which have different purposes.
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 provides no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or scenarios where inlining is inappropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all top-level symbols in a Python file.
Args: project_path: Root directory of the Python project file_path: File path relative to project_path
Returns: JSON with symbols: [{"name": "Foo", "type": "class", "line": 5, "byte_offset": 42}, ...]
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description states it lists symbols and returns JSON but does not disclose behavioral traits like read-only nature, side effects, or permissions. Basic functionality is clear but lacks extra transparency.
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 a single sentence followed by argument explanations and return format. It is concise, front-loaded with purpose, and every sentence adds value.
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 simplicity (2 parameters, no nested objects, has output schema), the description is complete. It explains inputs and return format adequately.
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 0%, but the description adds meaning by explaining that project_path is the root directory and file_path is relative. This compensates for the lack of 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 'List all top-level symbols in a Python file', which is a specific verb+resource. It distinguishes from sibling tools like move_symbol and rename_symbol.
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 provides arguments and return but does not explicitly state when to use this tool vs alternatives. Usage is implied but no explicit when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a module to a folder and optionally rename it.
This is a two-step operation:
Move module to destination folder
Rename the module (if new_name provided or auto-detected)
Auto-detection: If module is foo_bar.py and dest is foo/,
it will automatically strip the foo_ prefix → foo/bar.py
Includes workaround for Rope bug: Files that import from BOTH the destination package AND the module being moved are temporarily hidden during the move, then their imports are fixed manually.
Example: move_and_rename_module( "views/service_contractor_extra.py", "views/service_contractor/", new_name="extra" # or None for auto-detect ) Result: views/service_contractor/extra.py
Args: project_path: Root directory of the Python project module_path: Path to module file (relative to project_path) dest_folder: Destination folder path (relative to project_path) new_name: New name for the module (without .py), or None to auto-detect
Returns: JSON with success status and list of changed files
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| module_path | Yes | ||
| dest_folder | Yes | ||
| new_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently explains the two-step operation, auto-detection logic, and a Rope bug workaround. It also mentions the return format. While it discloses these behaviors, it does not explicitly state destructive nature or 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 a clear summary first, followed by detailed steps, example, and parameter list. Every sentence adds value 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 no annotations or output schema, the description covers all necessary details: operation, auto-detection, bug workaround, example, return format, and parameters. It is sufficiently complete for effective tool 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 0%, but the description includes an 'Args' section that explains each of the four parameters, adding meaning beyond the schema's type and required fields.
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 moves a module to a folder and optionally renames it, with specific details about auto-detection and a two-step operation. It effectively distinguishes from siblings like 'move_module' and 'rename_symbol'.
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 provides clear context for when to use the tool, including example and auto-detection behavior. However, it could explicitly differentiate from sibling tools like 'move_module', though the intent is largely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a module or package to another folder.
Updates all imports across the project automatically.
Args: project_path: Root directory of the Python project module_path: Path to module file or package folder (relative to project_path) dest_folder: Destination folder path (relative to project_path)
Returns: JSON with success status and list of changed files
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| module_path | Yes | ||
| dest_folder | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal all behavioral traits. It mentions automatic import updates and return format, but omits side effects like relative import adjustments or package boundary issues.
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?
Concise with labeled Args/Returns sections. The first line is redundant with Args, but overall efficient and easy to scan.
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?
Covers basic usage and return value, but lacks details on handling of package __init__.py, submodules, or potential failures. For a complex move operation, more completeness would be beneficial.
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 0%, so description must explain parameters. It clearly defines each parameter's meaning and relative path requirement, compensating for schema gaps.
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 it moves a module/package and updates imports. It differentiates implicitly from siblings like 'move_and_rename_module', but does not explicitly contrast with them.
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?
No guidance on when to use this tool versus alternatives like 'move_and_rename_module' or 'close_rope_project'. Lacks when-not-to-use or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a class or function to another file.
Updates all imports across the project automatically.
Args: project_path: Root directory of the Python project source_file: Source file path relative to project_path symbol_name: Name of the class or function to move dest_file: Destination file path (created if doesn't exist)
Returns: JSON with success status and list of changed files
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| source_file | Yes | ||
| symbol_name | Yes | ||
| dest_file | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses automatic import updates and dest_file creation. Missing details on error handling or permissions, but key behaviors are covered.
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 concise with a front-loaded purpose sentence followed by structured Args and Returns. 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?
Covers purpose, parameters, behavior, and return format (JSON with success and changed files). Lacks edge cases or error scenarios, but overall sufficient given no annotations.
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 0%, but description provides clear explanations for all 4 parameters in the Args section: project_path, source_file, symbol_name, dest_file, adding meaning beyond raw 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 'Move a class or function to another file' with automatic import updates. It distinguishes from sibling tools like rename_symbol (rename) and move_module (move module) by specifying the resource type.
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 implies usage when relocating a symbol with import updates, but lacks explicit guidance on when not to use or comparison with alternatives like extract_method or rename_symbol.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a symbol including all references and imports across the project.
Args: project_path: Root directory of the Python project file_path: File containing the symbol (relative to project_path) symbol_name: Current name of the symbol new_name: New name for the symbol
Returns: JSON with success status and list of changed files
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| file_path | Yes | ||
| symbol_name | Yes | ||
| new_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description effectively discloses the behavioral impact: renaming across the project including references and imports, plus return format (JSON with success and changed files).
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?
Concise with clear argument list; one sentence summary followed by structured args and returns. No wasted words.
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 involves renaming across a project, the description covers inputs and return but omits potential side effects, conflict handling, or limitations (e.g., scope handling). Could be more 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 coverage is 0%, and the description provides brief explanations for each parameter beyond their names (e.g., 'relative to project_path'), adding some value but not deeply detailed.
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 explicitly states the tool renames a symbol and updates all references and imports, clearly distinguishing it from siblings like move_symbol.
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?
No guidance on when to use this tool vs alternatives like move_symbol or inline_variable; lacks when-not-to-use or context for selection.
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. Dates show when Glama detected each change.
v0.1.2close_rope_projectconvert_module_to_initconvert_module_to_packageextract_methodinline_variablelist_symbolsmove_and_rename_modulemove_modulemove_symbolrename_symbolEach tool has a clearly distinct purpose: close project cleanup, two different module conversion strategies (to init vs to package), method extraction, variable inlining, symbol listing, module moving with optional rename, simple module moving, symbol moving, and symbol renaming. No two tools could be confused for the same operation.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., close_rope_project, convert_module_to_init, extract_method). Even multi-word verbs like move_and_rename_module are consistent, and no mixing of camelCase or other conventions occurs.
With 10 tools, the server is well-scoped for a Python refactoring assistant. Each tool addresses a specific refactoring or inspection task without unnecessary bloat or missing essential operations.
The tool set covers core refactorings (extract method, inline variable, rename symbol), module/package transformations, symbol movement, and project lifecycle (close). This provides a comprehensive surface for automated Python refactoring with no obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Exact text tools for AI agents: unified diff, patch apply, regex testing, grapheme counting.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/krystofbe/rope-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
