Field report: an agent built a 17-section landing page over the MCP. Here is everything it found, fixed in 1.9.5.

On 3 September an AI agent, driven by nothing but the MCP (JSON-RPC, key auth), took a fresh WordPress install on Hostinger from cold start to a finished 17-section landing page in Divi 5.11. It then wrote up everything that cost it a rebuild or a probe page. This is that report, item by item, with what shipped in WP BaseStation 1.9.5 for each. We publish these because a plugin that connects agents to your site should be graded by the agents that use it.

The one that mattered: the validator passed a shape that took the page down

What happened. The agent wrote a divi/contact-field whose fieldItem.innerContent value was an object ({"id":…,"title":…}). station_validate_markup said valid:true. station_create_page said success. The front end returned HTTP 500 — "Expected a string value, but a array value was given."

Why. The validator checked attribute paths, not value types. The schema already knew that field is a scalar; nothing read that.

What shipped. Values are now type-checked against the module schema. A scalar field given an object is a hard error, dvc_bad_attr_type, that names the node and quotes the fatal Divi would have thrown. And every page write now runs an in-process render probe and returns render_ok — or render_error with the exception — so a write that would 500 says so in the same response instead of warnings: [].

A stored title that rendered nothing

A blurb title written as a plain string ("value":"Expertise") stored, validated, and rendered no title — Divi's renderer reads ['text']. The correct shape was hinted at in known_paths and easy to miss. Now: a bare string on a link-carrying innerContent (blurb title, button, image) is coerced to {"text":…} on write with a warning, the schema response carries an inner_content_shapes map, and the skill states the rule outright: link-carrying innerContent is an object; heading, text and contact-field innerContent is a string.

A schema path Divi stores and never reads

divi/blurb's known paths advertised imageIcon.advanced.width.<bp>.value.image. Writing 80px there is accepted and the image renders at natural size; the renderer reads width from imageIcon.decoration.sizing.<bp>.value.width. The real path is now in known_paths, the dead one is mapped under a new renders_from key, and writing to it warns. Every module's schema also now returns a roots map — where sizing, spacing, shadow and border actually live for that module — which is the whole reason a shadow on divi/image belongs at image.decoration.boxShadow and not module.decoration.

A font variable that created a font nothing loaded

station_create_variables {type:"font", value:"Saira"} resolved, printed its --gvid token into :root, and rendered as the operating system's serif. No @font-face, no Google Fonts link — Divi enqueues webfonts it finds in literal family values, and a family that arrives only through a variable is invisible to it. The design-system tool reported the token as active. Now a Google family is enqueued when the variable is created (Divi's own loader where it exists, otherwise a link printed on wp_head at priority 1, where Divi's dequeue never sees it), the response says font.enqueued and how, and the performance audit warns about any font variable no stylesheet backs.

The smaller ones

• Mixed http/https media URLs on a site whose siteurl was still http. Every URL station_upload_media returns is pinned to the scheme the request arrived on, and station_get_site_context reports the mismatch.
• SVG refused. Landing pages are full of SVG badges. An SVG source is now rasterized to PNG at a requested width; raw SVG is never stored.
• No blank template. et_full_width_page only removes Theme Builder chrome; the theme's own header and footer still rendered. template:"blank" on station_create_page and station_set_post_fields uses Divi's blank page template.
• Rows with maxWidth and no width — rows default to 80% width, so maxWidth alone never applies. The validator warns; the skill's layout example carries width:"100%".
• Contrast false positive. Nav links styled inline with color:var(--gcid-…) were flagged 2.75:1 against the global link colour they did not use. The audit now reads the link's own colour; when it cannot, the finding says so and carries assumed:true.
• Where to activate a licence. Activation is owner-only, correctly, but the agent could not tell the owner where. site_context.license.activate_url now carries the exact wp-admin page.
• Draft copies 404 logged out. station_duplicate_page returns a preview_url alongside.
• Skill text gained the contact-form label CSS, the automatic select placeholder, the missing date field type, <br> being stripped from button text, alignItems:"flex-start" on icon-list items, and "clear the CSS cache after every update" — stale unified CSS masked two fixes during the build.

What the agent said worked

Key-mode auth from a plain HTTP client. The path checks and token-discipline warnings ("#666666 — pick heading or body colour"). Tokens returned as exact strings, copied verbatim, never mistyped. Owner-only licence activation and its refusal text. And, in its words, station_get_skill "is the best part of the product; the fixes above are additions to it, not replacements."

How we keep it fixed

Every item above is pinned in a new self-test group, Field report 1.9.5, that runs against your install from the Diagnostics tab — the object-on-a-scalar refusal, the title coercion, the blurb path, the roots map, the font enqueue, the scheme pin, the SVG guard, the inline-colour contrast rule and the skill text. The full suite is 1,898 checks on the store we dogfood against, all green on 1.9.5. Two items from the report are scoped for the next line: a css_for_node render-probe mode, and screenshots.

If you run an agent against WP BaseStation and it finds something, send its notes. They get read, fixed and pinned.