Obviously generated using Claude.ai - If AI submissions are not allowed please accept my apologies
Summary
update-page's section parameter accepts "new" but rejects every integer value with a schema validation error, making section-scoped edits to existing sections impossible. get-page's section parameter, which is a plain integer schema rather than a union, works correctly for reads.
Confirmed on v0.16.0. Present in at least one earlier release as well.
Reproduction
Against a page with several heading sections:
-
Read a section — works:
get-page { "title": "Sandbox", "section": 2 }
→ returns the section source
-
Append a new section — works:
update-page { "title": "Sandbox", "section": "new",
"sectionTitle": "Delta", "source": "Body." }
→ saves, returns a new revision ID
-
Edit an existing section — fails:
update-page { "title": "Sandbox", "section": 2,
"source": "== Beta ==\nEdited body." }
→ Input validation error: Invalid arguments for tool update-page:
section: Invalid input
Step 3 fails for every integer tried, including 0.
Schema
update-page declares section as a union:
"section": {
"anyOf": [
{ "type": "integer", "minimum": 0, "maximum": 9007199254740991 },
{ "const": "new", "type": "string" }
]
}get-page declares it as a plain integer, and that one validates fine:
"section": { "type": "integer", "minimum": 0, "maximum": 9007199254740991 }Suspected cause
The integer branch of the union appears not to be reachable in practice — the string branch is the only one that ever matches. A plausible mechanism is that the value arrives as a string and the union's integer branch performs no coercion, whereas the single-type schema on get-page does coerce. That the two tools differ only in union-vs-plain schema, and only the union fails, points at the union handling rather than at the transport.
I have not reproduced this against the server source directly, so treat the mechanism as a hypothesis and the observed behaviour above as the actual report.
Impact
Every edit to an existing section has to be a full-page rewrite. On large pages that is both expensive and risky: the caller must resend the entire source, and any omission silently truncates the page. It compounds with the 50,000-byte read truncation, since a page above that size cannot be read in one call or edited in part — reassembling the full source requires one truncated read plus a section-by-section fetch of the remainder before any edit can be made at all.
Suggested fix
Coerce or accept a numeric string in the integer branch of the union, so section: 2 and section: "2" both validate, matching the behaviour get-page already has.
Environment
- MediaWiki-MCP-Server v0.16.0, Docker image, HTTP transport
- MediaWiki 1.43.9
- Authenticated via bot password (server-side credentials, no bearer passthrough)
Obviously generated using Claude.ai - If AI submissions are not allowed please accept my apologies
Summary
update-page'ssectionparameter accepts"new"but rejects every integer value with a schema validation error, making section-scoped edits to existing sections impossible.get-page'ssectionparameter, which is a plain integer schema rather than a union, works correctly for reads.Confirmed on v0.16.0. Present in at least one earlier release as well.
Reproduction
Against a page with several heading sections:
Read a section — works:
Append a new section — works:
Edit an existing section — fails:
Step 3 fails for every integer tried, including
0.Schema
update-pagedeclaressectionas a union:get-pagedeclares it as a plain integer, and that one validates fine:Suspected cause
The integer branch of the union appears not to be reachable in practice — the string branch is the only one that ever matches. A plausible mechanism is that the value arrives as a string and the union's integer branch performs no coercion, whereas the single-type schema on
get-pagedoes coerce. That the two tools differ only in union-vs-plain schema, and only the union fails, points at the union handling rather than at the transport.I have not reproduced this against the server source directly, so treat the mechanism as a hypothesis and the observed behaviour above as the actual report.
Impact
Every edit to an existing section has to be a full-page rewrite. On large pages that is both expensive and risky: the caller must resend the entire source, and any omission silently truncates the page. It compounds with the 50,000-byte read truncation, since a page above that size cannot be read in one call or edited in part — reassembling the full source requires one truncated read plus a section-by-section fetch of the remainder before any edit can be made at all.
Suggested fix
Coerce or accept a numeric string in the integer branch of the union, so
section: 2andsection: "2"both validate, matching the behaviourget-pagealready has.Environment