Skip to main content
Glama

rewrite

Transform code patterns project-wide by replacing matches of a Python source pattern with a goal template, with dry-run audits and match constraints.

Instructions

Rewrite every site matching a structural Pattern into a Goal, project-wide — for transformations no dedicated refactoring expresses, such as migrating a deprecated call form (${obj}.get_attribute(${key}) -> ${obj}[${key}]) or collapsing an idiom. The Pattern is Python source with ${wildcard} placeholders; the Goal is the replacement template reusing those Wildcards. Prefer a dedicated behaviour-preserving tool (rename, inline, change_signature, move, use_function) whenever one fits; use rewrite only when none does, because a Rewrite is not behaviour-preserving: you assert that Pattern and Goal are equivalent, and the tool guarantees only that it rewrites exactly the Match Sites it reports. Control over-matching with per-Wildcard Match Constraints, e.g. constraints={"obj": {"type": "myapp.models.User"}}: name / type / object / instance narrow by a symbol's dotted path (one per Wildcard), and exact: true narrows to the Wildcard's literal name. type matches instances of exactly that class; instance matches instances of its subclasses (not the base class's own) — to cover a class and its subclasses, run once with each. A constrained run reports only the sites the constraint engages (matched or unsure), not every textual match. Each Match Site reports its certainty: matched (constraints satisfied) or unsure (a constraint that cannot be established at that site, common in dynamically typed code). Unsure sites are surfaced but not rewritten, so nothing is silently skipped; add unsure: true to a Wildcard's constraints to rewrite them too — they stay flagged unsure in the result for you to audit. When the Goal introduces a name the target modules do not import, pass imports (a list of import statements, added to each changed module, deduplicated); the tool never infers imports — checking for missing names is your LSP's job, so an omitted import leaves broken code. A rewrite that would produce unparsable Python fails safely in either mode, naming the file and parse location, with nothing written. Defaults to a Dry Run that previews without writing; review every Match Site for over-matching before setting apply=true. A truncated Match Site list ('showing N of M', unsure sites first) means the audit is incomplete — tighten the Pattern or Match Constraints and preview again before a Live Run. Both modes report the file-level Blast Radius and every Match Site (file + Range in 0-based UTF-16 LSP coordinates, against the pre-apply text — live targets for your LSP on a Dry Run, audit records after a Live Run). Start from a clean git tree, since git is the reversal mechanism, and run git diff after a Live Run to verify the equivalence you asserted. Pass root (the project directory) explicitly. Keep navigation and reading with your LSP; this tool only changes code.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYes
rootNo
applyNo
importsNo
patternYes
constraintsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description fully discloses the tool's non-behaviour-preserving nature, its dry-run default, handling of unsure match sites, safe failure on unparsable output, import behavior, and reliance on git for reversal.

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?

Although long, each sentence delivers unique operational knowledge—from matching semantics to failure behavior—without repetition. The structure logically moves from purpose to usage to parameter details to safety, justifying its length for a complex tool.

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?

The description covers the full lifecycle: selection, pattern/goal authoring, constraint control, dry-run preview, apply mode, output interpretation (blast radius, match sites, certainty), and post-run verification via git. It even explains truncated output and the need for a clean git tree, leaving no critical gap.

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

Parameters5/5

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

The schema provides only titles and types (0% description coverage), but the description explains pattern and goal templates, details constraint keys with exact/type/instance semantics, defines imports, apply, and root, adding meaning to every parameter.

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 opens with a specific verb and resource: 'Rewrite every site matching a structural Pattern into a Goal, project-wide', and gives concrete examples (get_attribute -> subscript). It explicitly distinguishes itself from dedicated refactoring tools by noting it is for transformations no dedicated refactoring expresses.

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?

It explicitly instructs 'Prefer a dedicated behaviour-preserving tool... whenever one fits; use rewrite only when none does', naming sibling tools. It also provides a workflow: dry-run, review match sites, set apply=true, and run git diff.

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/andrewesweet/ropey'

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