Nginx — 18 Operations for AI Agents
Nginx configuration is the front door of the internet — reverse proxies, TLS termination, routing rules where one wrong block takes a site down. act101 reads server and location blocks as structure, so agents see exactly which rule handles a request.
This page is the canonical reference an AI coding agent uses to refactor, query, and analyze Nginx code through the act MCP server. 18 operations available: 0 refactor, 18 query, 0 analysis. 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 Nginx examples
act101 reads an Nginx config's context blocks — http, server, events — and location blocks as declarations: the skeleton tags http/server block, but tags events field since it is built on a different underlying grammar node than the other context blocks. symbols covers the identical set, reporting http/server/the location routes as unknown and events as field; the two location route names keep a trailing space that skeleton strips but symbols does not. The unit of structure in this grammar is the named block: individual directives inside a block, such as listen or proxy_pass, are not read at all. 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 context and location blocks as a skeleton
tickets.conf fronts a ticket-booking platform: an events block sets worker connections, and inside http, a server block terminates TLS and routes /api/ to the booking backend and /static/ to a file root.
$ act query skeleton tickets.confBefore
worker_processes auto;
events {
worker_connections 1024;
}
http {
server {
listen 443 ssl;
server_name tickets.example.com;
location /api/ {
proxy_pass http://10.0.4.11:4000;
}
location /static/ {
root /var/www/tickets;
}
}
}Output
{
"type": "Skeleton",
"declarations": [
{
"kind": "field",
"name": "events",
"range": {
"start": {
"file": "tickets.conf",
"line": 3,
"column": 1,
"byte_offset": 24
},
"end": {
"file": "tickets.conf",
"line": 6,
"column": 1,
"byte_offset": 64
}
},
"name_range": {
"start": {
"file": "tickets.conf",
"line": 3,
"column": 1,
"byte_offset": 24
},
"end": {
"file": "tickets.conf",
"line": 3,
"column": 7,
"byte_offset": 30
}
}
},
{
"kind": "block",
"name": "http",
"range": {
"start": {
"file": "tickets.conf",
"line": 7,
"column": 1,
"byte_offset": 65
},
"end": {
"file": "tickets.conf",
"line": 21,
"column": 1,
"byte_offset": 314
}
},
"name_range": {
"start": {
"file": "tickets.conf",
"line": 7,
"column": 1,
"byte_offset": 65
},
"end": {
"file": "tickets.conf",
"line": 7,
"column": 5,
"byte_offset": 69
}
}
},
{
"kind": "block",
"name": "server",
"range": {
"start": {
"file": "tickets.conf",
"line": 8,
"column": 5,
"byte_offset": 76
},
"end": {
"file": "tickets.conf",
"line": 20,
"column": 1,
"byte_offset": 312
}
},
"name_range": {
"start": {
"file": "tickets.conf",
"line": 8,
"column": 5,
"byte_offset": 76
},
"end": {
"file": "tickets.conf",
"line": 8,
"column": 11,
"byte_offset": 82
}
}
},
{
"kind": "block",
"name": "/api/",
"range": {
"start": {
"file": "tickets.conf",
"line": 12,
"column": 9,
"byte_offset": 159
},
"end": {
"file": "tickets.conf",
"line": 14,
"column": 10,
"byte_offset": 231
}
},
"name_range": {
"start": {
"file": "tickets.conf",
"line": 12,
"column": 18,
"byte_offset": 168
},
"end": {
"file": "tickets.conf",
"line": 12,
"column": 24,
"byte_offset": 174
}
}
},
{
"kind": "block",
"name": "/static/",
"range": {
"start": {
"file": "tickets.conf",
"line": 16,
"column": 9,
"byte_offset": 241
},
"end": {
"file": "tickets.conf",
"line": 18,
"column": 10,
"byte_offset": 305
}
},
"name_range": {
"start": {
"file": "tickets.conf",
"line": 16,
"column": 18,
"byte_offset": 250
},
"end": {
"file": "tickets.conf",
"line": 16,
"column": 27,
"byte_offset": 259
}
}
}
]
}The skeleton reports http, server, /api/, and /static/ as block declarations, but reports events as field — the one block built on Nginx's directive node rather than its attribute node.
List the same blocks as symbols
The two location blocks route /api/ to the upstream backend and /static/ to a filesystem path.
$ act query symbols tickets.confBefore
worker_processes auto;
events {
worker_connections 1024;
}
http {
server {
listen 443 ssl;
server_name tickets.example.com;
location /api/ {
proxy_pass http://10.0.4.11:4000;
}
location /static/ {
root /var/www/tickets;
}
}
}Output
{
"type": "Symbols",
"symbols": [
{
"name": "events",
"kind": "field",
"range": {
"start": {
"file": "tickets.conf",
"line": 3,
"column": 1,
"byte_offset": 24
},
"end": {
"file": "tickets.conf",
"line": 3,
"column": 7,
"byte_offset": 30
}
},
"visibility": "unknown"
},
{
"name": "http",
"kind": "unknown",
"range": {
"start": {
"file": "tickets.conf",
"line": 7,
"column": 1,
"byte_offset": 65
},
"end": {
"file": "tickets.conf",
"line": 7,
"column": 5,
"byte_offset": 69
}
},
"visibility": "unknown"
},
{
"name": "server",
"kind": "unknown",
"range": {
"start": {
"file": "tickets.conf",
"line": 8,
"column": 5,
"byte_offset": 76
},
"end": {
"file": "tickets.conf",
"line": 8,
"column": 11,
"byte_offset": 82
}
},
"visibility": "unknown"
},
{
"name": "/api/ ",
"kind": "unknown",
"range": {
"start": {
"file": "tickets.conf",
"line": 12,
"column": 18,
"byte_offset": 168
},
"end": {
"file": "tickets.conf",
"line": 12,
"column": 24,
"byte_offset": 174
}
},
"visibility": "unknown"
},
{
"name": "/static/ ",
"kind": "unknown",
"range": {
"start": {
"file": "tickets.conf",
"line": 16,
"column": 18,
"byte_offset": 250
},
"end": {
"file": "tickets.conf",
"line": 16,
"column": 27,
"byte_offset": 259
}
},
"visibility": "unknown"
}
]
}symbols reports the same five entries, but http and server come back kind: unknown rather than block, events keeps kind: field, and the two location routes carry a trailing space in their names, "/api/ " and "/static/ ", that skeleton does not.
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