Post
Your AI Agent Shouldn't Read 5,000 Tokens to Change One CSS Value
A few weeks ago I gave ssg mcp access to the parts of a site it needed to
work on: templates, CSS and content. It could make a change and rebuild the
result. The workflow worked, but used far more context than the edit required.
For a page-background change, the only relevant information might be one line:
1background: #ffffff;
The agent did not know where that line was. It had to list files, open one or two likely candidates, read the whole stylesheet, send the whole file back with one value changed and often read it again to verify the edit.
On one migrated site, a one-line CSS change consumed roughly 10,000 tokens, mostly while locating that line. The model was not the bottleneck. The tools made it inspect the room before letting it turn off the light.
File access is not context access
The first MCP tools in SSG followed a fairly obvious filesystem model:
1list
2read
3write
That is a reasonable filesystem API, but a poor fit for many agent tasks.
If I ask a developer sitting beside me to change the page background, they do
not start by reading every stylesheet from line 1. They search for
background, look at a few surrounding lines, make the edit and move on.
An agent should be able to do the same thing, so SSG now has designer_find and
content_find.
1designer_find { "query": "background" }
returns something closer to:
1static/css/style.css:4-8
2
3body {
4 background: #ffffff;
5 color: var(--ink);
6}
Those five lines are the context the task required. The navigation CSS, print stylesheet and 300 lines of responsive rules below it add nothing to the edit.
Finding the line was only half the problem
Search removes the expensive read, but the original write operation still replaced the whole file.
That means changing this:
1background: #ffffff;
to this:
1background: #0b1220;
could still involve sending several kilobytes back through the model.
So the other half is an anchored edit:
1designer_edit {
2 "path": "static/css/style.css",
3 "old": " background: #ffffff;",
4 "new": " background: #0b1220;"
5}
old has to appear exactly once. SSG refuses the edit if it appears zero times
or more than once.
There is no fuzzy "this is probably what you meant" step between the model and the file.
That makes the normal path:
flowchart LR
A["Find 'background'"] --> B["5 relevant lines"]
B --> C["Anchored edit"]
C --> D["Changed lines returned"]
D --> E["Rebuild"]
The changed lines come back in the edit response, with their neighbours and line numbers. That response is also the verification. There is no reason to read the file again just to discover that the line now contains the value we just wrote.
Context is a resource
Token use is usually discussed as a pricing problem. For coding agents, context is also attention.
Every unrelated template block, CSS rule and paragraph you put into the context window competes with the thing the agent is supposed to be working on. A larger window lets you fit more irrelevant material in it; it does not make the irrelevant material useful.
The difference is easy to miss because both workflows eventually produce the same one-line diff.
One does this:
1list files
2read stylesheet
3read another stylesheet
4write entire stylesheet
5read stylesheet again
The other does this:
1find
2edit
The second workflow succeeds because the tool matches the task.
Where literal search falls short
Humans do not always know what text to search for.
You might ask:
Where is the styling for the box around code examples?
and there may be no word box, code example or anything else from that
sentence in the stylesheet.
A local text search cannot bridge that gap.
For projects using MDDB, SSG can therefore put an MDDB full-text search behind
the same find tools. ssg mddb push-theme indexes the templates and assets,
including their paths, kind, size and checksum.
The index is an accelerator, not a dependency.
The find tool asks the index first. If the index is unavailable or gives no useful answer, it falls back to the local scan.
A search outage therefore cannot prevent an agent from editing a local file.
Why not just give the agent grep?
You can, and you can also give it a shell.
For a general coding agent working inside a disposable checkout, that may be exactly the right answer.
ssg mcp has a narrower job. The designer is allowed to work on presentation.
The content role is allowed to work on Markdown. Those boundaries existed
before find/edit, and the new tools obey the same boundaries.
designer_find cannot quietly search the content tree.
content_edit cannot modify a template.
A more efficient tool must preserve the permissions of the slower one it replaced.
That constraint matters more as agents become better. The more capable the model, the less I want its safety model to depend on it remembering which directories I mentioned three prompts ago.
Small tools, smaller context
Improving an AI development tool does not always require a better prompt, a larger context window or another reviewing agent. Often the useful change is in the interface: do not send 4,812 bytes when the model needs 28; do not read a file merely to locate a line; do not read it again when the edit response can show exactly what changed.
The first version of ssg mcp gave the assistant access to the project. The
find and edit tools make that access economical. For many edits, five relevant
lines beat a larger context window.