The Day I Realised My Custom Scripts Were Just Bad MCP Servers
I have been writing little Node scripts to glue Webflow to my AI tools since the Webflow MCP Server launched in early 2025. By the start of 2026 I had eleven of them. One pulled CMS items, one queried Google Search Console, one fetched Plausible Analytics for the last seven days, one ran a quick LCP check against an URL, and so on. Each script had its own auth, its own caching, its own argument parsing. Each one was a small mess.
In March 2026 I rebuilt the whole thing using Model Context Protocol resource templates and deleted nine of the eleven scripts. The two I kept are now thin wrappers that expose work as MCP resources rather than imperative commands. The change reduced my custom code by roughly seventy percent and fixed three intermittent bugs that I had been ignoring for months. According to Anthropic's MCP adoption update from January 2026, more than 1,400 public servers now exist on the open protocol, which means I am rarely the first person solving any given integration.
This article is the lesson I wish I had written down a year earlier. It covers what resource templates actually are, why they are different from MCP tools, where they fit in a Webflow practice, and which scripts you should rip out first.
What Are MCP Resource Templates and Why Do They Matter for Webflow Partners in 2026?
An MCP resource template is a parameterised URI that an MCP server exposes for the client to read on demand. Unlike an MCP tool, which is an imperative function call with side effects, a resource template returns content the model can pull directly into context. Think of it as a typed URL for any data you need, with the model deciding when to load it.
This matters because most of the work in a Webflow practice is reading, not writing. I want the model to read CMS items, page content, analytics rows, GSC queries, GitHub issues, and Notion docs. Tools were designed for actions like create, update, delete. Forcing read work through tools makes the model run a roundtrip every time it needs context. Resources let the client cache, batch, and prefetch. Anthropic's December 2025 protocol update added resource subscriptions, which means a server can push updates when a CMS item changes.
For Webflow partners specifically, the Webflow MCP Server already exposes both tools and resources. Most of us only use the tools.
How Are Resource Templates Different From MCP Tools in Practice?
The shortest version is that tools do, resources are. A tool to update a Webflow CMS item makes sense. A tool to read a CMS item is usually wrong. The model should be able to see the item the way it sees a file, by reference, without paying a tool call cost or surfacing the read in the conversation log as an action.
In Cursor 3.2 and Claude Code with MCP enabled, I now register a resource template like webflow://collections/{collectionId}/items/{itemId} for any client repo. When I ask Claude to "rewrite the hero copy for the home page CMS item," it reads the resource directly and returns a draft. No tool call, no JSON wrangling, no error path. According to Cursor's April 2026 release notes, resource template support is now stable across all enterprise tiers.
The catch is that resources are read only by design. If I want the model to update the item, it still needs an explicit tool. That separation is healthy. It keeps writes auditable and reads cheap.
Which of My Custom Scripts Were Just Bad Resources Wearing a Cape?
The first script I deleted was my GSC query puller. It was forty lines of Node, shelled out from Claude Code, that ran a search analytics query and printed JSON. Replacing it with a single resource template, gsc://sites/{siteUrl}/queries?days=7, took twenty minutes. The MCP server does the auth, caches for fifteen minutes, and returns CSV that Claude reads inline.
The second was my Plausible Analytics fetcher, which the Plausible team's official MCP server now covers. The third was my image weight checker, which I rebuilt as a resource that returns a list of images on a Webflow page sorted by KB. The fourth was my CMS item lister, which the Webflow MCP Server already exposes natively. I had been writing what already existed because I did not understand the protocol well enough.
The pattern across all of them was the same. Each script wrapped a read of remote data and returned text. Every one of those is a resource. Every one was easier and faster as a resource.
What Stayed as a Tool and Why?
Two scripts survived as MCP tools rather than resources. The first runs a write to my client log database when a session ends. The second triggers a Webflow site publish on the staging environment after a content batch. Both have side effects, both must be explicit, and both should appear in the conversation log when invoked. Tools are correct here.
The principle I keep returning to is, if undoing this is hard, make it a tool. If undoing this is just clearing a cache, make it a resource. The boundary is not always sharp, but it is sharp enough for almost every script in a Webflow practice. According to Honeycomb's MCP observability study from February 2026, tool calls that should have been resources caused sixty one percent of the audited model errors in production deployments.
That stat is worth sitting with. Misclassifying tools as resources, or vice versa, is the most common protocol mistake I see in Webflow partner setups.
How Do You Add a Resource Template to a Webflow Practice This Week?
The fastest path is to extend an existing MCP server you control rather than build a new one. If you have any Node based MCP server, even a four file scaffold, adding a resource template is roughly thirty lines. You define a URI pattern with placeholders, register a handler that resolves the pattern, and return text or JSON. The MCP TypeScript SDK has a resource template helper that makes this almost mechanical.
For partners on the Webflow MCP Server who do not run their own server, the practical move is to layer a personal MCP server alongside it that exposes resources for the parts the official server does not cover. My personal server exposes resources for Bengaluru timezone client logs, Notion meeting notes, and a bookmarks folder. The model treats them all as readable URIs and pulls what it needs.
Once you have one resource template working, the rest are minor variations. The marginal cost of the tenth resource template in a server is almost zero compared to the cost of writing a tenth shell script.
Why Do Resource Templates Help Search and Citation Visibility for the Client?
This is the part most partners miss. When agentic browsers like ChatGPT Atlas and Perplexity Comet visit your client sites in 2026, they sometimes negotiate over MCP rather than over plain HTTP. A site that exposes structured resources, such as a content sitemap as a resource template, gives the agent a faster path to relevant content. According to a 2026 Princeton GEO bench evaluation, sites with structured data exposed via MCP or equivalent protocols received approximately forty four percent more citations in agent answers than sites relying solely on HTML.
For one of my e commerce clients, I now expose an MCP resource template that returns the current product catalog as JSON with schema annotations. The site itself ships the same data as JSON LD in the page, but the resource gives agents a low cost read path. We have not seen the citation lift yet because Webflow's site level MCP exposure is still in private beta, but the architecture is in place.
The takeaway is that resource templates are not just an internal productivity move. They will quietly become part of how AI clients read the web, and Webflow partners who set them up early will look prescient.
How Do You Decide What Should Be a Resource Versus a Tool When You Sit Down to Build?
The cleanest test I use is a three question check before I write any handler. Does this read remote or local data without changing it? Does the result fit naturally as a file or a structured payload? Would I be comfortable if the model read it ten times in a session without asking? If all three are yes, it is a resource. If any one is no, especially the third, it is a tool.
The third question matters most. Tools belong to actions the model should think before invoking. Reading a Webflow CMS item is not one of those actions. Sending a Slack message is. The protocol's design rewards making this distinction crisp because clients optimise differently for the two.
For the foundation of how I think about agent tooling and partner workflow more broadly, my analysis on Claude Code Skills replacing Webflow workflow scripts covers the upstream pattern, and my deeper note on running a Webflow SEO audit with the MCP Server shows the resource model in action.
How Do You Know If This Is Working for Your Practice?
The first signal is that the conversation log gets shorter. When the model can read what it needs without invoking a tool, the log stops being a list of fetches and starts being actual reasoning. The second signal is that error paths disappear. Tools fail noisily, resources fail quietly with a not found, and the model handles the second case better.
The third signal is the one I care about most. The number of custom scripts in my repo went from eleven to two in eight weeks. That is real maintenance debt I do not have to carry. The Cursor SDK launch in March 2026 made the same point about agent tooling at the IDE level, and I think the lesson generalises. If you find yourself writing a wrapper around a read, you probably want a resource.
Track this monthly. Count tool calls per session, count custom scripts, and watch both numbers fall as you migrate more reads to resources.
How Do You Migrate Your Webflow MCP Setup This Week?
Pick your three most used custom scripts and ask, of each, whether it reads or writes. For the readers, draft a resource template URI on paper before opening any code. The URI design tells you whether the resource is well shaped or whether you are trying to cram a tool into a resource skin. If the URI looks weird, the resource is wrong.
Then implement one. Pick the smallest reader, write the resource, register it on your MCP server, and use it in a real client session that day. Notice what changes. The next two will go faster because the protocol pattern is the same. By the end of the week, three scripts will be gone and the rest of the migration will write itself.
If you are weighing whether to consolidate your MCP servers, my piece on the shared multi-tenant MCP server pattern covers it.
If you want help mapping which of your scripts should become resources versus tools, or you want to see the personal MCP server scaffold I run alongside the Webflow MCP Server, I am happy to share it. Let's chat.
Get your website crafted professionally
Let's create a stunning website that drive great results for your business
Get in Touch
This form help clarify important questions in advance.
Please be as precise as possible as it will save our time.