The shift you might have missed
Most of the conversation about AI in marketing is still stuck on prompting: how you phrase a request, which template you paste, how you coax a better paragraph out of a chatbot. That is the least interesting part of what is happening. The more consequential change is quieter, and it is buried in tooling release notes rather than product launches.
Here is the thing worth paying attention to. Simon Willison's LLM 0.32, released on 4th August 2026, and the accompanying llm-anthropic 0.26 plugin, added support for what Willison calls server-side tools. In the llm-anthropic release notes, those tools are named explicitly: WebSearch, WebFetch, CodeExecution, and AnthropicMCP. On the OpenAI side, Willison notes a code execution environment and a WebSearch tool are also available as server-side tools.
That sounds like plumbing. It is. But plumbing is what determines whether your marketing automation actually holds water.
What "server-side tools" actually means
Until recently, when you wanted a model to search the web, fetch a page, or run a calculation, you generally had to build that capability yourself. Your own code would call a search API, scrape a page, execute the snippet the model produced, then feed the result back into the next prompt. You were the middleman, and you were responsible for every moving part.
Server-side tools change who does the work. As Willison describes it, the provider executes the tool as part of the request. His example for the llm-anthropic plugin is a single command: he points Claude at an MCP endpoint using the AnthropicMCP tool and asks how many rows are in a database table. In his words, that "causes Anthropic to execute MCP calls against my new datasette-mcp plugin as part of a single request/response interaction with their API."
Read that again, because it is the whole point. One request in, one response out, and inside that single round trip the model searched, fetched, executed code, or called an MCP server, without you orchestrating each step by hand.
For those of us who spend our days wiring GA4, BigQuery, GTM and Claude together, that collapse of steps is the interesting bit. Less orchestration code to maintain means fewer places for a workflow to silently break.
Why marketers should care about MCP specifically
MCP, the Model Context Protocol, is the standard that lets a model talk to your tools and data in a structured way. The AnthropicMCP server-side tool means Claude can call an MCP endpoint directly during a request. If you have an MCP server exposing your analytics, your ad data, or your tag configuration, the model can reach it without a custom integration layer sitting in between.
This is exactly the territory we already work in.
Today, a lot of the coordination in that kind of setup lives in glue we write and maintain: fetch this, hand it to the model, take the answer, query that, hand it back. Server-side tools shrink that glue. The model handles more of the fetching and executing inside its own request, and we spend more time on the questions worth asking and less on the pipes carrying the answers.
That is not a hypothetical benefit. Every layer of custom orchestration you remove is a layer you no longer have to debug at 6pm when a campaign report comes back empty.
The part connecting MCP does not fix
Here is where we want to be direct, because it is easy to walk away from the paragraphs above thinking the hard problem is solved once you point Claude at an MCP endpoint. It is not. Connecting the model to your data removes a layer of plumbing between the request and the answer. It does nothing about the quality of what is sitting behind that endpoint.
If your GA4 events are misconfigured, if half your conversions are double-counted, if your GTM container fires the same tag twice on some pages and never on others, none of that gets fixed by giving Claude a faster route to the data. It gets amplified. A model that can query your BigQuery tables in a single round trip will confidently answer questions using whatever is in those tables, wrong assumptions and all. Server-side tools make it faster to get an answer. They say nothing about whether the answer is right.
This is the part of the pitch that gets skipped in most of the excitement about MCP, and it is worth being blunt about: an MCP connection to a trustworthy source is good, but "trustworthy source" is not something you get by installing a plugin. It is something you get by doing the unglamorous work first, deciding what a conversion actually means for your business, making sure your tracking reflects that definition consistently across channels, and checking that the numbers in your warehouse would survive an audit.
Put another way, AnthropicMCP collapses the distance between a question and an answer. It does not tell you whether the data underneath that answer was worth collecting in the first place.
Where the real work is
This is the gap between "we connected Claude to our analytics" and "we can actually trust what Claude tells us about our analytics." Closing that gap is not a model problem. It is a data foundation problem, and it looks like:
- Auditing what your tags actually fire, and when, rather than trusting what the GTM container claims to do — the analytics engineering work that nobody puts in a release note.
- Defining events and conversions consistently, so a "signup" in your ads platform means the same thing as a "signup" in BigQuery.
- Deduplicating and reconciling data across GA4, ad platforms and your warehouse before a model ever touches it.
- Building the MCP layer on top of that clean structure, so the model is fast at answering questions that are actually worth asking.
None of that shows up in a release note. It is also exactly the work that determines whether the four tools below are useful to you or just a faster way to get confidently wrong numbers.
The four tools, in marketing terms
Let's translate the four llm-anthropic server-side tools into work a marketing team actually does, with the caveat above attached to each one.
WebSearch. The model can search the web as part of answering. For competitive scans, SERP context, or checking what is currently ranking for a query, you no longer bolt on a separate search step. Ask the question; the search happens inside the request. This one is largely self-contained, since the model is reading public web content rather than your own tracking data.
WebFetch. The model can pull a specific page. Useful when you already know the URL you care about, a competitor's pricing page, a landing page you want summarised, a source you want checked, and want the model to read it directly rather than you copying text across.
CodeExecution. The model can run code as part of its answer. For marketers this is the quiet workhorse. Ad-hoc analysis, reshaping an export, a quick calculation across a dataset, all handled inside the response rather than in a spreadsheet afterward. This is only as good as the export or dataset you hand it. On the OpenAI side, Willison shows the same idea with a code execution environment invoked with a single flag to report current Python and SQLite versions.
AnthropicMCP. The model can call an MCP server during the request. This is the one that matters most if you have already invested in MCP endpoints for your data, and it is also the one where data quality matters most. Your analytics and ad tooling become reachable in a single round trip, for better or worse, depending on what is actually in them.
A note on the models, and on figures we won't invent
The llm-anthropic 0.26 notes list new models: claude-fable-5, claude-sonnet-5, and claude-opus-5. Willison's own example uses claude-sonnet-5. The release also simplified the thinking controls, and the notes state that Claude 5 models think by default. On the OpenAI side, Willison writes that LLM 0.32 supports the GPT-5.6 model family, with GPT-5.6 Luna as the new default for a basic prompt.
We will name those as the releases name them and stop there. There are no benchmark numbers, no pricing, and no performance percentages in these release notes, so we are not going to manufacture any. If you see a blog post confidently telling you one of these models is a specific percentage faster or cheaper, ask where the number came from. The honest answer, from what is published here, is that the release notes describe capabilities and model names, not benchmarks.
What this changes about how we build
The practical implication is a change in where complexity lives. For the past couple of years, building a serious marketing automation with Claude meant building an orchestration layer around it: search connectors, page fetchers, code runners, and MCP clients, all stitched together in something like n8n or in bespoke code. We do a version of this ourselves, running n8n agent workflows that harvest, draft and track content.
Server-side tools move a chunk of that orchestration inside the model provider's own request. That does not make your workflow platform obsolete. You still need something to trigger the work, route the results, and store the outcome where your team can act on it. But it does mean the model can do more thinking, searching and calculating in a single call, so your workflow has fewer intermediate steps to define and monitor.
Our rule of thumb: let the model handle what happens inside a single question, and let your workflow platform handle what happens between questions. Server-side tools push the line between those two jobs in the model's favour, which is a good thing when your goal is fewer brittle handoffs. But that rule only pays off once the data both sides are working from is actually sound.
Where to start
If you are already running an MCP setup, the fastest experiment is not just to try the AnthropicMCP tool against an endpoint you trust. It is to first ask whether that endpoint deserves the trust: run a handful of known answers through it and check them against numbers you have already verified by hand. If they hold up, see how much orchestration code you can delete. If they do not, that is the real project.
If you are not on MCP yet, the WebSearch, WebFetch and CodeExecution tools are the lowest-friction entry point: they need no infrastructure from you, just a model that supports them. But if your longer-term plan involves connecting a model to your own analytics, start with the tracking, not the connector.
Either way, the shift is the same. Less time spent being the middleman between the model and your tools, more time spent on the marketing questions those tools exist to answer, and no shortcuts around making sure the answers are actually true.
If you want help wiring Claude to your analytics and ad stack through MCP, that is exactly the kind of implementation we do at Bitegrico, and it is only half of what we do. The other half is making sure your GA4 events, your GTM tags and your BigQuery tables are clean and consistent enough that the model's answers are worth trusting in the first place. Talk to us about your MCP and analytics setup, and we will help you figure out what to build, what to fix first, and what to stop maintaining.