DEV Community: Dhotiiiii

Ask ten LLMs for a Blender 5.0 script. Then run it in Blender 5.0.

Dhotiiiii — Tue, 29 Sep 2026 07:28:01 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

The question

Ask an LLM for a Blender Python script and it will usually give you one that looks right. Whether it runs depends on which Blender you paste it into. The bpy API changes on every major release: enums get renamed, attributes are removed, node sockets move, whole subsystems (compositor, sequencer, animation) get restructured. Most of the Blender code a model has seen was written for 2.8 to 3.x. Ask for 5.0 and you often get a 3.x script that dies on the first changed line.

Text similarity cannot see this. mesh.use_auto_smooth = True reads perfectly and raises AttributeError in 4.1 and later. The only judge that counts is the Blender version you asked for. So the benchmark runs every answer in that exact version.

Two questions per answer:

runs: does the script, followed by a per-task assert script, exit 0 in a headless Blender of the target version?
aware: does the answer say what changed? Each answer must end with a WATCH OUT block naming every API that changed for that version and its replacement, or - none.

These come apart in interesting ways, which is most of what follows.

The task

30 scripting tasks, each asked for Blender 3.6, 4.2, 4.5 and 5.0 (119 prompts per model; one task has no 3.6 form). The tasks cover 33 verified API changes: EEVEE engine ids, the boolean solver enum, auto-smooth and custom normals, calc_normals, Principled BSDF socket names, the OBJ exporter, node group sockets, bone collections, slotted actions, the compositor node tree moving off Scene, the sequencer's sequences becoming strips, and so on. Two control tasks use APIs that did not change, to check the grader does not punish ordinary correct code.

Every model gets the same system prompt, temperature 0, no tools, no retrieval. The Kaggle task ships the four Blender Linux builds in a dataset, extracts them at the start of the run, and grades each answer by launching blender -b --factory-startup --python on the target build. A hand-written reference answer per task and version passes its assert in all four builds (119/119), which is the evidence that every prompt is answerable.

Models Tested

Ten models through the Kaggle Model Proxy, chosen to span vendors, sizes, open and closed weights, and reasoning styles, within a daily proxy budget of a few dollars:

model	why
gpt-5.5, claude-sonnet-5, gemini-3.1-pro-preview	current frontier from three vendors
gemini-3.7-flash, gemini-3.8-flash, claude-haiku-4-5	the small and cheap tier people actually script with
grok-4.20-0309-reasoning	fourth vendor, reasoning model (grok-4.6 is listed by the proxy but returned 404 on every call)
deepseek-r1-0528	open-weight reasoning model that returns its thinking inline
qwen3-coder-480b-a35b-instruct	open-weight model tuned for code
gpt-oss-120b	open-weight OpenAI model

Total proxy spend for the ten leaderboard runs: $11.23. gpt-5.5 alone was $4.44; qwen3-coder was $0.03.

Findings

Results

1190 graded answers. Aware is re-graded offline with the current parser so every model is judged the same way (more on that under methodology).

model	runs	aware	runs but unaware
gpt-5.5	95%	71%	26%
claude-sonnet-5	94%	53%	42%
gemini-3.8-flash	92%	77%	17%
gemini-3.1-pro-preview	92%	76%	18%
gemini-3.7-flash	89%	73%	18%
grok-4.20-reasoning	82%	29%	57%
claude-haiku-4-5	72%	31%	48%
qwen3-coder-480b	70%	29%	46%
deepseek-r1	67%	39%	33%
gpt-oss-120b	61%	29%	37%

Runs by target version:

model	3.6	4.2	4.5	5.0
gpt-5.5	97%	97%	100%	87%
claude-sonnet-5	100%	97%	100%	80%
gemini-3.8-flash	97%	90%	97%	87%
gemini-3.1-pro-preview	97%	90%	97%	83%
gemini-3.7-flash	93%	90%	90%	83%
grok-4.20-reasoning	86%	83%	87%	70%
claude-haiku-4-5	79%	77%	73%	60%
qwen3-coder-480b	83%	67%	70%	60%
deepseek-r1	86%	70%	63%	50%
gpt-oss-120b	93%	53%	57%	43%

Pooled over all ten models: 91% of scripts run on 3.6, 81% on 4.2, 83% on 4.5, 70% on 5.0. Awareness falls faster: 81%, 48%, 40%, 35%.

1. Every model is worst on 5.0, and the 5.0 failures are the same five APIs

Three categories go to 0% on 5.0 across all ten models: the compositor (Scene.node_tree is gone; the compositor is now a node group on scene.compositing_node_group), the boolean solver ('FAST' is now 'FLOAT', and 'MANIFOLD' is new), and the sequencer (SequenceEditor.sequences is now strips, and new_effect() takes length= instead of frame_end=). Animation is at 10%: Action.fcurves moved under slotted actions (action.layers[0].strips[0].channelbag(slot).fcurves). Not one model knew any of these. The training data has not caught up with 5.0 and no amount of scale fixes that. The best model on 5.0 (gpt-5.5 and gemini-3.8-flash, 87%) is still exactly as lost on these five as gpt-oss-120b.

The failures on 4.2 and later are different in character. They are changes from 4.0 to 4.2 that the models have partly absorbed (counts pooled over 4.2, 4.5 and 5.0): use_auto_smooth removed (19 failures), the legacy OBJ exporter bpy.ops.export_scene.obj removed (15), Mesh.calc_normals removed (14), BLENDER_EEVEE renamed (14), Principled BSDF Specular renamed to Specular IOR Level (9). The frontier models mostly get these right; the open-weight models mostly do not. gpt-oss-120b is the clearest case: 93% on 3.6, 53% on 4.2. It knows Blender 3.x well and stopped there.

2. A rename that was reverted splits the models into two camps

The render engine id was BLENDER_EEVEE in 3.6, became BLENDER_EEVEE_NEXT in 4.2 when EEVEE Next shipped, and went back to BLENDER_EEVEE in 5.0 when the legacy engine was deleted. Every model failed this task somewhere:

camp	models	3.6	4.2	4.5	5.0
learned the 4.2 rename	gpt-5.5, claude-sonnet-5, claude-haiku-4-5	ok	ok	ok	fail
never learned it	both gemini flash models, gemini-3.1-pro, grok, deepseek, qwen, gpt-oss	ok	fail	fail	ok

The second camp is right on 5.0 by accident: they write BLENDER_EEVEE for every version. The first camp is wrong on 5.0 with full confidence. gpt-5.5's WATCH OUT for the 5.0 prompt reads:

scene.render.engine = 'BLENDER_EEVEE': changed in Blender 4.2 when legacy EEVEE was replaced by EEVEE Next; use scene.render.engine = 'BLENDER_EEVEE_NEXT' in Blender 5.0.

Claude Sonnet 5's answer for 5.0 is the most instructive failure in the whole set. Its WATCH OUT names both identifiers and says the old one "no longer refers to the current EEVEE renderer in 5.0", so the aware check passes. The script then sets BLENDER_EEVEE_NEXT and fails. It knows there is a story here and tells the wrong half of it.

3. Running is not knowing: the "runs but unaware" gap

The gap column in the first table is the share of answers where the script ran but the WATCH OUT block missed the change. It is the number I find most useful, because it separates two very different kinds of model.

gemini-3.8-flash and gpt-5.5 have small gaps (17% and 26%): when their code works, they can usually say why the old code would not. Claude Sonnet 5 runs 94% of the time but names the change in only 53%; grok-4.20 runs 82% and names it in 29%. Both write - none under WATCH OUT for most prompts: Sonnet in 85 of 119 answers, grok in 110. qwen3-coder and Haiku do the same (115 and 109), and it is why the whole bottom half of the table sits at 29% to 39% aware. For every 2.80-era change (scene.objects.link becoming collection.objects.link, lamps becoming lights, dupli becoming instance) they silently write the modern form and declare that nothing changed. That is a judgement about what counts as "changed", not a parse failure, and I decided not to special-case it: the prompt asked for changes relative to older Blender, and 3.6 is old enough that 2.80 changes are still the ones people trip over in old tutorials.

The reverse gap, "aware but breaks", is small everywhere (1% to 7%). 41 answers named the change and still emitted broken code. Sonnet's EEVEE answer above is one. Three of Haiku's eight are the OBJ exporter: it knows export_scene.obj became wm.obj_export, then passes the old use_selection= keyword to the new operator.

4. The awareness curve is steeper than the run curve

On 3.6, awareness is 69% to 97%: everybody knows the 2.80 changes. By 4.2 the field splits. The three Gemini models and gpt-5.5 stay between 60% and 80% through 5.0, Sonnet sits at 43% to 53%, and everyone else drops below 30% by 4.5 and stays there. The scripts of that last group still run 57% to 87% of the time on 4.5 because most tasks touch APIs that did not change in that version. They are right without knowing why, and that is exactly the situation where a user cannot tell a stale answer from a current one.

5. Temperature 0 is not a determinism guarantee

The same model, prompt and settings, run four times through the proxy (gemini-3.7-flash across task versions): 107, 107, 103 and 106 of 119 scripts ran. Zero of the 119 answers were byte-identical between two runs. That is 3 to 4 points of noise on top of the sampling interval, so gpt-5.5 at 95%, Sonnet at 94% and the two Gemini models at 92% are a tie. Sonnet and gemini-3.8-flash actually swapped places between two task versions. The differences that survive the noise are the tiers: the five models above 89%, grok alone at 82%, and the four between 61% and 72%.

Methodology notes (the parts that would have silently corrupted the numbers)

Three grading problems showed up in real runs. Each one would have produced a plausible-looking leaderboard that was wrong.

Reasoning leaks into the answer. deepseek-r1 returns its thinking inline as <think>...</think>, and in 29 of 119 answers the thinking contained a draft code fence. The first notebook version ran the draft. Fixed by stripping the block before parsing; deepseek's run rate moved from 62% to 67% and its awareness came down, because the rehearsed WATCH OUT inside the thinking had inflated it. The Kaggle leaderboard still shows 62% for deepseek because that is what the notebook version that ran it computed; the tables here are re-graded offline from the stored answers, and the changed scripts were re-run in the same Blender builds.
Output caps truncate thinking models. Gemini 3.x thinking tokens count against max_tokens through the proxy. gemini-3.8-flash spends 12 to 16 thousand tokens thinking about auto-smooth, hit an 8192 cap once, and its "SyntaxError: unterminated string literal" was a truncation, not a model error. The task now raises the cap to 16384 for reasoning models and re-asks once at 32768 if an answer lands within 32 tokens of the cap. One answer needed that retry.
Proxy errors are not model errors. Rate limits (429) and daily-quota rejections (403) come back as exceptions. The task retries with backoff, excludes prompts that are still lost from the denominator, and aborts if more than 10% are lost rather than record a score. An early version recorded qwen3-coder at 0.8% because 118 of 119 calls were rate-limited; that version is gone.

Two limits worth stating. The aware check matches identifiers by substring and quoted enum values exactly, so it is a floor on awareness, not a proof of understanding. And 30 tasks is enough to show the shape of the drift, not to rank models that are three points apart.

Where this came from

The case bank and the WATCH OUT contract come from bpy-compass, a version-aware Blender assistant I built for the Sanity challenge. Its evaluation compared one model with and without a retrieval layer over the release notes. The question this benchmark asks is the one I wanted answered before building that: how bad is the drift without retrieval, for which models, and where exactly. The answer is that on 5.0 it is bad for everyone, and that retrieval over release notes is not a nicety for Blender scripting, it is the difference between the compositor working and not.

My Benchmark

Benchmark on Kaggle: https://www.kaggle.com/benchmarks/tasks/hoholalagaul/bpy-drift-runs/7 (task v7, ten models, public)
Blender builds and grading wheel: https://www.kaggle.com/datasets/hoholalagaul/bpy-drift-blender-builds
Code, case bank, reference answers and the aggregation script: https://github.com/Rustam335/bpy-drift-bench

bpy-compass: Blender Python answers that run on the version you actually have

Dhotiiiii — Mon, 28 Sep 2026 19:04:02 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

What I Built

You copy a render-setup script from a Blender 4.2 tutorial, run it in Blender 5.0, and get:

TypeError: bpy_struct: item.attr = val: enum "BLENDER_EEVEE_NEXT" not found in ('BLENDER_EEVEE', ...)

Ask a plain LLM to write that script for 5.0 and it can hand you the very same line. That is exactly what happened in my eval (case 10 below).

The bpy API breaks in almost every major release. scene.objects.link died in 2.80, the context-override dict for operators died in 4.0, the EEVEE engine identifier changed in 4.2 and changed back in 5.0, the fast boolean solver was renamed in 5.0. Old tutorials keep ranking, and a plain LLM answers from a memory where every version is blended together.

bpy-compass answers Blender Python scripting questions for the Blender version you pick, and tells you which popular pattern broke, in which version, and what replaced it. It reads a Sanity Context Knowledge Base built from the official release notes, a curated dataset of API changes and, on purpose, four stale tutorials. Every answer has three blocks:

ANSWER: a script valid for the requested version (3.6, 4.2, 4.5 or 5.0).
WATCH OUT: the popular patterns that stopped working, in which version, and what replaced them. Each bullet cites the Knowledge Base entry it came from.
SOURCES: the Knowledge Base entry paths the agent actually read for this answer.

If the Knowledge Base has no entry for part of a question, the agent marks those lines # NOT in Knowledge Base: and the UI highlights them, instead of inventing a citation.

Ask "Set the render engine to EEVEE and the boolean solver to the fast one" on 4.2 and on 5.0 and you get two different scripts (BLENDER_EEVEE_NEXT / FAST vs BLENDER_EEVEE / FLOAT), each explaining why. A keyword search over the release notes returns both identifiers with no way to tell which one applies to you.

To keep myself honest, every generated script is executed in headless Blender against an assert, for bpy-compass and for the same model without the Knowledge Base. The results, failures included, are on the live /eval page and in the table below.

Demo

Live app, no login: https://bpy-compass.vercel.app

Try it in a minute

Pick 4.2, click "Set the render engine to EEVEE and the boolean solver to the fast one." You get BLENDER_EEVEE_NEXT and FAST. Switch to 5.0 and click it again: BLENDER_EEVEE and FLOAT.
On 4.5, click "Join two meshes with a boolean union and apply it.", then Show what a stale tutorial would say to see the old-tutorial version next to it, with every break named.
Ask "Add a text object that says Hello and extrude it 0.2 units." The Knowledge Base has no entry for text objects, so those lines come back highlighted as # NOT in Knowledge Base:.
Open /eval for every run, failures included.

/ chat with the version rail. Try the same question on 4.2 and 5.0.
/eval the headless-Blender results table, filled from Sanity evalRun documents.
/about how it works, plus the Knowledge Base Issues screenshots before and after resolution.

Rate limit is 10 questions per minute per IP, so the OpenRouter key survives a public demo.

Code

https://github.com/Rustam335/bpy-compass (MIT)

app/          chat + version rail · /eval · /about · /studio · api/chat/route.ts
lib/          model.ts (pinned model/provider/temperature) · prompt.ts · context-mcp.ts · sanity.ts · rate-limit.ts
sanity/       schemaTypes/ (apiChange, blenderVersion, testCase, evalRun) · seed/*.json
scripts/      eval.ts (baseline vs bpy-compass → blender -b → evalRun docs) · seed-api-changes.ts
kb-sources/   the four stale tutorials uploaded as Knowledge Base file sources + ATTRIBUTION.md

Stack: Next.js App Router on Vercel, Vercel AI SDK with the MCP client, OpenRouter (z-ai/glm-5.3-flash, provider pinned to novita, temperature 0), Sanity Context MCP in knowledge_base mode, Sanity Studio embedded at /studio.

How I Used Sanity

What the Knowledge Base is built from

Three kinds of sources, all in one Knowledge Base (bpy-compass):

Dataset source: the project's own structured content. 27 apiChange documents, each with symbol, kind (removed / renamed / behavior), replacement, before and after code, a reference to the blenderVersion document it changed in, and the release-note URL it was verified against. This is the part a keyword search cannot reconstruct: the relationship between an old symbol, a version and its replacement.
Website sources: the official Python API release notes for 2.80, 3.6, 4.0, 4.1, 4.2, 4.4, 4.5 and 5.0 on developer.blender.org.
File sources: four tutorials written in the 2.7x style (scene.objects.link, obj.select = True, override dicts, calc_normals). They are there to make the build find the conflicts a real user would run into.

What the build found

Adding the stale tutorials next to the release notes made Sanity Context raise six Critical conflicts on the Issues tab:

Two of them were plain wrong-vs-right and got a pick (for example, Mesh.calc_normals() was removed in 4.0, not "available before 4.1"). Four of them were not conflicts at all: both sides were true for different Blender versions (BLENDER_EEVEE_NEXT in 4.2 vs BLENDER_EEVEE in 5.0; solver FAST up to 4.4 vs FLOAT from 5.0). "Pick a winner" is the wrong tool for that, so I resolved those with version-scoped picks and wrote a standing Instruction:

Every bpy API fact in this knowledge base is scoped to a Blender version. Two sources that give different values for different Blender versions are NOT in conflict: record both, each labeled with its version range. When two sources disagree about the SAME version, the official Blender release notes and the apiChange dataset are ground truth over tutorials. Always keep the old form in the entry, labeled with the version it stopped working in and its replacement.

Saving the Instruction flagged a contradiction in the "Modifiers & Boolean Solvers" entry and rebuilt it. The entry now carries a solver table by version range and a version-safe selection snippet:

Final state: 14 resolved issues and 4 manual Instructions. Two of the Instructions came from the eval harness catching the Knowledge Base being wrong (more on that below).

One lesson that cost me a rebuild: stale tutorials that carry an "intentionally outdated" banner produce zero conflicts, because the build reads the banner and files them as history. Real stale tutorials have no banner, so mine do not either.

What the agent does with it

The Context MCP endpoint bpy-compass exposes the Knowledge Base only. Per request:

The server fetches the Knowledge Base outline (initial_context) and inlines it into the system prompt together with the requested Blender version, so the model knows which entry paths exist.
The model calls knowledge_base_read with the paths it needs, up to five tool steps. The UI shows the paths as they are read.
The system prompt grounds every answer in the Knowledge Base first: every WATCH OUT bullet must cite an entry path, and any code the Knowledge Base does not back must start with # NOT in Knowledge Base: and is never cited as a source.

The baseline used for the eval gets the exact same model, provider, temperature, system prompt, output contract and user prompt. The only difference is the Knowledge Base: the baseline has no tools, no outline and no KB rules, and is told so.

Eval: same model, with and without the Knowledge Base

Each script was run in headless Blender, one exact build per target version (4.2.23 LTS, 4.5.14 LTS, 5.0.1) with --factory-startup, then the test case's assert script. A row passes only if the script ran and the answer kept its contract: WATCH OUT names every API change the test case expects (old symbol and replacement), and SOURCES lists only Knowledge Base entries the agent actually read. Runs are stored as evalRun documents in Sanity; /eval shows one complete run (both contenders, every case), never a mix of runs.

#	Question (short)	Target	Plain LLM	bpy-compass
1	Create a triangle mesh object and link it to the scene	4.5	✅	✅
2	Deselect all, select 'Cube', make it active	4.5	✅	✅
3	Print world-space vertex coordinates	4.5	✅	✅
4	Boolean UNION with a sphere, then apply the modifier	4.5	❌ script ran, but WATCH OUT never mentions the override dict → `temp_override` change	✅
5	Material 'Glow', Principled BSDF emitting orange at strength 5	4.5	✅	✅
6	Geometry Nodes group with Geometry in/out and a Float 'Scale' socket	4.5	✅	✅
7	Export selected objects to OBJ	4.5	✅	✅
8	Shade smooth by angle (30°)	4.5	❌ `'Mesh' object has no attribute 'use_auto_smooth'` (wrote it anyway, with a comment saying it was removed)	✅
9	EEVEE engine + 640×480 resolution	4.2	✅	✅
10	EEVEE engine + 640×480 resolution	5.0	❌ `enum "BLENDER_EEVEE_NEXT" not found`	✅
11	Boolean DIFFERENCE with the fast solver	4.5	✅	✅
12	Boolean DIFFERENCE with the fast solver	5.0	❌ `enum "FAST" not found in ('FLOAT', 'EXACT', 'MANIFOLD')`	❌ knew `FAST` → `FLOAT`, but created the cutter with `objects.new` without linking it, then `select_set`
	Pass rate		8/12	11/12

What the numbers say, honestly:

GLM 5.3 Flash already knows the 2.80 and 4.0 breaks. Link, select, @ matrix multiply, temp_override, node-group sockets, the new OBJ exporter: the plain model's scripts get them right (its case 4 script runs; it only failed to explain the override-dict break in WATCH OUT). A "plain LLMs get everything wrong" story would be false for this model, and I am not telling it.
The gap is at the newest boundary, 4.5 → 5.0. On cases 10 and 12 the baseline writes the 4.2–4.5 names (BLENDER_EEVEE_NEXT, FAST) into a 5.0 script and Blender rejects both. bpy-compass states each rename with a citation and gets the value right. Its one failure, case 12, is an ordinary scripting bug (an unlinked object), not a version mistake; it stays in the table.
The stricter harness cut both scores, and that is the point. An earlier run scored 11/12 vs 12/12 when passing only meant "the script ran". After an independent review (below) the harness also checks WATCH OUT and SOURCES, and the baseline gets the identical prompt. Case 4 is the clearest example: the baseline's script runs, but its WATCH OUT never mentions that the context-override dict was removed in 4.0.
The Knowledge Base is only as good as its sources, and the eval caught it. Case 8 first failed for bpy-compass: one entry offered modifiers.new(..., 'SMOOTH_BY_ANGLE'), a modifier type that does not exist. The agent's own WATCH OUT had flagged that two entries disagreed. The fix was an Instruction (the real replacement for use_auto_smooth is bpy.ops.object.shade_smooth_by_angle), a rebuild of two entries, and a rerun. The failed run is still in Sanity.
A reader reviewed the repo before publish and filed 13 issues. The first: every non-5.x case used to run in the 4.5 build, so the one 4.2 case had executed in Blender 4.5.14. The harness now maps each target to its own build and verifies blender --version before the first LLM call. The rest covered the eval (WATCH OUT/SOURCES were never checked, baseline and compass got different prompts, /eval could pair results from different runs, --only could silently run everything), the API route (message validation, the model-config guard only ran in eval, a rate limiter that never forgot an IP) and an inconsistent grounding policy. Every issue is fixed and referenced in the commits; the numbers above are from the rerun after those fixes.
Two harness lessons: reasoning tokens count against the output budget (one baseline attempt returned 16k characters of thinking and no code, so reasoning is now capped equally for both contenders), and Sanity's CDN caches test-case documents (the scripts read with useCdn: false).

Why the structured part matters

The apiChange dataset source is what makes "which version" answerable. A release-notes page says a symbol was removed; it does not say what the replacement is for a user on 4.2 versus 5.0, and it does not know that a 2.7x tutorial still ranks on Google. The dataset ties symbol, version and replacement together, the Knowledge Base build merges it with the release notes and detects where the stale tutorials disagree, and the Instructions encode the one rule a human had to decide: different versions are not a conflict, same version is, and release notes win.

Limits

Four target versions: 3.6, 4.2, 4.5 and 5.0.
Twelve eval cases on one model (GLM 5.3 Flash). They show where the Knowledge Base helps this model, not how every model behaves; a stronger model may already know some of the 5.0 renames.
The Knowledge Base is only as right as its sources. Case 8 needed a human-written Instruction to fix a wrong entry.
Code outside the Knowledge Base is marked # NOT in Knowledge Base:, not verified. It can still be wrong.

Sanity Project Details

Project ID: uuc8lnyk · dataset production (public read)
Knowledge Base: bpy-compass (kbMlSqMSn4Q9) · MCP endpoint: bpy-compass (Knowledge Base source only)
Schema: apiChange (27 docs), blenderVersion (8), testCase (12), evalRun (all runs, including failed ones)
Studio: https://bpy-compass.vercel.app/studio

Agent Session

Agent session transcript: bpy-compass build session: Sanity Context and Knowledge Base builds

The main Claude Code build session, cut to the Sanity part: enabling Context, the three Knowledge Base builds (0 → 2 → 6 conflicts), resolving the Issues, and wiring the Context MCP endpoint into the chat route.

Give Your AI Agent WhatsApp Superpowers with MCP (Official Business API)

Dhotiiiii — Fri, 18 Sep 2026 16:05:26 +0000

What if your AI assistant could check your store's WhatsApp inbox, look up an order, and send the customer a reply — by itself?

That's what the Model Context Protocol (MCP) makes possible. MCP is now supported across the LLM ecosystem — claude.ai, ChatGPT, Gemini, Cursor, Windsurf, VS Code Copilot, and most agent frameworks speak it — and in this post I'll show you how to wire any MCP-capable client to a live WhatsApp Business platform in under two minutes. No SDKs, no servers to host — it's a remote MCP server.

The server

Tokolaku is a WhatsApp business platform for Indonesian SMBs built on Meta's official WhatsApp Business API (Cloud API — so no gray-market gateways, no ban roulette). It exposes a hosted MCP server:

https://api.tokolaku.id/mcp

Transport: Streamable HTTP, stateless
Auth: OAuth 2.1 (interactive clients) or API key (programmatic)
Tools: send messages, browse inbox conversations, products, orders, manage webhooks

Option 1: OAuth-capable clients — just paste the URL

Any modern MCP client with OAuth discovery (claude.ai, ChatGPT, Gemini, LibreChat, and most hosted assistants) needs nothing but the URL:

Open your client's connector / MCP server settings (e.g. Settings → Connectors → Add custom connector)
Paste https://api.tokolaku.id/mcp
You'll be redirected to sign in with your Tokolaku account and approve access
Done. Your assistant now has 6 read-only tools scoped to your account: list_channels, list_conversations, get_conversation, list_products, list_orders, get_order.

Behind the scenes this uses PKCE, dynamic client registration (RFC 7591), and standard discovery metadata (RFC 8414/9728) — tokens are minted per user, short-lived, and revocable from the dashboard.

Try prompts like:

"Any unpaid orders from this week? Summarize who I should follow up with."

"Which products got asked about most in yesterday's chats?"

Option 2: Coding agents, CLIs & SDK frameworks — API key

For write access (actually sending messages), use a secret API key from the developer dashboard. Most coding agents and frameworks (Claude Code, Cursor, Windsurf, Cline, VS Code, OpenAI Agents SDK, LangChain, and friends) share the same mcpServers config convention:

{
  "mcpServers": {
    "tokolaku": {
      "type": "http",
      "url": "https://api.tokolaku.id/mcp",
      "headers": { "x-api-key": "tk_live_sk_xxx" }
    }
  }
}

Building your own agent instead? Point any MCP client SDK at the Streamable HTTP URL and pass the key as an x-api-key (or Authorization: Bearer) header — that's the whole integration.

Tools follow your key's scopes (tools/list reflects them), and write tools like send_message go through the exact same billing, quota, and rate-limit path as the REST API — your agent can't do anything your key can't.

A fun one to try in your coding agent of choice:

"A customer at +62812xxxx asked about their order this morning. Check the conversation, find the order status, and send them a polite update."

Why this pattern is interesting

Most "AI + WhatsApp" setups either screen-scrape the desktop app (fragile, ToS-risky) or make you build a bot pipeline first. A remote MCP server flips it: the platform speaks MCP natively, and any agent — today's or next year's — gets structured, permissioned access to real business state: conversations, catalog, orders.

The same endpoint also serves classic REST (POST /api/v1/messages, webhooks with HMAC signatures) and official SDKs on npm, PyPI, and Packagist — so the MCP layer is a first-class citizen, not a demo.