Skip to main content
Glama

apply_codemod

Destructive

Apply structural or regex find-and-replace to modify code. Preview changes with dry-run before applying.

Instructions

Structural (AST-aware) or regex find-and-replace across files. Default engine "auto": when the pattern is an ast-grep pattern (concrete syntax with $META metavariables, e.g. "foo($$$ARGS)") supported code files (.ts/.tsx/.js/.jsx) are matched syntactically — so occurrences inside strings and comments are NOT touched. Plain regex patterns fall back to the text engine. Dry-run by default — first call shows preview (with engine_used), second call with dry_run=false applies. Potentially destructive. Always preview with dry_run=true first. Returns JSON: { success, engine_used, dry_run, matches, files_modified, total_replacements, total_files }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
engineNoEngine: "auto" (default — AST for ast-grep patterns on supported code files, else regex), "ast" (force ast-grep), "regex" (force text regex).
dry_runNoPreview changes without writing (default: true). Set to false to apply.
patternYesPattern to match. ast-grep pattern (e.g. "foo($$$ARGS)", "console.log($A)") for the AST engine, or a JavaScript regex for the text engine.
multilineNoRegex engine only: multiline mode (dot matches newlines, patterns span lines)
replacementYesReplacement template. AST engine: substitute captured metavariables ($A, $$$ARGS, or positional $1/$2). Regex engine: $1, $2 capture groups.
file_patternYesGlob pattern for files to scan (e.g. "tests/**/*.test.ts", "src/**/*.py")
confirm_largeNoRequired when >20 files affected. Acknowledges large-scale change.
filter_contentNoOnly process files containing this substring (narrows scope)
Behavior5/5

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

The description fully discloses behavior beyond annotations: the two-pass workflow (preview then apply), engine selection logic (auto defaults), and pattern matching characteristics (AST patterns ignore strings/comments). It also mentions the return JSON shape. Annotations already declare destructiveHint=true, and the description reinforces this with explicit warning.

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 a single paragraph of ~100 words, front-loaded with purpose. It covers key points concisely but lacks clear section breaks. Every sentence adds value; no unnecessary 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 tool's complexity (8 params, 3 required, no output schema), the description is remarkably complete. It explains engine behavior, workflow, return type, and provides explicit warnings. No critical information is missing.

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 coverage is 100% with thorough descriptions for all 8 parameters. The description adds high-level context (e.g., engine default behavior, dry-run workflow) but does not significantly enhance individual parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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: 'Structural (AST-aware) or regex find-and-replace across files.' It distinguishes between AST and regex engines with specific examples, and the verb 'apply_codemod' aligns with the action. Compared to siblings, this tool is uniquely for find-and-replace operations.

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 usage guidance: dry-run by default, preview first, set dry_run=false to apply. It warns about destructiveness and advises previewing. It explains when to use AST vs regex patterns. However, it doesn't explicitly list when not to use this tool or mention specific alternatives.

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/nikolai-vysotskyi/trace-mcp'

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