Skip to main content
Glama

refactor

Read-only

Analyzes code for refactoring opportunities including code smells, decomposition, and modernization. Guides through a structured investigation with expert validation.

Instructions

Analyzes code for refactoring opportunities with systematic investigation. Use for code smell detection, decomposition planning, modernization, and maintainability improvements. Guides through structured analysis with expert validation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepYesThe refactoring plan. Step 1: State strategy. Later steps: Report findings. CRITICAL: Examine code for smells, and opportunities for decomposition, modernization, and organization. Use 'relevant_files' for code. FORBIDDEN: Large code snippets.
modelYesCurrently in auto model selection mode. CRITICAL: When the user names a model, you MUST use that exact name unless the server rejects it. If no model is provided, you may use the `listmodels` tool to review options and select an appropriate match. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
imagesNoOptional list of absolute paths to architecture diagrams, UI mockups, design documents, or visual references that help with refactoring context. Only include if they materially assist understanding or assessment.
findingsYesSummary of discoveries from this step, including code smells and opportunities for decomposition, modernization, or organization. Document both strengths and weaknesses. In later steps, confirm or update past findings.
confidenceNoYour confidence in refactoring analysis: exploring (starting), incomplete (significant work remaining), partial (some opportunities found, more analysis needed), complete (comprehensive analysis finished, all major opportunities identified). WARNING: Use 'complete' ONLY when fully analyzed and can provide recommendations without expert help. 'complete' PREVENTS expert validation. Use 'partial' for large files or uncertain analysis.incomplete
hypothesisNoCurrent theory about issue/goal based on work
focus_areasNoSpecific areas to focus on (e.g., 'performance', 'readability', 'maintainability', 'security')
step_numberYesThe index of the current step in the refactoring investigation sequence, beginning at 1. Each step should build upon or revise the previous one.
temperatureNo0 = deterministic · 1 = creative.
total_stepsYesYour current estimate for how many steps will be needed to complete the refactoring investigation. Adjust as new opportunities emerge.
issues_foundNoRefactoring opportunities as dictionaries with 'severity' (critical/high/medium/low), 'type' (codesmells/decompose/modernize/organization), and 'description'. Include all improvement opportunities found.
files_checkedNoList all files examined (absolute paths). Include even ruled-out files to track exploration path.
refactor_typeNoType of refactoring analysis to perform (codesmells, decompose, modernize, organization)codesmells
thinking_modeNoReasoning depth: minimal, low, medium, high, or max.
relevant_filesNoSubset of files_checked with code requiring refactoring (absolute paths). Include files with code smells, decomposition needs, or improvement opportunities.
continuation_idNoUnique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
relevant_contextNoMethods/functions identified as involved in the issue
next_step_requiredYesSet to true if you plan to continue the investigation with another step. False means you believe the refactoring analysis is complete and ready for expert validation.
use_assistant_modelNoUse assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.
style_guide_examplesNoOptional existing code files to use as style/pattern reference (must be FULL absolute paths to real files / folders - DO NOT SHORTEN). These files represent the target coding style and patterns for the project.
Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description aligns with that. The description adds context about 'structured analysis with expert validation', hinting at a multi-step process, but does not fully disclose the iterative step-based workflow implied by the schema (step_number, total_steps, next_step_required).

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 just three sentences, front-loaded with the core purpose. It is concise and free of redundancy, though it could be slightly more structured to outline the multi-step process.

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

Completeness2/5

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

Given the tool's complexity (20 parameters, 6 required, multi-step protocol), the description is too brief. It does not explain the iterative step nature, how to use step_number/total_steps, or the role of expert validation, leaving significant gaps for an AI agent to infer from the schema alone.

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?

Schema description coverage is 100%, so the schema already documents all 20 parameters thoroughly. Baseline is 3, and the tool description does not add additional parameter meaning beyond what the schema provides.

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's purpose: 'Analyzes code for refactoring opportunities with systematic investigation' and lists specific use cases (code smell detection, decomposition planning, modernization, maintainability improvements). It differentiates from siblings like 'codereview' and 'analyze' by emphasizing systematic investigation and expert validation.

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 explicitly says 'Use for code smell detection, decomposition planning, modernization, and maintainability improvements', providing clear usage context. However, it lacks explicit guidance on when not to use or mention of 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/bigl34/pal-mcp-server'

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