Five WordPress MCP jobs, 45 runs. Here are the token counts.

You ask Claude to find the WordPress posts missing SEO titles. Then you ask it to fill them in. Twenty posts, one category. A fairly ordinary SEO housekeeping job.

But with MCP, the work itself is only part of what consumes tokens. Claude also reads tool descriptions, receives API responses, figures out which calls to make, and carries the growing conversation into every subsequent step.

We wanted to measure that cost.

We tested three WordPress MCP servers against five real WordPress jobs. Each job ran three times per server, for 45 runs in total.

In our final test, Vibery Sites completed all 15 attempts, with median token counts between 9,342 and 20,945 per job. It used the fewest tokens on all five jobs.

Some competing connections also completed the work. Others could not access the required WordPress features or returned incorrect results.

Here is what we measured.

The test setup

We used one WordPress installation with the same seeded data and five prompts for every server.

The environment:

• WordPress 6.9.4
• WooCommerce 10.4.3
• Rank Math for SEO metadata
• Elementor 4.3.5
• Claude Sonnet through Claude Code, with nothing else loaded

We compared three connections.

The official WordPress MCP Adapter 0.7.1, alongside the WooCommerce MCP endpoint. This exposes abilities registered through WordPress, plus WooCommerce product and order tools.

Automattic's wordpress-mcp 0.2.5, which provides REST API tools for discovering endpoints and performing WordPress operations.

Vibery Sites, which exposes two MCP tools, search and execute. Your assistant can write a short script that runs server-side and returns a compact result, often one line, instead of bringing every WordPress record into the conversation.

The test site contained 60 posts in the Journal category, including 20 without Rank Math SEO titles. We also prepared an Elementor page and 14 WooCommerce orders from the previous seven days.

We measured total tokens as reported by Claude Code: input, cache creation, cache reads, and output.

We measured tokens rather than dollars because actual cost depends on model pricing, caching, and your plan.

Success was checked separately. A script read the WordPress site's actual content and settings after each run. Claude saying it had finished was not enough.

Five jobs, with the exact prompts

1. Find missing SEO titles.

In my Journal category, which posts don't have an SEO title set? List their titles.

2. Fill 20 missing SEO titles.

In my Journal category, some posts don't have an SEO title. Give each of those an SEO title in the form "<post title> | Bench Studio". Don't touch the posts that already have one.

3. Change an Elementor heading.

On my "Bench Landing" page, change the main heading from "Welcome to Bench Studio" to "Welcome to Harbor Studio". Leave everything else as it is.

4. Summarize WooCommerce orders.

Summarize my WooCommerce orders from the last 7 days: how many orders, total revenue, and my top 3 products by quantity sold.

5. Create a draft post.

Write a new draft post titled "Benchmark Harbor Notes" with three short paragraphs about visiting a harbor lighthouse, and put it in the Journal category. Don't publish it.

These cover SEO audits, bulk updates, page-builder edits, store reporting, and ordinary publishing.

The results

Each cell shows median total tokens · successful runs out of 3.

A few results are worth explaining.

The official adapter could not perform four jobs because its default configuration exposed no post, page, SEO, or builder abilities. WordPress abilities remain private unless a plugin explicitly makes them public.

That is a configuration and capability boundary, rather than evidence that the official adapter is bad.

The WordPress AI plugin was also unavailable for this test. It required WordPress 7.0.3, while our test installation ran 6.9.4.

But the official WooCommerce connection did its job correctly. It summarized the orders in one tool call and passed all three runs, with a median of 66,493 tokens.

Automattic's wordpress-mcp also completed the Elementor heading edit and draft creation, both 3/3.

Its SEO tasks failed because the Rank Math title metadata was not available through the exposed REST tools.

The WooCommerce summary failed for a different reason. Its order listing returned at most 10 rows and could not page or filter the results as needed. It reported 10 orders and $549.50, when the correct result was 14 orders and $747.00.

A smaller token bill means little if the answer is wrong.

Where the tokens go

The first source of overhead is tool descriptions.

The official adapter and WooCommerce connection exposed 12 tools in our setup. Their descriptions occupied approximately 22,800 tokens, included in the model's context at every step.

That overhead can be reasonable when a task finishes in one call. With multiple calls, those descriptions are carried through repeated model turns.

The second source is large responses.

During the tests, Automattic's wordpress-mcp encountered a 66,339-character API route list and a 1.3 MB site-information response. These oversized responses did not help it reach the missing Rank Math metadata.

The third source is work performed inside the model's conversation.

Consider updating 20 SEO titles across 60 posts.

A conventional approach might retrieve pages of posts, inspect their metadata, identify the missing titles, and send individual update requests.

Every returned record adds context. Each subsequent call can carry that context forward.

With Vibery Sites, your assistant can send a short script through execute. It identifies the posts missing SEO titles, performs the updates server-side, and returns a small summary.

Claude does not need to see 60 complete post objects or 20 separate update responses.

The WordPress work still happens. Much less of it needs to cross the model boundary.

What we changed in Vibery Sites

We reduced the instructions and discovery steps required before the assistant could perform useful work.

Vibery Sites still exposes two tools: search and execute. But with clearer guidance, Claude could use execute directly for these five jobs.

Across all 15 Vibery runs, the assistant made 32 tool calls, all throughexecute. It needed no separate search calls.

Finding missing SEO titles took one execution call. Updating them took two. Summarizing seven days of WooCommerce orders took one.

An Elementor heading change needed three calls. Creating a draft post needed three.

The assistant could spend its context on the user's request rather than repeatedly discovering how to reach WordPress.

That is particularly useful for freelancers and agencies working across multiple client sites. The same conversation can handle different site operations while respecting the access permissions you grant.

You control which sites and actions your assistant can access, with restore points and undo available for supported changes.

What this benchmark does not prove

We built this benchmark ourselves, and we improved Vibery Sites using what it showed. The five jobs, prompts, and pass/fail checker did not change. All results reported here come from one final run of all three servers on the same build.

This is one test installation, one model, and three runs per job. The results are indicative, not a universal ranking of WordPress MCP connections.

There was variation between runs. For example, Vibery's draft-post task ranged from 20,570 to 29,732 tokens, while Automattic's wordpress-mcp ranged from 37,799 to 46,952. Other tasks varied more substantially.

Different WordPress versions, plugins, models, prompts, and cache conditions will produce different numbers. A custom WordPress ability could also let the official adapter perform jobs unavailable in its default configuration.

We re-run the benchmark after every release that touches our AI tools.

Fewer tokens matter when the work gets done

For agencies already using Claude or ChatGPT to manage WordPress, MCP token overhead is another cost worth watching.

A five-minute housekeeping request should not require the assistant to receive a 1.3 MB site-information response or struggle with a 66,339-character API route list.

Our results suggest that keeping repetitive operations server-side, and returning only what the assistant needs, can make a substantial difference.

In this test, Vibery Sites used the fewest tokens on all five jobs and completed all 15 attempts correctly.

We will keep measuring it. The goal is straightforward: your assistant does the WordPress work, without making you pay in tokens for every intermediate step.

You remain in control of what changes.

Try Vibery Sites for 14 days: https://sites.vibery.app/app