Jinja — 103 Operations for AI Agents
This page is the canonical reference an AI coding agent uses to refactor, query, and analyze Jinja code through the act MCP server. 103 operations available: 29 refactor, 18 query, 42 analysis, 14 verification. Each operation is callable from Claude Code, Cursor, Codex, OpenCode, or any MCP-compatible agent host. Click any operation for a stable anchor link suitable for citation.
Worked Jinja examples
act101 reads and edits Jinja templates through the tag and expression structure the tree-sitter grammar exposes, so an edit targets a specific {% %} tag, {{ }} expression, or filter chain rather than a raw line offset. It can generate a {% macro %} scaffold with a given signature, and normalize the whitespace inside {% %}, {{ }}, and {# #} tag delimiters to a single space. It can also read a file's structure as a skeleton or list its symbols, surfacing {% extends %} imports, {% macro %} definitions, and {% block %} tags without descending into their bodies. Each example below is the verbatim output of the command shown, run against the file shown. Query outputs are pretty-printed with the timing block omitted.
Read the file's structure without bodies
invoice.jinja2 extends a base template, defines a line_item macro, and declares a body block that loops over items.
$ act query skeleton invoice.jinja2
Before
{% extends "base.jinja2" %}
{% macro line_item(name, qty, price) %}
<tr><td>{{ name }}</td><td>{{ qty }}</td><td>{{ price }}</td></tr>
{% endmacro %}
{% block body %}
<table>
{% for item in items %}
{{ line_item(item.name, item.qty, item.price) }}
{% endfor %}
</table>
{% endblock %}
Output
{
"type": "Skeleton",
"declarations": [
{
"kind": "import",
"name": "\"base.jinja2\"",
"range": {
"start": {
"file": "invoice.jinja2",
"line": 1,
"column": 4,
"byte_offset": 3
},
"end": {
"file": "invoice.jinja2",
"line": 1,
"column": 25,
"byte_offset": 24
}
},
"name_range": {
"start": {
"file": "invoice.jinja2",
"line": 1,
"column": 12,
"byte_offset": 11
},
"end": {
"file": "invoice.jinja2",
"line": 1,
"column": 25,
"byte_offset": 24
}
}
},
{
"kind": "macro",
"name": "line_item",
"range": {
"start": {
"file": "invoice.jinja2",
"line": 3,
"column": 4,
"byte_offset": 32
},
"end": {
"file": "invoice.jinja2",
"line": 3,
"column": 37,
"byte_offset": 65
}
},
"name_range": {
"start": {
"file": "invoice.jinja2",
"line": 3,
"column": 10,
"byte_offset": 38
},
"end": {
"file": "invoice.jinja2",
"line": 3,
"column": 19,
"byte_offset": 47
}
}
},
{
"kind": "block",
"name": "body",
"range": {
"start": {
"file": "invoice.jinja2",
"line": 7,
"column": 4,
"byte_offset": 157
},
"end": {
"file": "invoice.jinja2",
"line": 7,
"column": 14,
"byte_offset": 167
}
},
"name_range": {
"start": {
"file": "invoice.jinja2",
"line": 7,
"column": 10,
"byte_offset": 163
},
"end": {
"file": "invoice.jinja2",
"line": 7,
"column": 14,
"byte_offset": 167
}
}
}
]
}
The skeleton lists the "base.jinja2" extends target as kind import, line_item as kind macro, and body as kind block — three declarations, none of them showing the loop or markup inside.
List every named symbol in the file
invoice.jinja2 is the same template, with its line_item macro and body block as the only named declarations.
$ act query symbols invoice.jinja2
Before
{% extends "base.jinja2" %}
{% macro line_item(name, qty, price) %}
<tr><td>{{ name }}</td><td>{{ qty }}</td><td>{{ price }}</td></tr>
{% endmacro %}
{% block body %}
<table>
{% for item in items %}
{{ line_item(item.name, item.qty, item.price) }}
{% endfor %}
</table>
{% endblock %}
Output
{
"type": "Symbols",
"symbols": [
{
"name": "line_item",
"kind": "function",
"range": {
"start": {
"file": "invoice.jinja2",
"line": 3,
"column": 10,
"byte_offset": 38
},
"end": {
"file": "invoice.jinja2",
"line": 3,
"column": 19,
"byte_offset": 47
}
},
"visibility": "unknown"
},
{
"name": "body",
"kind": "unknown",
"range": {
"start": {
"file": "invoice.jinja2",
"line": 7,
"column": 10,
"byte_offset": 163
},
"end": {
"file": "invoice.jinja2",
"line": 7,
"column": 14,
"byte_offset": 167
}
},
"visibility": "unknown"
}
]
}
The symbol list gives line_item kind function and body kind unknown, each with the byte range act located it at.
Generate a macro scaffold
components.jinja2 contains only a comment; the command adds a render_item macro taking item and class.
$ act refactor-lang generate_macro --file components.jinja2 --params '{"name":"render_item","params":"item, class","line":1,"column":1}'
Before
{# template #}
After
{% macro render_item(item, class) %}
{# macro body #}
{% endmacro %}
{# template #}
A {% macro render_item(item, class) %}...{% endmacro %} pair is inserted at the top of the file with a placeholder comment as its body; the existing comment is untouched.
Normalize whitespace inside tag delimiters
toggle.jinja2 writes {%if x%}content{%endif%} with no spaces inside the tag delimiters.
$ act refactor-lang format_jinja_syntax --file toggle.jinja2 --params '{"line":1,"column":1}'
Before
{%if x%}content{%endif%}
After
{% if x %}content{% endif %}
{%if x%} and {%endif%} each gain a single space inside the delimiters, becoming {% if x %} and {% endif %}; the content text between them is untouched.
Query
18 query tools, the same on every supported language. Descriptions live in the shared reference: /docs/query-tools.
callers control_flow data_flow definition diagnostics effect_closure effect_summary fix_auto get_type graph import_organize interface mutations references repo_outline skeleton symbols symbols_batch
Refactor
| Operation | Description |
|---|---|
add-default-filter |
add default filter to variable reference |
add-escape-filter |
add escape filter to variable reference for XSS prevention |
convert-to-import |
convert include to import for namespace isolation |
extract-block |
extract template fragment into named block |
extract-include |
extract template fragment into separate include file |
extract-macro |
extract template fragment into reusable macro |
extract_function |
Extract a code selection into a new function — automatically infers parameters, return types, and inserts the call site. Use instead of manually cutting/pasting code. Works without LSP; LSP improves type inference. Params: file (string), new_name (string), start_line (u32), start_column (u32), end_line (u32), end_column (u32) [, preview (bool), receipt (bool)] |
extract_variable |
Extract an expression into a named variable — inserts the declaration and replaces the expression with the variable name. Works without LSP. Params: file (string), new_name (string), start_line (u32), start_column (u32), end_line (u32), end_column (u32) [, preview (bool)] |
format-jinja-syntax |
auto-format Jinja template syntax for consistent spacing and indentation |
generate-block |
create named block with placeholder content |
generate-dict-access-with-fallback |
create safe dict/object property access |
generate-dict-iteration |
create dictionary/object iteration loop |
generate-empty-state-block |
create if/else for empty collection display |
generate-filter-chain |
create sequential filter application |
generate-for-loop |
create {% for %} loop with placeholder body |
generate-if-block |
create {% if %} conditional with else branch |
generate-macro |
create new macro definition with signature from parameters |
generate-safe-output |
create output statement with escaping |
generate-variable-with-default |
create variable assignment with default filter |
inline |
Inline a variable, function, or method — replace every usage with its definition body, then remove the original. The inverse of extract. Works without LSP (single-file); LSP enables cross-file inlining. Params: file (string), symbol (string) [, line (u32), preview (bool), receipt (bool)] |
inline-variable-assignment |
inline variable assignment replacing set with direct reference |
insert_body |
Replace a function's implementation body with new code. AST-validated — rejects if the result has parse errors, so you can't accidentally break syntax. Use instead of manual text editing for function rewrites. Params: file (string), symbol (string), code (string) [, commit (bool)] |
move-block |
relocate block definition within template |
move_symbol |
Move a function, class, or type to a different file and automatically update all imports across the codebase. Use instead of manually cut/paste + fixing imports. Works without LSP (single-file); LSP enables cross-file import updates. Params: file (string), symbol (string), destination (string) [, preview (bool), receipt (bool)] |
recipe_run |
Run a codemod recipe: declarative match → transform → optional verify across modeled grammars. Preview lists matches; apply writes with optional E7 receipts and all-or-nothing rollback. Returns a per-site report. |
rename |
Rename a symbol and automatically update ALL references across the codebase. Safer and faster than find-and-replace — AST-aware, won't rename strings or comments. Works without LSP (single-file); LSP enables cross-file renames. Params: file (string), old_name (string), new_name (string) [, line (u32), column (u32), preview (bool), receipt (bool)] |
rename-block |
rename block definition across template inheritance chain |
rename-macro |
rename macro definition and all call sites |
rename-variable |
rename variable across all usages in template scope |
Analysis
42 analysis tools, the same on every supported language. Descriptions live in the shared reference: /docs/analysis-tools.
analyze_api_diff analyze_chokepoints analyze_clones analyze_clusters analyze_cohesion analyze_conformance analyze_coupling analyze_cycle_risk analyze_cycles analyze_dead_code analyze_depth analyze_entry_points analyze_export analyze_extraction analyze_fan_balance analyze_features analyze_hotspots analyze_impact analyze_inconsistencies analyze_inheritance analyze_interface_bloat analyze_interfaces analyze_layers analyze_orphan_types analyze_patterns analyze_platform_deps analyze_readiness analyze_roles analyze_seams analyze_stability analyze_surface analyze_test_gaps analyze_thickness analyze_type_completeness churn_hotspots co_change_clusters coverage_overlay ownership_map profile_overlay simulate split_module trace_overlay
Verify
14 verify tools, the same on every supported language. Descriptions live in the shared reference: /docs/verification.
bisect_regression gate generate_test_harness scan secret_surface summarize_pr taint_flow unsafe_surface verify_behavioral_equivalence verify_contract_preserved verify_diff_semantics verify_port_parity verify_side_effects verify_test_impact