Framework Guide · WebMCP · MediaWiki
WebMCP for MediaWiki: knowledge bases agents can actually use
MediaWiki has had a machine API since before the term existed: the Action API is a decades-hardened, token-guarded, self-documenting interface — functionally what people now reinvent as “MCP for wikis.” What wikis never had is a page-level agent surface: a way for the reader’s assistant to search, summarize and prepare contributions inside the article they’re standing in. This article, written for extension developers and site administrators, maps WebMCP onto MediaWiki’s own doctrine — modules as tools, tokens as the confirmation boundary — and is candid about which half belongs to the Action API’s century-old discipline.
Fact-checked and updated on September 2, 2026 (MediaWiki Action API documentation). Primary sources are cited at the end of the article.
Doctrine first: MediaWiki already wrote the spec’s security chapter
The Action API’s design rules are documented, ancient and familiar to every wiki engineer: every operation is a module parameterized by format and version; reads are stateless; every state-changing action requires a token and POST; the ApiSandbox lets you construct calls interactively ([API:Action API overview](https://www.mediawiki.org/wiki/API:Action_API); [API:Main page](https://www.mediawiki.org/wiki/API:Main_page)). Modern JSON practice: format=json&formatversion=2 — flat, predictable, LLM-friendly ([API:Data formats](https://www.mediawiki.org/wiki/API:Data_formats)).
Now the newcomer. WebMCP lets a live page declare callable tools to an in-browser agent — document.modelContext.registerTool() imperatively, annotated <form>s declaratively — with Chrome’s origin trial (149–156, June 2026 onward) as the production door ([specification](https://webmachinelearning.github.io/webmcp); [Chrome for Developers](https://developer.chrome.com/docs/ai/webmcp)). The specification, pointedly, defines no auth and no approval mechanism of its own; the burden is explicitly the site’s.
Read together, the pairing is almost embarrassingly well-matched: query modules are read tools; action modules are write tools; MediaWiki’s token regime is the confirmation boundary the spec leaves blank. A wiki that treats agents as a new class of anonymous-plus-credentialed editor is applying its own 2007 lessons, not improvising.
Server-side first: an MCP front for the Action API
Most real agent traffic to a wiki today is not a reader’s Gemini tab — it is ingestion pipelines, RAG bots and research agents, exactly the clients that never render a page. Their answer is standard MCP — tools/list/tools/call over HTTP — and the mapping onto MediaWiki’s module granularity is transliteration, not invention:
# illustrative Python — each tool is a mapped api.php call
TOOLS = [
{"name": "search_pages",
"description": "Full-text search; returns title + snippet for up to 20 matches.",
"inputSchema": {"type": "object",
"properties": {"query": {"type": "string"}},
"required": ["query"]},
"annotations": {"readOnlyHint": True}},
{"name": "get_article",
"description": "Returns the parsed plain-text body of one page by title.",
"inputSchema": {"type": "object",
"properties": {"title": {"type": "string"}},
"required": ["title"]},
"annotations": {"readOnlyHint": True}},
]Implementations follow every ordinary MediaWiki bot rule: maxlag honoured, User-Agent identifying the operator, rate limits respected, and — because action=parse and friends answer with the querying user’s visibility rights — the same permission surface as the wiki itself. The REST gateway (/rest/v3/) covers the simpler reads directly. This tier is low-risk because it grants nothing new: a mapped read-only front over a read-only API.
In-page tools: the gadget that makes an article actionable
Where WebMCP genuinely adds capability is at the point of use — a reader’s agent, on the article, needing its shape without a round trip through the open web. MediaWiki’s frontend extension points are precisely specified and community-governed: gadgets, site scripts, ResourceLoader modules. A read-only, gated example — the pattern the trial ecosystem is designed around:
// MediaWiki:Gadget-WebMCP.js — registered via RLQ for safe timing
window.RLQ = window.RLQ || [];
window.RLQ.push(function () {
var ctx = document.modelContext || navigator.modelContext;
if (!ctx || !('registerTool' in ctx)) return; // no trial, no cost, no trace
var controller = new AbortController();
var page = mw.config.get('wgPageName');
ctx.registerTool({
name: 'article-structure',
description: 'Returns the section headings and edit-protected flag of the currently open wiki article.',
inputSchema: { type: 'object', properties: {} },
annotations: { readOnlyHint: true },
execute: function () {
return new mw.Api().get({
action: 'parse', page: page, prop: 'sections|displaytitle',
format: 'json', formatversion: 2
}).then(function (data) {
return { content: [{ type: 'text', text: JSON.stringify(data.parse) }] };
});
}
}, { signal: controller.signal });
window.addEventListener('pagehide', function () { controller.abort(); });
});Note what this inherits, deliberately: mw.Api() carries the session and its rights, returns formatversion=2 JSON, and the tool ships nothing it doesn’t already expose to a logged-in reader pressing the same buttons. Registration mechanics match the specification exactly — the dual-root feature detection survives Chrome’s documented migration from navigator.modelContext to the canonical document.modelContext ([modern-web-guidance](https://github.com/GoogleChrome/modern-web-guidance/blob/main/skills/modern-web-guidance/guides/webmcp/agentic-javascript-tools.md)); the AbortController signal is the only unregistration mechanism (there is no unregisterTool()); the return value is MCP’s content envelope. A ResourceLoader module is also consensus-shippable: the same Gadget review process that vets any UI change vets the agent surface, which is the governance the specification is conspicuously missing.
The declarative search form: two attributes, no extension review
Every MediaWiki skin renders a search form — plain GET markup, which is the entire substrate of the Declarative API ([explainer](https://github.com/webmachinelearning/webmcp/blob/main/declarative-api-explainer.md); mechanism walkthrough in our reference article):
<form action="/w/index.php" method="get"
toolname="wiki-search"
tooldescription="Searches this wiki. Returns a results page listing matching articles.">
<input type="search" name="search" required>
<input type="hidden" name="title" value="Special:Search">
<button type="submit">Search</button>
</form>The browser synthesizes the schema from the controls; omit toolautosubmit and submission stays human. A skin-level template edit — reviewed like any template change — makes every page on the wiki agent-usable for the most common query there is. This is the rare upgrade path that requires no extension, no deployment of JavaScript, and no new permission surface.
Editing: the line both worlds already agree on
MediaWiki learned in 2007 that writes need tokens (action=edit hands out a CSRF token; action=checktoken verifies; blocked and semi-protected pages enforce their own rules). WebMCP’s draft converges from the other direction: no built-in approval layer, so the site must supply one. The wiki answer follows directly — no autonomous edit-page tool, full stop. The acceptable ladder, in descending wisdom:
- Reads only (server MCP + in-page read tools); edits remain human — the status quo for good reason.
- An edit preparation tool: fills the edit form via declarative semantics, human reviews and publishes — the spec’s default human-in-the-loop, and identical to what a clipboard does today, only structured.
- Flagged-revision or sandbox flows: agent-adjacent drafts land in review queues that already exist — Recent Changes patrol, the world’s first agent-mitigation system, still is one.
Deployment order for a community (this is a governance document, not just a tutorial)
- Server-side MCP reads — trivially reversible, immediate payoff for the bots already hammering
api.php; you may even reduce load by pointing them at a stable tool contract. - Declarative search annotation — skin-level, one consensus thread, every page improved.
- Opt-in read gadget behind a preferences toggle — the native way to pilot interface experiments while a draft spec still moves.
- Any write capability: a formal RfC first. If a wiki won’t RfC a button move, it must RfC an agent hand.
Verification
Local: #enable-webmcp-testing flag, a wiki instance with the gadget loaded, DevTools — (await document.modelContext.getTools()).map(t => t.name) on an article, an edit page, a Special page (surface differs per skin template — assert each). Schema and routing validation with the Model Context Tool Inspector; ApiSandbox remains the ground truth for any tool you claim is a “thin projection.”
FAQ
REST API vs Action API — which should tools project?
Reads that exist cleanly in the REST gateway (/rest/v3/) can; the Action API covers the long tail and the token discipline. Either way the tool is a thin, described projection of a documented module — never custom data access that bypasses the API, which is precisely the pattern MediaWiki has spent two decades forbidding extensions from doing to the database.
Does this help Wikibase/Wikidata-scale deployments?
Absolutely — at that scale the MCP tier is the only sane one: structured entity queries are ideal tool surfaces, and the same capability/token plumbing applies. The in-page tier matters less when the audience is data consumers rather than readers.
What about Semantic MediaWiki or Cargo?
Ask/inline-query systems are unusually good tool targets — parameterized natural-language-ish queries with existing parsers. Same discipline: read-only tools first, descriptions that state bounds, and the community review process as your approval mechanism.
Conclusion
Wikis are the original human knowledge API — versioned, attributed, patrolled, reversible. WebMCP asks nothing MediaWiki does not already believe: declare your capabilities precisely, gate your writes behind tokens and review, make the reader’s experience better without adding attack surface. The wiki that ships read tools and an annotated search box is simply publishing its contract in the newest format; the wiki that hands an agent the edit button is answering a question it settled twenty years ago. The standards are new; the doctrine isn’t.