Skip to main content
Glama

royal-mcp__wp_verify_rendered_page

Read-onlyIdempotent

Post-write verification tool. Fetches the actual rendered HTML that WordPress serves at a URL via a loopback request and returns the response status, a subset of response headers (content-type, cache-control, x-cache), the page title, meta description, first h1, counts of script and stylesheet link tags, robots_meta (content of , null when absent), x_robots_tag (the X-Robots-Tag header, null when absent), redirect_chain ([{url, status}] for each redirect followed, up to 5; [] when none — response_status is the final status), tls_valid (whether the https certificate verifies; null for http), and (when include_body_excerpt is true) a 500-char excerpt of the page body. Optional selector arg reports whether an id/class selector is present in the served HTML. Use after any write that changes content, theme, or options to catch page-builder caches, object caches, or edge caches serving stale HTML even when the DB write returned success. Rate-limited to 10 calls per minute per URL; the redirect … Through Royally: read-only, runs straight away.

Input Schema

NameRequiredDescriptionDefault
urlYesAbsolute URL on this site to fetch (must match home_url() origin).
scopeNopage (default) matches anywhere; article matches only inside the detected article body, so header, sidebar and footer are left out.
checksNoRun the page checks (visible H1 count, duplicate H1, duplicate table of contents, duplicate excerpt, leftover shortcodes) without a selector. They also run whenever selector or scope is given.
site_idNoSite to run this tool on: 8ef2e52b-bd07-4671-a363-ebe8b480b65c (https://demo.royalplugins.com)
max_textNoMost characters of visible text per match. Default 300.
selectorNoCSS selector to match in the served HTML. Supported: tag, .class, #id, [attr], [attr="value"], [attr^="value"], [attr*="value"], [attr$="value"], combinations of those (img.hero[alt]), descendant (article img) and child (figure > img). Returns matches[] with tag, id, classes, visible text, an html excerpt, and for images src, srcset, sizes, alt, width, height, loading, decoding and the figure caption; for links href and rel.
max_matchesNoMost matches to return. Default 20, up to 100.
include_body_excerptNoWhen true, include a 500-char excerpt of the <body> in the response. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only/idempotent/non-destructive, but the description adds substantial context beyond them: loopback mechanism, rate limit of 10 calls/minute per URL, redirect_chain behavior up to 5, tls_valid semantics, and null handling for absent meta. This is rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with 'Post-write verification tool,' but the bulk is a dense run-on sentence enumerating every return field and ends truncated ('the redirect …'). The field-by-field listing is verbose and could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries the full burden of explaining return values, and it does so comprehensively (status, headers, title, meta, robots, redirects, TLS, excerpt). An agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description nonetheless adds meaning beyond the schema by explaining what selector reports (presence of id/class in served HTML) and that checks also run when selector or scope is given, clarifying parameter interactions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (fetches rendered HTML via loopback), resource (served page at a URL), and its role (post-write verification). It is clearly distinguishable from siblings like wp_get_page or wp_get_block_outline, which read stored data rather than live rendered output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use it after any write that changes content, theme, or options, and names the failure mode (page-builder/object/edge caches serving stale HTML despite a successful DB write). It does not name a specific alternative tool to prefer, so it falls just short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources