Context Engineering: why API access alone doesn't make a good agent
You connect your AI agent to your Google Ads account. The API key is in place, the connection works. And yet the agent returns nonsense: wrong numbers, made-up campaign names. That's rarely the model's fault. It comes down to how the tools and their context are built.
There's a name for this problem: context engineering. The term describes which information lands in a language model's context window, and when.
What is context engineering?
Context engineering refers to the strategies a system uses to supply a language model with the right information. That's how Anthropic frames it on its engineering blog (2025). It covers everything that ends up in the context window: instructions, tool responses, the history so far.
The context window is limited. Every extra token draws on a tight budget of attention. So whatever goes in has to count.
The term dates back to the summer of 2025. Shopify CEO Tobi Lütke coined it; Andrej Karpathy made it popular. Karpathy drew a clear line between it and the older idea of prompt engineering:
Context engineering is the delicate art and science of filling the context window with just the right information for the next step.
A prompt is the short instruction you type. Context engineering is everything around it that decides between a good result and a mess. Context engineering in online marketing means this: the agent gets your campaign, analytics, and content data prepared so it can actually work with them.
The misconception: plug in an API key, and the agent is done
The common assumption goes like this: hook a language model up to the API, grant access, done. The agent will handle the rest. But access is only the precondition, not the solution.
Access itself is easy today. An MCP server connects the agent to your marketing accounts. What happens after that decides the quality.
Because an API doesn't answer for humans. It answers for other software.
What a raw API response means to a model
An example from the Google Ads API. You want to know what a campaign cost yesterday. The raw response looks roughly like this:
cost_micros: 47230000
campaign.resource_name: "customers/1234567890/campaigns/22334455"
campaign.status: 2Three traps are hiding in here. Costs come in micros: the Google Ads API multiplies every amount by 1,000,000. So 47230000 means €47.23. The campaign name is missing; there's only an ID. And status 2 means "enabled," but that's written nowhere.
A language model has to interpret all of this on its own. It guesses whether 47230000 is cents, euros, or micros. It has no name for the campaign. Every one of these steps is a source of error.
And that was just one campaign. A real query returns dozens of fields per row. Unfiltered, that floods any context window.
Anthropic puts it plainly: tools should return only high-signal information. Technical shorthand like internal IDs confuses the model more than it helps.
A well-built tool returns this instead: "Campaign Summer Sale, €47.23 spent, 3 conversions." The same data, but readable. The model has nothing left to guess. Optimize on the basis of misread numbers and you'll burn through budget fast.
The four levels of good context engineering
Good context engineering works on four levels. Each one reduces what the model has to interpret on its own. Together they turn raw access into a reliable tool.
Defaults
A tool needs sensible defaults. When the agent asks for campaigns, it shouldn't get back 500 rows. A good default returns the last 30 days, sorted by cost. Anthropic recommends exactly these kinds of reasonable default values.
Descriptions
The model picks tools based on their description. If it says "fetches data," the model guesses. If it says "fetches cost and conversions per campaign for a date range," the model gets it right. Anthropic stresses that even small improvements to descriptions produce big leaps.
Guardrails
Some actions change things: budgets, ads, published copy. Tools like these need limits. An approval gate before writing, a cap on spend, a log of every action. Without guardrails, a helpful agent becomes a risk. An agent that shifts budgets without being asked costs more than it saves.
Interpretation
The last level connects sources. A number from Google Ads says little on its own. Only alongside GA4, Search Console, and Clarity does it form a picture. How this context from multiple sources comes together is a task of its own. Good context engineering doesn't just pass data through. It puts data into relation.
Why context engineering means maintenance
A connector is never finished, because APIs change constantly. Google Ads releases a new API version several times a year and retires old ones. Meta, LinkedIn, and GA4 do the same.
Every change can reshape a response. A field gets a new name, a value arrives in a new unit. Left unmaintained, the connector breaks silently. The tricky part: no one notices right away. The agent then goes back to returning numbers without meaning.
This is exactly where a tool parts ways with a gimmick. An API key is plugged in within minutes. The preparation behind it is ongoing work: defaults, descriptions, guardrails, interpretation. Build it yourself and you take on this maintenance for every source. A maintained connector takes it off your hands.
The difference between a gimmick and a tool rarely lies in the model. It lies in the context engineering. For context engineering in online marketing, that means: only the preparation turns raw access into a reliable data foundation.
The Honeyfield Marketing MCP is exactly this kind of maintained connector. Over 200 tools for 11 marketing sources, with cleaned-up responses, approvals before write actions, and EU hosting. If you want your agent to work reliably, it's worth a look at marketing-mcp.honeyfield.at.