Refactory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| refactory_analyzeB | Analyze a source file for decomposition. Returns health score, function count, dependency graph, and recommended split points. |
| refactory_planA | Generate a decomposition plan — module boundaries, function assignments, dependency order. Uses AST analysis + LLM reasoning. |
| refactory_extractC | Extract one module from the monolith according to the plan. Routes to the cheapest capable free LLM API. |
| refactory_verifyB | Verify a decomposed module: loads without errors, exports match plan, no circular deps, tests pass. |
| refactory_metricsB | Calculate before/after metrics and the Refactory Score (0-1). Measures health improvement, module quality, test preservation. |
| refactory_reportA | Generate a decomposition report with metrics, dependency graphs, and Refactory Score. Outputs Markdown or HTML. |
| refactory_depmapA | Map dependencies for a file — who requires it (consumers), what it requires (dependencies), detect circular deps. |
| refactory_characterizeA | Generate characterization tests and golden export snapshot BEFORE decomposition. Captures behavioral contract. |
| refactory_verify_exportsA | Compare post-decomposition module against golden export snapshot. Reports missing, added, or type-changed exports. |
| refactory_fix_importsA | Mechanically fix broken require() paths after module extraction. No LLM needed — pure path resolution. |
| refactory_decomposeA | Full decomposition pipeline in one call: analyze, depmap, characterize, plan, extract ALL modules, fix-imports, verify, metrics, re-export, report. The 'just do it' tool. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool has a distinct and clearly defined purpose within the decomposition pipeline—analyze, characterize, decompose, depmap, extract, fix imports, metrics, plan, report, verify, verify exports. There is no overlap or ambiguity between them; an agent can easily select the correct tool for each step.
All tools follow the consistent pattern 'refactory_verb_noun' (e.g., refactory_analyze, refactory_fix_imports, refactory_verify_exports). The naming is uniform, predictable, and uses only snake_case, making it easy for an agent to infer functionality from the name.
With 11 tools, the server is well-scoped for its domain of code decomposition. Each tool serves a necessary step in the pipeline, and the count is neither too low (missing functionality) nor too high (unwieldy). The tool set earns its place.
The tools cover the entire decomposition lifecycle: analysis, characterization, dependency mapping, planning, extraction, import fixing, verification, metrics, reporting, and export verification. There are no obvious gaps; the surface is complete for the stated purpose of refactoring a monolithic file.